Building on the OpenID PAPE specification

When we decided to launch our TrustBearer OpenID provider, we were excited that there was an extension to the OpenID specification that would allows us to convey the strength with which we authenticated our users. The OpenID Provider Authentication Policy Extension (PAPE) appeared to provide us with a way to tell Relying Parties (RP) that we were using arguably one of the strongest methods of user authentication available: PKI challenge-response with the user’s private key stored in a hardware device and protected by a passphrase.

PAPE allows OpenID Providers (OP) to describe their authentication policies to RPs using the following 3 categories:

• Phishing-Resistant Authentication: An authentication mechanism where the End User does not provide a shared secret to a party potentially under the control of the Relying Party.
• Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor.
• Physical Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor where at least one of the factors is a physical factor such as a hardware device or biometric.

There is some overlap between these categories, and if an OP supports more than one policy, they should all be asserted. (e.g. Using a hardware-based key with PIN would typically include all 3 of these policies)

For TrustBearer OpenID we assert all three of these policies. This would appear to say to RPs that we are providing the strongest authentication techniques available. And it does.

But there is a problem.

Many other OPs, using arguably less-strong authentication techniques could also assert the exact same policies. How? Consider the following scenarios.

Phishing-Resistant Authentication

This policy states that if a shared secret is not passed from the user to the OP, then this authentication method is considered to be phishing resistant. Does this include a password that is sent over an SSL channel? What about a one-time-password? Depending on their opinion, an OP could probably make the case that they support or don’t support phishing-resistant technology. The decision is subjective.

Multi-Factor Authentication

The policy states that the user authenticated using more than one factor (something you have, know, or are). The problem is that all kinds of multi-factor authentication are not treated equally. One OP could authenticate its users using client authentication with SSL and a password-protected private key, while another OP could use a password + visual grid card. These types of multi-factor authentication are not equivalent, but this policy could imply that they are equal.

Physical Multi-Factor Authentication

The policy states that the user authenticated using multiple factors where one of the factors is a “hardware device or biometric.” Like the multi-factor authentication case, specifying “physical” still opens a wide range of levels of authentication. A biometric device that unlocks a password that is sent to the website is far less secure than using PKI-based smart card authentication with PIN protection.

The PAPE authors intentionally avoided defining specific authentication methods. Instead, they stuck to these higher-level policies to describe classes of authentication that were used. While I understand the motivation of this decision (high-level policies change less than authentication technology), I feel that it will lead to OPs and RPs subjectively interpreting how the user was actually authenticated.

A Solution

A few members of a related industry group, the Initiative for Open Authentication (OATH), got together and discussed the PAPE specification. Together we came to the conclusion that specific assertions about how a user authenticated to an OP were needed. This group is tentatively calling our suggested changes OpenID Provider Authentication Policy Extension – Authentication Mechanisms (PAPE-AM).

Even though specific authentication methods change more often than the higher-level policies presented in PAPE, they are much more definitive. Consider the following OP response parameters presented in PAPE-AM (Note: These are all in a draft stage and have not yet been accepted by any official OpenID specification working group) :

• method = {password, otp, pki, biometric}

  
  The authentication method must contain one or more of these elements in the set. We chose 4 of the most common authentication methods today. This set could be expanded in the future.

• otp.info = {mode, token_type, consent, length, encoding, algorithm}

  
  This parameter contains detailed information about the type of One-Time Password token and service that was used during authentication. Consent is defined by the additional factor of authentication needed to use the OTP (such as a passphrase or biometric).

• pki.key.info = {storage, algorithm, policy, consent}

  
  This parameter contains detailed information about the private key used in a challenge-response with PKI authentication. (e.g. “hardware”, “RSA_1024”, “not exportable”, “passphrase”)

Each of these response parameters are clearly defined. This gives both the OP and RP the ability to objectively assert and verify what method of authentication was used.

Who would use this? The same OpenID Providers & Relying Parties that would use PAPE. Here’s a couple use cases:

1. Online banking website that supports government-issued ID smart cards
   
   Consider an online banking website that has adopted support for OpenID, but wishes to restrict access to users who have been issued a citizen ID smart card by government authorities that the bank trusts. In this case, the online banking website would use PAPE-AM to ensure hardware-based PKI authentication was used with the OP. The banking website would also use PAPE-AM to get information about who issued the user’s digital certificate.

   These additional request/response parameters provided by PAPE-AM help ensure that the bank’s users will not fall victim to hijacking attempts since client authentication using PKI with a hardware-based token was used. The information about the issuer of the certificate could help the bank prove the real-life identity of the user, also.

   By using PAPE-AM request/response parameters such as method, pki.key.storage, pki.cert.revocation_check, and pki.key.info an online bank RP could be assured that the OP is authenticating its users as described above.

2. Online Brokerage Supports OTP
   
   An online brokerage supports OpenID as a RP. However, when enabling users to authenticate via third-party OpenID Providers, they want to make sure that the user is using a hardware OTP token where the length of the OTP is at least 8. The RP can request additional PAPE-AM attributes during the OpenID exchange and thereby can be assured that the user and the OpenID provider meet the requirements.

   By using PAPE-AM request/response parameters, including method and otp.info, an online brokerage RP could be assured that the OP is authenticating its users as described above.

Next Steps

I created this post because the PAPE-AM authors and I wanted to engage the community that is impacted by both PAPE and the suggested changes that I outlined above. The authors and I felt that we could help OpenID gain adoption amongst Identity Providers & Relying Parties providing secure online services by improving the existing PAPE specificaiton. We have created an early draft of a PAPE-AM specification, and are searching for the best way to publish this draft – whether it is part of PAPE or as a standalone extension.

We would like feedback from the OpenID community. Do you think the high-level PAPE policies are sufficient? Do you see value in some of the proposed PAPE-AM request/response parameters? Should the PAPE-AM policies be merged into PAPE?

Please add your comments to this post or contact me directly.