OpenID authentication security profiles
Granqvist, Hans
hgranqvist at verisign.com
Tue Sep 12 16:07:06 UTC 2006
Hi All,
As a follow up to the old mailing list regarding proposed
security profiles, here is a slightly modified proposal
defining a mechanism to communicate security properties of
OpenID auth 2.0.
The doc identifies a number of security variants in the
protocol, and then a mechanism to define security
profiles that encapsulate the set of all such variants.
I have tried to capture security variants that are important
for RP/IDP parties to agree on, both now and as far ahead
as I can predict in the future.
The intention is not to decide *which* profiles make sense,
since there are many different ways of using and deploying
OpenID Authentication, but rather *how* it is possible to
create and communicate profiles. The parties involved then
have to decide on their own with which profiles to comply.
My hopes are that we can use this document as a starting
point to make it possible to define such profiles and that
we can start discussing the listed security properties.
(I'm not sure where this document should live. For now, send
your comments to this list and I will update the document as
needed.)
Thanks,
Hans Granqvist
OpenID authentication security profiles
draft-hgranqvist-openid-auth-security-profiles-00.txt
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
2. Requirements notation
3. Definitions and Terminology
4. Goals
5. Non-goals
6. Requirements
7. Conventions
8. Security variants
9. Profiles
9.1. Profile A
9.2. Profile B
10. Usage
11. Security considerations
12. IANA considerations
13. Normative References
Author's Address
1. Introduction
The OpenID Authentication 2.0 [1] 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 passwords.
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 mechanisms 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.
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 [2].
3. Definitions and Terminology
TODO.
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 [1].
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.
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.
6. Requirements
TODO.
7. Conventions
It is assumed an OpenID Authentication 2.0 [1] party will advertise
its intended profile compliance via the service discovery phase by
using the service types defined in this memo.
8. Security variants
The following section describes the identified security variants in
the OpenID Authentication 2.0 [1] protocol.
This table defines the security variants and the expected values.
References are to 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 insecure | 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. | |
| | | |
| 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
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" rather 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
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
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 intended expiry of such adherence.
11. Security considerations
TODO.
12. IANA considerations
This document has no actions for IANA.
13. Normative References
[1] Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, "OpenID
Authentication 2.0",
<http://openid.net/specs/openid-authentication-2_0-09.html>.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Author's Address
Hans Granqvist
VeriSign, Inc.
487 East Middlefield Rd.
Mountain View, CA 94043
US
More information about the specs
mailing list