TOC 
DraftD. Recordon
 VeriSign
 June 22, 2007


OpenID Provider Authentication Policy Extension 1.0 - Draft 1

Abstract

This extension to the OpenID Authentication protocol provides means for a Relying Party to request previously agreed upon authentication policies be applied by the OpenID Provider and for an OpenID Provider to inform a Relying Party what authentication policies were used. Thus a Relying Party can request the End User authenticate, for example, by means which are resistant to common phishing attacks or that provide for multi-factor authentication. Likewise, the OpenID Provider is able to convey to the Relying Party that the End User either met or did not meet the requirements of the requested policy, or policies, in the OpenID Authentication response message as well as the general strength of the credential(s) being used.

This extension is not aimed at answering all questions around the quality of an OpenID Authentication assertion. Rather, it is designed to be balanced with information the Relying Party already has in regards to the OpenID Provider and the level of trust it places in it. It is envisioned that if additional information is needed about processes such as new End User enrollment on the OpenID Provider, this will either be conveyed by out-of-band methods or in other extensions such as OpenID Attribute Exchange. It is expected that other aspects (e.g. security characteristics, credential provisioning, etc) could be dealt with in the future, though End User privacy concerns must be kept in mind especially when discussing enrollment procedures.

As an extension, it requires no changes to the OpenID Authentication protocol and is viewed as an optional extension though its use is certainly recommended. This extension can be used with both OpenID Authentication versions 1.1 and 2.0.

While none of the information expressed via this extension can be verified by the Relying Party using technology alone, this does not limit the utility of this extension. The lack of a single required trust model within OpenID allows for Relying Parties to decide which Providers they trust using whatever criteria they choose - likewise RPs will decide whether or not to trust claims as to authentication policy from such OpenID Providers as well.



Table of Contents

1.  Definitions
    1.1.  Requirements Notation
    1.2.  Conventions
    1.3.  Terminology
2.  Extension Overview
3.  Advertising Supported Policies
4.  Defined Authentication Policies
5.  Authentication Protocol
    5.1.  Request Parameters
    5.2.  Response Parameters
6.  Security Considerations
    6.1.  NIST Assurance Levels
7.  Examples
    7.1.  Authentication Method Classifications
8.  Acknowledgements
9.  Normative References
§  Author's Address




 TOC 

1.  Definitions



 TOC 

1.1.  Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” 1997.).



 TOC 

1.2.  Conventions

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.

All OpenID Provider Authentication Policy Extension (PAPE) messages MUST contain the following extension namespace declaration, as specified in the Extensions section of [OpenIDAuthentication2.0] (specs@openid.net, “OpenID Authentication 2.0 - Draft 11,” 2007.).


    openid.ns.<alias>=http://specs.openid.net/extensions/pape/1.0

The actual extension namespace alias should be determined on a per-message basis by the party composing the messages, in such a manner as to avoid conflicts between multiple extensions. For the purposes of this document and when constructing OpenID 1.1 messages, the extension namespace alias SHALL be "pape".



 TOC 

1.3.  Terminology

The following terms are defined in [OpenIDAuthentication2.0] (specs@openid.net, “OpenID Authentication 2.0 - Draft 11,” 2007.):



 TOC 

2.  Extension Overview

  1. As part of the [Yadis] (Miller, J., Ed., “Yadis Specification 1.0,” 2005.) Discovery process, OpenID Providers can optionally add supported authentication policies to an End User's XRDS document. This aides Relying Parties in choosing between multiple listed OPs depending on authentication policy requirements.
  2. The Relying Party includes parameters in the OpenID Authentication request describing its preferences for authentication policy for the current assertion.
  3. The OpenID Provider processes the PAPE request, prompting the End User to fulfill the requested policies during the authentication process.
  4. As part of the OpenID Provider's response to the Relying Party, the OP includes PAPE information around the End User's authentication. An OP MAY include this response information even if not requested by the RP.
  5. When processing the OpenID Provider's response, the Relying Party takes the PAPE information into account when determining if the End User should be sent through additional verification steps or if the OpenID login process cannot proceed due to not meeting policy requirements.



 TOC 

3.  Advertising Supported Policies

Via the use of [Yadis] (Miller, J., Ed., “Yadis Specification 1.0,” 2005.) within OpenID, Relying Parties are able to discover OpenID Provider service information in an automated fashion. This is used within OpenID Authentication for a RP to discover what version of the protocol each OP listed supports as well as any extensions, such as this one, that are supported. To aide in the process of a Relying Party selecting which OP they wish to interact with, it is advised that the following information be added to the End User's XRDS document.

When advertising supported policies, each policy URI MUST be added as the value of an <xrd:Type> element of an OpenID <xrd:Service> element in an XRDS document.



 TOC 

4.  Defined Authentication Policies

The following are previously agreed upon policies and policy identifiers describing how the End User authenticated to their OP. Additional policies can be agreed upon and used without having to make changes to this document. The policies described below are designed to be a starting point to cover the most common use-cases. Additional polices can be found at http://schemas.openid.net/pape/policies/. [anchor6] (There is ongoing discussion as to if a policy should be defined to represent technologies which help prevent phishing attacks though do not fit the phishing-resistant definition. Examples would be site seal technology, browser plugins specific to OpenID flows, and Internet Explorer 7's support for Extended Validation SSL certificates.)



 TOC 

5.  Authentication Protocol



 TOC 

5.1.  Request Parameters

The following parameters can be included during an OpenID Authentication request (specs@openid.net, “OpenID Authentication 2.0 - Draft 11,” 2007.) [OpenIDAuthentication2.0] by the Relying Party.



 TOC 

5.2.  Response Parameters

In response to a Relying Party's request, the following parameters MUST be included in the OpenID Authentication Response. All response parameters MUST be included in the signature of the Authentication Response. It is RECOMMENDED that an OP supporting this extension include the following parameters even if not requested by the Relying Party.

All response parameters MUST describe the End User's current session with the OpenID Provider.



 TOC 

6.  Security Considerations

As to commonly accepted security practices, it should be noted that the overall strength of any authentication is only as strong as its weakest step. It is thus recommended that provisioning of phishing-resistant and other credentials stronger than shared secrets should be accomplished using methods that are at least as strong as the credential being provisioned. By counter-example, allowing people to retrieve a phishing-resistant credential using only a phishable shared secret negates much of the value provided by the phishing-resistant credential itself.

OpenID Providers need to make smart decisions as to the level of authentication that they assert the End User performed in comparison to that requested by the Relying Party. For example, if the RP were to request phishing-resistant authentication it may or may not make sense for the OP to actually tell it that the End User did in fact perform phishing-resistant, physical multi-factor, and NIST Level 2 authentication. While there are use cases where the OP should provide the true strength of the authentication if it is above the request, there are also use cases where the OP should only assert to the level requested.

One example of the later would be in an online banking scenario where the End User is solely viewing their balance and thus the RP requests phishing-resistant authentication. If the OP were to actually assert that the user performed stronger authentication than requested, additional access may be granted to the End User at the RP. While in many cases this may be desired, in this scenario it increases the risk in terms of if the End User were to not end their session with the RP and leave their User-Agent unsecured. Rather by the OP only responding to the level requested, and the RP making a second request for a higher level when it is needed at the time, it can reduce the overall risk. An example of this is that when working on Linux systems you do not login as the "root" user at all times.



 TOC 

6.1.  NIST Assurance Levels

Depending on the particular use case being satisfied by the authentication response and PAPE information, the OpenID Provider will have to make a decision, ideally with the consent of the End User, as if it will include the "openid.pape.nist_auth_level" parameter. This information is designed to give Relying Parties more information around the strength of credentials used without actually disclosing the specific credential type. Disclosing the specific credential type can be considered a potential privacy or security risk.

It is RECOMMENDED that this parameter always be included in the response from the OP. This holds true even in cases where the End User authentication does not meet one of the defined Authentication Policies. For example, if the End User is authenticating using a password via HTTPS there is still value to the RP in knowing if the strength of the Password corresponds to the entropy requirements laid out by Level 1 or 2 or that it does not even meet the minimum requirement for the lowest level. With that said, discretion needs to be used by OP's as conveying that one of their End User's has a weak password to an "un-trustworthy" RP would not generally be considered a good idea.



 TOC 

7.  Examples



 TOC 

7.1.  Authentication Method Classifications

This non-normative section illustrates classification of various common authentication methods and their respective conformance within the defined policies and levels.



 TOC 

7.1.1.  Authentication Policy Examples

This table provides examples of common authentication technologies and their mapping to the Authentication Policies defined in Section 4 (Defined Authentication Policies).

MethodPhishing-ResistantMulti-FactorPhysical Multi-Factor
Password via HTTPS      
PIN and digital certificate via HTTPS X X  
PIN and "soft" OTP token via HTTPS X X  
PIN and "hard" OTP token via HTTPS X X X
PIN and "hard" crypto token via HTTPS X X X

[anchor14] (Where does technology such as Vidoop or Passfaces fit into this table?)



 TOC 

7.1.2.  NIST Assurance Levels

This section is designed to highlight the majority of referenced information needed in the most commonly envisioned OpenID Provider deployments. All normative and authoritative text can be found in [NIST_SP800‑63] (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.).

This table is republished from page 39 of [NIST_SP800‑63] (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.).

Token TypeLevel 1Level 2Level 3Level 4
Hard crypto token X X X X
One-time password device X X X  
Soft crypto token X X X  
Passwords & PINs X X    

This table is republished from page 39 of [NIST_SP800‑63] (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.).

Protect AgainstLevel 1Level 2Level 3Level 4
On-line guessing X X X X
Replay X X X X
Eavesdropper   X X X
Verifier impersonation     X X
Man-in-the-middle     X X
Session hijacking       X

The following table illustrates the minimum number of factors required at each assurance level.

LevelFactors
1 1
2 1
3 2
4 2

In all cases, implementing a commonly accepted nonce and cross-site scripting protection when entering authentication credentials is required to satisfy all four Assurance Levels. All examples below assume this requirement is met.

It should be noted that NIST Assurance Levels 1 and 2 have differing password entropy requirements. When working with passwords, you should refer to the [NIST_SP800‑63] (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.) specification for more details. All examples below assume the password meets these requirements.

This table provides examples of common authentication technologies and their mapping to NIST Assurance Levels, please be aware that there are details not represented in these examples that may bear on the resulting Assurance Level.

MethodLevel 1Level 2Level 3Level 4
Password via HTTP Yes, if challenge-response      
Password via HTTPS Yes Yes    
PIN and Digital Certificate via HTTPS Yes Yes Yes  
PIN and "soft" OTP token via HTTPS Yes Yes Yes  
PIN and "hard" OTP token via HTTPS Yes Yes Yes  
PIN and "hard" crypto token via HTTPS Yes Yes Yes Yes, if FIPS 140-2 Level 2 crypto and Level 3 physical


 TOC 

8.  Acknowledgements

I'd like to thank Ben Laurie, Dick Hardt, Drummond Reed, George Fletcher, Kim Cameron, and Mike Jones for their feedback when drafting this specification.



 TOC 

9. Normative References

[NIST_SP800-63] Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.
[OpenIDAuthentication2.0] specs@openid.net, “OpenID Authentication 2.0 - Draft 11,” 2007 (TXT, HTML).
[RFC2119] Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, 1997.
[Yadis] Miller, J., Ed., “Yadis Specification 1.0,” 2005 (PDF, ODT).


 TOC 

Editorial Comments

anchor6: There is ongoing discussion as to if a policy should be defined to represent technologies which help prevent phishing attacks though do not fit the phishing-resistant definition. Examples would be site seal technology, browser plugins specific to OpenID flows, and Internet Explorer 7's support for Extended Validation SSL certificates.
anchor7: There is ongoing discussion as to the best wording for this definition. The main spirit of this definition is that a user does not authenticate to the OP by providing a password by itself directly from within the User-Agent.
anchor14: Where does technology such as Vidoop or Passfaces fit into this table?


 TOC 

Author's Address

  David Recordon
  VeriSign, Inc.
  487 E Middlefield Road
  Mountain View, CA 94043
  USA
Email:  drecordon@verisign.com