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.

Advertisements

9 responses to “Building on the OpenID PAPE specification

  1. Thanks for this nice article. I hope PAPE will help us to provide Strong Authentication for OpenID

    Sylvain Maret

  2. Hello,

    Maybe you can add more methods ?

    method = {password, otp, pki, biometric, etc.}

    Like SMS or Phone call, etc…

    Does it make sense for you ?

    A good example is SAML:

    3.4.1 Internet Protocol…………………………………………………………………………………………………………22
    3.4.2 InternetProtocolPassword……………………………………………………………………………………………24
    3.4.3 Kerberos……………………………………………………………………………………………………………………25
    3.4.4 MobileOneFactorUnregistered………………………………………………………………………………………27
    3.4.5 MobileTwoFactorUnregistered………………………………………………………………………………………30
    3.4.6 MobileOneFactorContract……………………………………………………………………………………………33
    3.4.7 MobileTwoFactorContract……………………………………………………………………………………………36
    3.4.8 Password…………………………………………………………………………………………………………………..39
    3.4.9 PasswordProtectedTransport………………………………………………………………………………………..41
    3.4.10 PreviousSession……………………………………………………………………………………………………….42
    3.4.11 Public Key – X.509…………………………………………………………………………………………………….44
    3.4.12 Public Key – PGP………………………………………………………………………………………………………45
    3.4.13 Public Key – SPKI………………………………………………………………………………………………………46
    3.4.14 Public Key – XML Digital Signature……………………………………………………………………………….48
    3.4.15 Smartcard………………………………………………………………………………………………………………..49
    3.4.16 SmartcardPKI…………………………………………………………………………………………………………..50
    3.4.17 SoftwarePKI……………………………………………………………………………………………………………..53
    3.4.18 Telephony………………………………………………………………………………………………………………..55
    3.4.19 Telephony (“Nomadic”)……………………………………………………………………………………………….56
    3.4.20 Telephony (Personalized)……………………………………………………………………………………………57
    3.4.21 Telephony (Authenticated)…………………………………………………………………………………………..59
    3.4.22 Secure Remote Password…………………………………………………………………………………………..60
    3.4.23 SSL/TLS Certificate-Based Client Authentication……………………………………………………………62
    3.4.24 TimeSyncToken………………………………………………………………………………………………………..63
    3.4.25 Unspecified……………………………………………………………………………………………………..

  3. Interesting extension to PAPE. (Sorry came across this only recently).

    Couple of questions:
    1. Have you guys thought about allowing RPs to specify the preferred methods/otp types in the login request ? The benefit being if the method the OP uses is going to be not good enough for RP, then there is no need for the OP to make the user go through the pain of verifying the OTP.
    2. Along the same lines, can the OP advertise the methods/OTP types it supports for it’s users in it’s XRDS document ? that would help the RPs choose the OPs they support before hand.
    3. Finally, do you know if this is being considered for future versions of PAPE extension ?

    thanks
    Praveen

  4. Thanks for the comments, Sylvain & Praveen. As you may know the official PAPE 1.0 spec was published on 12/30/2008 (http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html). This post proposed some alternatives to describing strong authentication handshakes between an OpenID Provider and its users.

    The OpenID working group that contributed and voted on the final spec decided to keep the subjective authentication policies that I discussed in this article (phishing-resistant, multi-factor and physical multi-factor) and somewhat dated NIST Assurance Policies.

    So Sylvain, to your point, we the PAPE-AM group did consider other factors, like the ones you mentioned, but we wanted to start with the most popular subset of those in use today.

    @Praveen:
    1. We did consider letting the RPs specify the preferred method for the exact reason that you mentioned. The official spec sort-of does this with openid.pape.preferred_auth_policies, but it does not _require_ the OP to use any of the policies. The preferred policies are treated as nice-to-have, not requirements.

    If you modify your example to specify that passwords are the preferred method, even if OTP is available, then the OP might be able to avoid requesting an OTP from the user.

    2. More information about this is available on the official spec page linked above in the “Advertising Supported Authentication Policies” section.

    3. Good question. Some members of the PAPE working group saw value in PAPE-AM when we proposed it back in October 2008. But, PAPE-AM was a big enough departure from the actively maturing PAPE 1.0 spec, that it was ultimately viewed as too big of a change to a spec that was trying to get published as soon as possible.

    I would encourage you to join the PAPE working group mailing list and bring up the parts of PAPE-AM that you think deserve attention in the official PAPE spec. Thank you for the insightful questions.

  5. Pingback: Healthcare PKI in Denmark « Digital Trust

  6. VERY loosely related indeed…..

  7. PAPE needs to provide the tools to guard against cases where a hacker gains access to an account using the “I’ve lost my token” workflow. With the current VeriSign PIP workflow, a hacker can replace the user’s original hardware token with another one and then proceeds to login with two-factor authenticated status.

    I’ve discussed this topic at:

    http://sites.google.com/a/daveboden.com/home/Home/openidissues

    Overall, I feel that the best solution is to ensure that OpenID providers not only say how a user is authenticated but also provide details of exactly which hardware token has been used.

    Regards,
    Dave

  8. Dave, thanks for the comment. I agree that the “I’ve lost my token” workflow greatly reduces the security gained by using a browser certificate or OTP for login. It seems that the current state of the “OTP industry” almost always needs to fall back to the much-less secure email verification. I believe PayPal uses the same Q&A / email verification method today.

    As stated in this (over a year old) post, PAPE-AM was an attempt to standardize how OPs communicate more details about user authentication to RPs. Ultimately it’s about trust of the OP. PAPE-AM may have been too complicated for most RPs to even care about. I think we’ll see more of an OP whitelist approach being deployed – An RP will specify a list (perhaps managed by an authority) of OPs that are allowed to be used to delegate authentication.

    Check out the U.S. federal government’s take on this in the ICAM OpenID 2.0 Profile.

    http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV

  9. my husband was looking for VA 22-8691 several days ago and was told about a company with a lot of fillable forms . If others need VA 22-8691 as well , here’s a http://goo.gl/mknzgk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s