Draft H. Granqvist VeriSign, Inc. September 2006 OpenID Authentication Security Profiles - Draft 1 Granqvist [Page 1] OpenID Authentication Security Profiles September 2006 Abstract This memo defines security profiles for OpenID 2.0 authentication protocol. By agreeing on one or several such security profiles, an OpenID relying party and identity provider can decide the security properties for their mutual OpenID communication before such communication takes place. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 5 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security variants . . . . . . . . . . . . . . . . . . . . . . 10 9. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Profile A . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Profile B . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Security considerations . . . . . . . . . . . . . . . . . . . 15 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 13. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Granqvist [Page 2] OpenID Authentication Security Profiles September 2006 1. Introduction The OpenID Authentication 2.0 [OPENID] protocol defines a way to prove ownership of an identifier. The typical use-case of this protocol is to log into one or several web sites without having to deal with multiple usernames and passswords. In the protocol, claims of ownership to a specific identifier have several security dependencies, for example cryptographic primitives, trust in keying material, and reliance on underlying domain system. This memo seeks to describe a framework for mechisms to describe such dependencies, as well as defining a few usable profiles. This memo intentionally does not advise on usage of specific profiles, nor does it implicitly claim to cover all security dependencies of the protocol, nor does it decide how to process a party's willing or unwilling departure from a previously agreed-upon profile. Granqvist [Page 3] OpenID Authentication Security Profiles September 2006 2. 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 RFC 2119 [RFC2119]. Granqvist [Page 4] OpenID Authentication Security Profiles September 2006 3. Definitions and Terminology TODO. Granqvist [Page 5] OpenID Authentication Security Profiles September 2006 4. Goals This security profile specification has the following goals. 1. Define a framework for describing profiles that security mechanisms with in OpenID Authentication 2.0 [OPENID]. 2. Define a number of security profiles using this framework. 3. Absence or presence of these profiles MUST have no effect on the referenced OpenID protocol. Compliance (and non-compliance) should only be governed by the protocol's parties and not the protocol itself. 4. The list of identified security variants must be extensible for future additions. This is necessary to handle security risks that were identified after this memo was written. 5. Any new security variants MUST be appended to the list of identified variants, and not override them. This is needed to keep previous defined profiles unchanged over time. A security variant that should no longer be used will be marked as such in the current version of this memo. Granqvist [Page 6] OpenID Authentication Security Profiles September 2006 5. Non-goals This security profile specification has the following non-goals. 1. Automatic negotiation of profile. This memo intentionally does not define a profile negotiation phase. 2. Automatic detection of profile violations. Some security properties are enforceable only via cooperation of the protocol parties. Granqvist [Page 7] OpenID Authentication Security Profiles September 2006 6. Requirements TODO. Granqvist [Page 8] OpenID Authentication Security Profiles September 2006 7. Conventions It is assumed an OpenID Authentication 2.0 [OPENID] party will advertise its intended profile compliance via the service discovery phase by using the service types defined in this memo. Granqvist [Page 9] OpenID Authentication Security Profiles September 2006 8. Security variants The following section describes the identified security variants in the OpenID Authentication 2.0 [OPENID] protocol. This table defines the security variants and the expected values. References are tp the OpenID specification. +--------+------------------------+---------------------------------+ | Number | Variant | Values | +--------+------------------------+---------------------------------+ | 1. | Wildcards allowed in | One of Yes/No | | | trust roots. This | | | | relates to whether the | | | | idp accepts wild | | | | carded trust roots as | | | | specified in section | | | | 8.2 | | | | | | | 2. | Allow unsecure | One of Yes/No | | | associations? Whether | | | | the idp agrees to | | | | process authentication | | | | messages with no | | | | assoc_handle in | | | | section 8. | | | | | | | 3. | Types of claimed | Set of Http/Https/XRI | | | identifiers accepted. | | | | Types of identifiers | | | | as enumerated in | | | | section 9.3. | | | | | | | 4. | Self-issued | One of Yes/No | | | certificates allowed | | | | for authentication. | | | | This Applies to all | | | | https traffic. If | | | | 'no' here, then idp | | | | *probably* requires | | | | all https identifiers | | | | to chain up to known | | | | trust roots, but | | | | that's intentionally | | | | not implied. | | | | | | Granqvist [Page 10] OpenID Authentication Security Profiles September 2006 | 5. | XRDS file must be | One of Yes/No | | | signed. Signature on | | | | the XRDS as per | | | | XMLDSIG. Keying | | | | material not | | | | specified, since RP | | | | ultimately needs to | | | | make own decision | | | | whether to trust keys | | | | used for such | | | | signature. | | | | | | | 6. | XRDS must be retrieved | One of Yes/No | | | over secure channel. | | | | This does not imply | | | | SSL. See note on 4. | | | | about trust roots. | | | | | | | 7. | Accepted association | Set of | | | session types. What | No-encryption/DH-SHA1/DH-SHA256 | | | types of session types | | | | can be used as defined | | | | in section 7.4.3 | | | | | | | 8. | RP must have XRDS. | One of Yes/No | | | Should the relying | | | | party be required to | | | | advertise compliance | | | | with specific profiles | | | | as per section 11. | | | | | | | 9. | Accepted association | Set of HMAC-SHA1/HMAC-SHA256 | | | types. What section | | | | 7.3. association types | | | | the IDP agrees to use | | | | for signatures. | | | | | | | 10. | Association must be | One of Yes/No | | | over secure channel. | | | | Whether the 7.4.1 | | | | request must take | | | | place on a secure | | | | channel. | | +--------+------------------------+---------------------------------+ Identified security variants. Table 1 Granqvist [Page 11] OpenID Authentication Security Profiles September 2006 9. Profiles The following section specifies two profiles "A" and "B" as examples. The identifier of these profiles are URLs that appends to http://openid.net/authn/2.0/. This memo uses names like "A" and "B" tather than"low security" and "medium security" as such distinctions carry implications and liabilities. There is also a risk of security creep that forces definitions to change over time -- what is now 'medium security' could be 'low security' in a few years, and possibly 'useless security' in yet another few years. But the definition will be stuck as 'medium security' forever. 9.1. Profile A The identifier for this profile is http://openid.net/authn/2.0/A These are the profile settings as they relate to Section 9 . +--------+-----------------------+ | Number | Values | +--------+-----------------------+ | 1. | Yes | | | | | 2. | Yes | | | | | 3. | Http/Https/XRI | | | | | 4. | Yes | | | | | 5. | No | | | | | 6. | No | | | | | 7. | DH-SHA1/DH-SHA256 | | | | | 8. | No | | | | | 9. | HMAC-SHA1/HMAC-SHA256 | | | | | 10. | No | +--------+-----------------------+ Table 2 Granqvist [Page 12] OpenID Authentication Security Profiles September 2006 9.2. Profile B The identifier for this profile is http://openid.net/authn/2.0/B These are the profile settings as they relate to Section 9. +--------+-----------------------+ | Number | Values | +--------+-----------------------+ | 1. | Yes | | | | | 2. | No | | | | | 3. | Http/Https/XRI | | | | | 4. | Yes | | | | | 5. | No | | | | | 6. | No | | | | | 7. | No-encryption | | | | | 8. | No | | | | | 9. | HMAC-SHA1/HMAC-SHA256 | | | | | 10. | Yes | +--------+-----------------------+ Table 3 Granqvist [Page 13] OpenID Authentication Security Profiles September 2006 10. Usage Intention to following one or several profiles defined in this memo or in other location can be advertised. Section 4.2. of the OpenID protocol defines the protocol discovery phase in which parties find out properties about each other. Adherence to one or several profiles should be advertised via this mechanism, including intendet expiry of such adherence. Granqvist [Page 14] OpenID Authentication Security Profiles September 2006 11. Security considerations TODO. Granqvist [Page 15] OpenID Authentication Security Profiles September 2006 12. IANA considerations This document has no actions for IANA. Granqvist [Page 16] OpenID Authentication Security Profiles September 2006 13. Normative References [OPENID] Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, "OpenID Authentication 2.0", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Granqvist [Page 17] OpenID Authentication Security Profiles September 2006 Author's Address Hans Granqvist VeriSign, Inc. 487 East Middlefield Rd. Mountain View, CA 94043 US Granqvist [Page 18]