OpenID authentication security profiles

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 (Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “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.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

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 (Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “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.

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 (Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “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.

8.  Security variants

The following section describes the identified security variants in the OpenID Authentication 2.0 (Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “OpenID Authentication 2.0,” .) [OPENID] protocol.

This table defines the security variants and the expected values. References are tp the OpenID specification.

Identified security variants.

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 (Profiles) .

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 (Profiles).

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.

11.  Security considerations

TODO.

12.  IANA considerations

This document has no actions for IANA.

13. Normative References

Author's Address