P2P Identity Proofing

Burt Kaliski at RSA Labs recently contacted me after we published our Authentication Lifecycle Management: Avoiding the Pitfalls research document. Burt and his team have been working on some of the same emergency access issues described in the ALM document. The emergency access issues are discussed in other Burton Group research documents, including Strong Authentication: Increased Options, but Interoperability and Mobility Challenges Remain and Consumer Authentication and the FFIEC Guidance. Some of Burt’s colleagues (John Brainard, Ari Juels, Ron Rivest, Michael Szydlo, and Moti Yung) presented a paper titled “Fourth-Factor Authentication: Somebody You Know” at the 13th ACM Conference on Computer and Communications Security in early November. The paper outlines a new, peer-to-peer (P2P) identity proofing approach that can be used in emergency access scenarios. The approach resonates with the ideas discussed in Mike Neuenschwander’s Law of Relational Symmetry blog entry.

Why does identity proofing matter? Reliable identity infrastructures require good authentication lifecycle management. The cornerstone of authentication lifecycle management is identity proofing. Identity proofing gives the organization confidence that the user performing an authentication is the legitimate user. Identity proofing is the process organizations perform to bind users to authentication methods. It must be performed at key phases of the lifecycle, including emergency access. Restated, a poorly identity-proofed smart card provides less identity assurance than an adequately identity-proofed password.

Emergency access is a temporary state where the user does not have access to their authenticator. Authenticators include smart cards, biometrics, and one-time password (OTP) devices. One example is users forgetting their two-factor hardware token. For the sake of clarity I will stick with OTPs as we examine the issues surrounding emergency access, but the approaches outlined here apply to most authentication systems.

There are several common approaches to identity-proof users so they get temporary access.
• The Help Desk. The users contact the corporate help desk, and authenticate to the help desk person. Once the help desk person has validated the identity of the caller, she can issue a temporary password. Most two-factor authentication systems support temporary password expiry (for example, the temporary password is invalidated after two days). After the expiry, the password will not be accepted, and the original two-factor hardware token must be used to authenticate. The two chief criticisms of the help desk approach are cost and subjectivity to social engineering attacks.

• Self-Service via Knowledge-Based Authentication (KBA). Users access a portal and answer some questions that in theory only they know the answer to. KBA is also commonly called “life questions”. KBA is one of the surest ways to degrade a stronger authentication mechanism.

• Self-Service via Out-of-Band (OOB) Identity Proofing. OOB identity proofing is one of the more promising identity proofing approaches, particularly in consumer authentication systems. OOB identity proofing utilizes a mechanism outside the channel of the primary authenticator (e.g., dialing the user back at a phone number of record, then binding the dial-back to a web session via a recovery code). OOB identity proofing is emerging as a security-smart, cost-effective identity proofing approach.

The paper specifies a process where a peer (“the helper”) can identity-proof the user (“the asker”) in an emergency access scenario. The process has the following tasks:
• The asker contacts the helper. The relationship between the helper and asker is established in advance (e.g., at the time of OTP issuance), and the contact medium would likely be telephone.
• Helper authenticates the asker. The helper may verify the identity of the user by voice, caller-ID, or a previously agreed-upon protocol.
• Helper authenticates to server. The helper authenticates to the authentication authority (e.g., via a web browser session protected by anonymous SSL) with his PIN and OTP tokencode.
• Helper obtains a vouchcode. The authentication authority delivers a vouchcode to the helper, which is a short passphrase that can be relayed from the helper to the asker. The authentication authority records the ongoing P2P identity proofing transaction in anticipation of the asker contacting the authentication authority in a subsequent step.
• Helper gives vouchcode to asker.
• Asker authenticates to Authentication Authority. The asker authenticates via PIN (which he normally uses in conjunction with his OTP) and the vouchcode he got from the helper.
• Authentication Authority issues temporary password to the asker

The paper (to the credit of the authors) also specifies an attack vector – the helper impersonating the asker. This vector would be mitigated with consistent auditing and verification procedures (e.g., contacting the asker and/or the asker’s manager to confirm the emergency access process after the fact).

Scalability is a potential concern. Would P2P identity proofing work well in large organizations? I believe that it would scale, provided that the organization has well-defined emergency access processes. As discussed in the Authentication Lifecycle Management: Avoiding the Pitfalls research document, well-defined processes – regardless of the identity proofing mechanism– are essential for successful authentication deployments.

What’s the takeaway? The RSA folks have outlined a new, viable alternative identity proofing approach that is a good alternative to the help desk and KBA approaches. While P2P identity proofing can support a variety of technologies (including passwords), the sweet spot is OTP because of the higher identity assurance requirements and the portability of the devices. The creation of a P2P identity-proofing process is readily achievable, and can be built without modifying most vendors’ OTP systems, including those from the OATH vendors.

[posted by Mark Diodati]