draft-ietf-kitten-sasl-openid-08.txt   rfc6616.txt 
Network Working Group E. Lear Internet Engineering Task Force (IETF) E. Lear
Internet-Draft Cisco Systems GmbH Request for Comments: 6616 Cisco Systems GmbH
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: August 25, 2012 Nokia Siemens Networks ISSN: 2070-1721 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
February 24, 2012 May 2012
A SASL & GSS-API Mechanism for OpenID A Simple Authentication and Security Layer (SASL) and
draft-ietf-kitten-sasl-openid-08 Generic Security Service Application Program Interface (GSS-API)
Mechanism for OpenID
Abstract Abstract
OpenID has found its usage on the Internet for Web Single Sign-On. OpenID has found its usage on the Internet for Web Single Sign-On.
Simple Authentication and Security Layer (SASL) and the Generic Simple Authentication and Security Layer (SASL) and the Generic
Security Service Application Program Interface (GSS-API) are Security Service Application Program Interface (GSS-API) are
application frameworks to generalize authentication. This memo application frameworks to generalize authentication. This memo
specifies a SASL and GSS-API mechanism for OpenID that allows the specifies a SASL and GSS-API mechanism for OpenID that allows the
integration of existing OpenID Identity Providers with applications integration of existing OpenID Identity Providers with applications
using SASL and GSS-API. using SASL and GSS-API.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 25, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6616.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for application protocols other than HTTP . 4 2. Applicability for Application Protocols other than HTTP . . . 4
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8
3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 10 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 11
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 11 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14
6.2. RP redirected by malicious URL to take an improper action 14 6.2. RP Redirected by Malicious URL to Take an Improper
Action . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
OpenID [OpenID] is a web-based three-party protocol that provides a OpenID 2.0 [OpenID] is a web-based three-party protocol that provides
means for a user to offer identity assertions and other attributes to a means for a user to offer identity assertions and other attributes
a web server (Relying Party) via the help of an identity provider. to a web server (Relying Party) via the help of an identity provider.
The purpose of this system is to provide a way to verify that an end The purpose of this system is to provide a way to verify that an end
user controls an identifier. user controls an identifier.
Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is Simple Authentication and Security Layer (SASL) [RFC4422] is used by
used by application protocols such IMAP [RFC3501], POP [RFC1939] and application protocols such as IMAP [RFC3501], Post Office Protocol
XMPP [RFC6120], with the goal of modularizing authentication and (POP) [RFC1939], and Extensible Messaging and Presence Protocol
(XMPP) [RFC6120], with the goal of modularizing authentication and
security layers, so that newer mechanisms can be added as needed. security layers, so that newer mechanisms can be added as needed.
This memo specifies just such a mechanism. This memo specifies just such a mechanism.
The Generic Security Service Application Program Interface (GSS-API) The Generic Security Service Application Program Interface (GSS-API)
[RFC2743] provides a framework for applications to support multiple [RFC2743] provides a framework for applications to support multiple
authentication mechanisms through a unified interface. This document authentication mechanisms through a unified interface. This document
defines a pure SASL mechanism for OpenID, but it conforms to the new defines a pure SASL mechanism for OpenID, but it conforms to the new
bridge between SASL and the GSS-API called GS2 [RFC5801]. This means bridge between SASL and the GSS-API called GS2 [RFC5801]. This means
that this document defines both a SASL mechanism and a GSS-API that this document defines both a SASL mechanism and a GSS-API
mechanism. Implementors of the SASL component MAY implement the GSS- mechanism. Implementors of the SASL component MAY implement the GSS-
API interface as well. API interface as well.
This mechanism specifies interworking between SASL and OpenID in This mechanism specifies interworking between SASL and OpenID in
order to assert identity and other attributes to relying parties. As order to assert identity and other attributes to Relying Parties. As
such, while SASL servers (as relying parties) will advertise SASL such, while SASL servers (as Relying Parties) will advertise SASL
mechanisms, clients will select the OpenID mechanism. mechanisms, clients will select the OpenID mechanism.
The OpenID mechanism described in this memo aims to re-use the OpenID The OpenID mechanism described in this memo aims to reuse the OpenID
mechanism to the maximum extent and therefore does not establish a mechanism to the maximum extent and therefore does not establish a
separate authentication, integrity and confidentiality mechanism. It separate authentication, integrity, and confidentiality mechanism.
is anticipated that existing security layers, such as Transport Layer It is anticipated that existing security layers, such as Transport
Security (TLS) [RFC5246], continue to be used. Minimal changes are Layer Security (TLS) [RFC5246], continue to be used. Minimal changes
required to non-web applications, as most of the transaction occurs are required to non-web applications, as most of the transaction
through a normal web browser. Hence, this specification is only occurs through a normal web browser. Hence, this specification is
appropriate for use when such a browser is available. only appropriate for use when such a browser is available.
Figure 1 describes the interworking between OpenID and SASL. This Figure 1 describes the interworking between OpenID and SASL. This
document requires enhancements to the Relying Party and to the Client document requires enhancements to the Relying Party and to the Client
(as the two SASL communication end points) but no changes to the (as the two SASL communication end points), but no changes to the
OpenID Provider (OP) are necessary. To accomplish this goal indirect OpenID Provider (OP) are necessary. To accomplish this goal,
messaging required by the OpenID specification is tunneled through indirect messaging required by the OpenID specification is tunneled
the SASL/GSS-API mechanism. through the SASL/GSS-API mechanism.
+-----------+ +-----------+
| Relying | | Relying |
>| Party / | >| Party / |
/ | SASL | / | SASL |
// | Server | // | Server |
// +-----------+ // +-----------+
// ^ // ^
OpenID // +--|--+ OpenID // +--|--+
// | O| | G // | O| | G
/ S | p| | S / S | p| | S
// A | e| | S // A | e| | S
// S | n| | A // S | n| | A
// L | I| | P // L | I| | P
// | D| | I // | D| | I
</ +--|--+ </ +--|--+
+------------+ v +------------+ v
| | +----------+ | | +----------+
| OpenID | OpenID | | | OpenID | OpenID | |
| Provider |<--------------->| Client | | Provider |<--------------->| Client |
| | | | | | | |
+------------+ +----------+ +------------+ +----------+
Figure 1: Interworking Architecture
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terms used in the The reader is assumed to be familiar with the terms used in the
OpenID 2.0 specification. OpenID 2.0 specification.
1.2. Applicability 1.2. Applicability
Because this mechanism transports information that should not be Because this mechanism transports information that should not be
controlled by an attacker, the OpenID mechanism MUST only be used controlled by an attacker, the OpenID mechanism MUST only be used
over channels protected by TLS, and the client MUST successfully over channels protected by TLS, and the client MUST successfully
validate the server certificate. [RFC5280][RFC6125] validate the server certificate [RFC5280][RFC6125].
2. Applicability for application protocols other than HTTP 2. Applicability for Application Protocols other than HTTP
OpenID was originally envisioned for HTTP [RFC2616] and HTML [W3C OpenID was originally envisioned for HTTP- [RFC2616] and HTML-based
.REC-html401-19991224] based communications, and with the associated [W3C.REC-html401-19991224] communications, and with the associated
semantic, the idea being that the user would be redirected by the semantic; the idea being that the user would be redirected by the
Relying Party to an identity provider who authenticates the user, and Relying Party (RP) to an identity provider (IdP) who authenticates
then sends identity information and other attributes (either directly the user and then sends identity information and other attributes
or indirectly) to the Relying Party. The identity provider in the (either directly or indirectly) to the Relying Party. The identity
OpenID specifications is referred to as an OpenID Provider (OP). The provider in the OpenID specifications is referred to as an OpenID
actual protocol flow can be found in Section 3 of the OpenID 2.0 Provider (OP). The actual protocol flow can be found in Section 3 of
specification [OpenID]. The reader is strongly encouraged to be the OpenID 2.0 specification [OpenID]. The reader is strongly
familiar with the specification before continuing. encouraged to be familiar with that specification before continuing.
When considering that flow in the context of SASL, we note that while When considering that flow in the context of SASL, we note that while
the RP and the client both need to change their code to implement the RP and the client both need to change their code to implement
this SASL mechanism, it is a design constraint that the OP behavior this SASL mechanism, it is a design constraint that the OP behavior
remain untouched, in order for implementations to interoperate with remain untouched, in order for implementations to interoperate with
existing IdPs. Hence, an analog flow that interfaces the three existing IdPs. Hence, an analog flow that interfaces the three
parties needs to be created. In the analog, we note that unlike a parties needs to be created. In the analog, we note that unlike a
web server, the SASL server already has some sort of session web server, the SASL server already has some sort of session
(probably a TCP connection) established with the client. However, it (probably a TCP connection) established with the client. However, it
may be necessary for a SASL client to invoke to another application. may be necessary for a SASL client to invoke to another application.
This will be discussed below. By doing so, we externalize much of This will be discussed below. By doing so, we externalize much of
the authentiction from SASL. the authentication from SASL.
The steps are listed below: The steps are listed below:
1. The SASL server advertises support for the SASL OpenID mechanism 1. The SASL server advertises support for the SASL OpenID mechanism
to the client. to the client.
2. The client initiates a SASL authentication and transmits the 2. The client initiates a SASL authentication and transmits the
User-Supplied Identifier as its first response. The SASL User-Supplied Identifier as its first response. The SASL
mechanism is client-first, and as explained in [RFC4422] the mechanism is client-first, and, as explained in [RFC4422], the
server will send an empty challenge if needed. server will send an empty challenge if needed.
3. After normalizing the User-Supplied Identifier as discussed in 3. After normalizing the User-Supplied Identifier as discussed in
[OpenID], the Relying Party performs discovery on it and [OpenID], the Relying Party performs discovery on it and
establishes the OP Endpoint URL that the end user uses for establishes the OP Endpoint URL that the end user uses for
authentication. authentication.
4. The Relying Party and the OP optionally establish an association 4. The Relying Party and the OP optionally establish an association
-- a shared secret established using Diffie-Hellman Key Exchange. -- a shared secret established using Diffie-Hellman Key
The OP uses an association to validate those messages through the Exchange. The OP uses an association to validate those messages
use of an HMAC; this removes the need for subsequent direct through the use of a Hashed Message Authentication Code (HMAC);
requests to verify the signature after each authentication this removes the need for subsequent direct requests to verify
request/response. the signature after each authentication request/response.
5. The Relying Party transmits an authentication request to the OP 5. The Relying Party transmits an authentication request to the OP
to obtain an assertion in the form of an indirect request. These to obtain an assertion in the form of an indirect request.
messages are passed through the client rather than directly These messages are passed through the client rather than
between the RP and the OP. OpenID defines two methods for directly between the RP and the OP. OpenID defines two methods
indirect communication, namely HTTP redirects and HTML form for indirect communication -- namely, HTTP redirects and HTML
submission. Both mechanisms are not directly applicable for form submission. Neither mechanism is directly applicable for
usage with SASL. To ensure that a standard OpenID 2.0 capable OP usage with SASL. To ensure that an OP that is OpenID 2.0
can be used a new method is defined in this document that capable can be used, a new method is defined in this document
requires the OpenID message content to be encoded using a that requires the OpenID message content to be encoded using a
Universal Resource Idenitifier (URI). [RFC3986] Note that any Universal Resource Identifier (URI) [RFC3986]. Note that any
Internationalized Resource Identifiers (IRIs) must be normalized Internationalized Resource Identifiers (IRIs) must be normalized
to URIs by the SASL client, as specified in [RFC3987], prior to to URIs by the SASL client, as specified in [RFC3987], prior to
transmitting them to the SASL server. transmitting them to the SASL server.
6. The SASL client now sends an response consisting of "=", to 6. The SASL client now sends a response consisting of "=" to the
indicate that authentication continues via the normal OpenID server, to indicate that authentication continues via the normal
flow. OpenID flow.
7. At this point the client application MUST construct a URL 7. At this point, the client application MUST construct a URL
containing the content received in the previous message from the containing the content received in the previous message from the
RP. This URL is transmitted to the OP either by the SASL client RP. This URL is transmitted to the OP by either the SASL client
application or an appropriate handler, such as a browser. application or an appropriate handler, such as a browser.
8. Next the client optionally authenticates to the OP and then 8. Next, the end user optionally authenticates to the OP and then,
approves or disapproves authentication to the Relying Party. For depending on the OP, may approve or disapprove authentication to
reasons of its own the OP has the option of not authenticating a the Relying Party. For reasons of its own, the OP has the
request. The manner in which the end user is authenticated to option of not authenticating a request. The manner in which the
their respective OP and any policies surrounding such end user is authenticated to their respective OP and any
authentication is out of scope of OpenID and and hence also out policies surrounding such authentication are out of scope of
of scope for this specification. This step happens out of band OpenID and, hence, also out of scope for this specification.
from SASL. This step happens out of band from SASL.
9. The OP will convey information about the success or failure of 9. The OP will convey information about the success or failure of
the authentication phase back to the RP, again using an indirect the authentication phase back to the RP, again using an indirect
response via the client browser or handler. The client transmits response via the client browser or handler. The client
over HTTP/TLS the redirect of the OP result to the RP. This step transmits to the RP (over HTTP/TLS) the redirect of the OP
happens out of band from SASL. result. This step happens out of band from SASL.
10. The RP MAY send an OpenID check_authentication request directly 10. The RP MAY send an OpenID check_authentication request directly
to the OP, if no association has been established, and the OP to the OP, if no association has been established, and the OP
should respond. Again this step happens out of band from SASL. should respond. Again, this step happens out of band from SASL.
11. The SASL server sends an appropriate SASL response to the 11. The SASL server sends an appropriate SASL response to the
client, with optional Open Simple Registry (SREG) attributes. client, with optional Open Simple Registry (SREG) attributes.
SASL Serv. RP/Client OP SASL Serv. RP/Client OP
|>-----(1)----->| | Advertisement |>-----(1)----->| | Advertisement
| | | | | |
|<-----(2)-----<| | Initiation |<-----(2)-----<| | Initiation
| | | | | |
|> - - (3) - - - - - - - - - ->| Discovery |> - - (3) - - - - - - - - - ->| Discovery
| | | |
|>- - -(4)- - - - - - - - - - >| Association |>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <| |<- - -(4)- - - - - - - - - - <|
| | | | | |
|>-----(5)----->| | Indirect Auth Request |>-----(5)----->| | Indirect Auth Request
| | | | | |
|<-----(6)-----<| | Client "=" Response |<-----(6)-----<| | Client "=" Response
| | | | | |
| |>- - (7)- - ->| Client GET to the OP (ext) | |>- - (7)- - ->| Client GET to the OP (ext.)
| | | | | |
| |<- - (8)- - ->| Client / OP Auth. (ext.) | |<- - (8)- - ->| Client / OP Auth. (ext.)
| | | | | |
|<- - -(9)- - - + - - - - - - <| HTTPs Indirect id_res |<- - -(9)- - - + - - - - - - <| HTTPS Indirect id_res
| | | | | |
|<- - -(10)- - - - - - - - - ->| Optional check_authenticate |<- - -(10)- - - - - - - - - ->| Optional
| | | check_authentication
| | | | | |
|>-----(11)---->| | SASL completion with status |>-----(11)---->| | SASL completion with status
----- = SASL ----- = SASL
- - - = HTTPS - - - = HTTPS
Note the directionality in SASL is such that the client MUST send the Note the directionality in SASL is such that the client MUST send the
"=" response. Specifically, the SASL client processes the redirect "=" response. Specifically, the SASL client processes the redirect
and then awaits a final SASL decision, while the rest of the OpenID and then awaits a final SASL decision, while the rest of the OpenID
authentication process continues. authentication process continues.
2.1. Binding SASL to OpenID in the Relying Party 2.1. Binding SASL to OpenID in the Relying Party
OpenID is meant to be used in serial within the web, where browser OpenID is meant to be used in serial within the web, where browser
cookies are easily accessible. As such, there are no transaction-ids cookies are easily accessible. As such, there are no transaction IDs
within the protocol. To ensure that a specific request is bound, and within the protocol. To ensure that a specific request is bound, and
in particular to ease interprocess communication, the relying party in particular to ease inter-process communication, the Relying Party
MUST encode a nonce or transaction-id in the URIs it transmits MUST encode a nonce or transaction ID in the URIs it transmits
through the client for success or failure, either as a base URI or through the client for success or failure, as either a base URI or
fragment component to the "return_to" URI. This value is to be used fragment component to the "return_to" URI. This value is to be used
to uniquely identify each authentication transaction. The nonce to uniquely identify each authentication transaction. The nonce
value MUST be at least 2^32 large and large enough to handle well in value MUST be at least 2^32 bits and large enough to handle well in
excess of the number of concurrent transactions a SASL server shall excess of the number of concurrent transactions a SASL server shall
see. see.
2.2. Discussion 2.2. Discussion
As mentioned above OpenID is primarily designed to interact with web-
based applications. Portions of the authentication stream are only As mentioned above, OpenID is primarily designed to interact with
defined in the crudest sense. That is, when one is prompted to web-based applications. Portions of the authentication stream are
only defined in the crudest sense. That is, when one is prompted to
approve or disapprove an authentication, anything that one might find approve or disapprove an authentication, anything that one might find
on a browser is allowed, including JavaScript, fancy style-sheets, on a browser is allowed, including JavaScript, complex style-sheets,
etc. Because of this lack of structure, implementations will need to etc. Because of this lack of structure, implementations will need to
invoke a fairly rich browser in order to ensure that the invoke a rich browser in order to ensure that the authentication can
authentication can be completed. be completed.
Once there is an outcome, the SASL server needs to know about it. Once there is an outcome, the SASL server needs to know about it.
The astute will hopefully by now have noticed an "=" client SASL The astute reader will hopefully by now have noticed an "=" client
response. This is not to say that nothing is happening, but rather SASL response. This is not to say that nothing is happening, but
that authentication flow has shifted from SASL and the client rather that authentication flow has shifted from SASL and the client
application to OpenID within the browser, and will return to the application to OpenID within the browser, and it will return to the
client application when the server has an outcome to hand to the client application when the server has an outcome to hand to the
client. The alternative to this flow would be some sort of signal client. The alternative to this flow would be some sort of signal
from the HTML browser to the SASL client of the results that would in from the HTML browser to the SASL client of the results that would in
turn be passed to the SASL server. The inter-process communication turn be passed to the SASL server. The inter-process communication
issue this raises is substantial. Better, we conclude, to issue this raises is substantial. Better, we conclude, to
externalize the authentication to the browser, and have an "=" client externalize the authentication to the browser and have an "=" client
response. response.
3. OpenID SASL Mechanism Specification 3. OpenID SASL Mechanism Specification
This section specifies the details of the OpenID SASL mechanism. This section specifies the details of the OpenID SASL mechanism.
Recall section 5 of [RFC4422] for what needs to be described here. Recall Section 5 of [RFC4422] for what needs to be described here.
The name of this mechanism "OPENID20". The mechanism is capable of The name of this mechanism is "OPENID20". The mechanism is capable
transferring an authorization identity (via "gs2-header"). The of transferring an authorization identity (via "gs2-header"). The
mechanism does not offer a security layer. mechanism does not offer a security layer.
The mechanism is client-first. The first mechanism message from the The mechanism is client-first. The first mechanism message is from
client to the server is the "initial-response" described below. As the client to the server, and it is the "initial-response" described
described in [RFC4422], if the application protocol does not support below. As described in [RFC4422], if the application protocol does
sending a client-response together with the authentication request, not support sending a client-response together with the
the server will send an empty server-challenge to let the client authentication request, the server will send an empty server-
begin. challenge to let the client begin.
The second mechanism message is from the server to the client, the The second mechanism message is from the server to the client, and it
"authentication_request" described below. is the "authentication_request" described below.
The third mechanism message is from client to the server, and is the The third mechanism message is from client to the server, and it is
fixed message consisting of "=". the fixed message consisting of "=".
The fourth mechanism message is from the server to the client, The fourth mechanism message is from the server to the client,
described below as "outcome_data" (with SREG attributes), sent as described below as "outcome_data" (with SREG attributes), sent as
additional data when indicating a successful outcome. additional data when indicating a successful outcome.
3.1. Initiation 3.1. Initiation
A client initiates an OpenID authentication with SASL by sending the A client initiates an OpenID authentication with SASL by sending the
GS2 header followed by the URI, as specified in the OpenID GS2 header followed by the URI, as specified in the OpenID
specification. specification.
initial-response = gs2-header Auth-Identifier The ABNF [RFC5234] syntax is as follows:
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI ; Identifier is specified in initial-response = gs2-header Auth-Identifier
; Sec. 7.2 of the OpenID 2.0 spec. Auth-Identifier = Identifier ; authentication identifier
Identifier = URI ; Identifier is specified in
; Sec. 7.2 of the OpenID 2.0 spec.
The syntax and semantics of the "gs2-header" are specified in The syntax and semantics of the "gs2-header" are specified in
[RFC5801], and we use it here with the following limitations: The [RFC5801], and we use it here with the following limitations: The
"gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n" "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n"
because channel binding is not supported by this mechanism. because channel binding is not supported by this mechanism.
URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0] URI is specified in [RFC3986]. Extensible Resource Identifiers
(XRIs) [XRI2.0] MUST NOT be used.
3.2. Authentication Request 3.2. Authentication Request
The SASL Server sends the URL resulting from the OpenID The SASL server sends the URL resulting from the OpenID
authentication request, containing an "openid.mode" of either authentication request, containing an "openid.mode" of either
"checkid_immediate" or "checkid_setup", as specified in Section 9.1 "checkid_immediate" or "checkid_setup", as specified in Section 9.1
of the OpenID 2.0 specification. of the OpenID 2.0 specification [OpenID].
authentication-request = URI authentication-request = URI
As part of this request, the SASL server MUST append a unique As part of this request, the SASL server MUST append a unique
transaction id to the "return_to" portion of the request. The form transaction ID to the "return_to" portion of the request. The form
of this transaction is left to the RP to decide, but SHOULD be large of this transaction is left to the RP to decide, but it SHOULD be
enough to be resistant to being guessed or attacked. large enough to be resistant to being guessed or attacked.
The client now sends that request via an HTTP GET to the OP, as if The client now sends that request via an HTTP GET to the OP, as if
redirected to do so from an HTTP server. redirected to do so from an HTTP server.
The client MUST handle both user authentication to the OP and The client MUST handle both user authentication to the OP and
confirmation or rejection of the authentiation by the RP via this confirmation or rejection of the authentication by the RP via this
SASL mechanism. SASL mechanism.
After all authentication has been completed by the OP, and after the After all authentication has been completed by the OP, and after the
response has been sent to the client, the client will relay the response has been sent to the client, the client will relay the
response to the Relying Party via HTTP/TLS, as specified previously response to the Relying Party via HTTP/TLS, as specified previously
in the transaction ("return_to"). in the transaction ("return_to").
3.3. Server Response 3.3. Server Response
The Relying Party now validates the response it received from the The Relying Party now validates the response it received from the
client via HTTP/TLS, as specified in the OpenID specification, using client via HTTP/TLS, as specified in the OpenID specification, using
the "return_to" URI given previsiously in the transaction. the "return_to" URI given previously in the transaction.
The response by the Relying Party constitutes a SASL mechanism The response by the Relying Party constitutes a SASL mechanism
outcome, and SHALL be used to set state in the server accordingly, outcome, and it SHALL be used to set state in the server accordingly.
and it SHALL be used by the server to report that state to the SASL Also, it SHALL be used by the server to report that state to the SASL
client as described in [RFC4422] Section 3.6. In the additional client as described in Section 3.6 of [RFC4422]. In the additional
data, the server MAY include OpenID Simple Registry (SREG) attributes data, the server MAY include OpenID Simple Registry (SREG) attributes
that are listed in Section 4 of [SREG1.0].SREG attributes are encoded that are listed in Section 4 of [SREG1.0]. SREG attributes are
as follows: encoded as follows:
1. Strip "openid.sreg." from each attribute name. 1. Strip "openid.sreg." from each attribute name.
2. Treat the concatentation of results as URI parameters that are 2. Treat the concatenation of results as URI parameters that are
separated by an ampersand (&) and encode as one would a URI, separated by an ampersand (&) and encode as one would a URI,
absent the scheme, authority, and the question mark. absent the scheme, authority, and the question mark.
For example: email=lear@example.com&fullname=Eliot%20Lear For example: email=lear@example.com&fullname=Eliot%20Lear
More formally: More formally:
outcome-data = [ sreg-avp *( "," sreg-avp ) ] outcome-data = [ sreg-avp *( "," sreg-avp ) ]
sreg-avp = sreg-attr "=" sreg-val sreg-avp = sreg-attr "=" sreg-val
sreg-attr = sreg-word sreg-attr = sreg-word
sreg-val = sreg-word sreg-val = sreg-word
sreg-word = 1*( unreserved / pct-encoded ) sreg-word = 1*( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3986 ; pct-encoded from Section 2.1 of RFC 3986
; unreserved from Section 2.3 of RFC 3986 ; unreserved from Section 2.3 of RFC 3986
A client who does not support SREG MUST ignore SREG attributes sent A client who does not support SREG MUST ignore SREG attributes sent
by the server. Similarly, a client MUST ignore unknown attributes. by the server. Similarly, a client MUST ignore unknown attributes.
In the case of failures, the response MUST follow this syntax: In the case of failures, the response MUST follow this syntax:
outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp ) outcome-data = "openid.error" "=" sreg-val *( "," sregp-avp )
3.4. Error Handling 3.4. Error Handling
[RFC4422] Section 3.6 explicitly prohibits additional information in Section 3.6 of [RFC4422] explicitly prohibits additional information
an unsuccessful authentication outcome. Therefore, the openid.error in an unsuccessful authentication outcome. Therefore, the
and openid.error_code are to be sent as an additional challenge in openid.error and openid.error_code are to be sent as an additional
the event of an unsuccessful outcome. In this case, as the protocol challenge in the event of an unsuccessful outcome. In this case, as
is lock step, the client will follow with an additional exchange the protocol is in lockstep, the client will follow with an
containing "=", after which the server will respond with an additional exchange containing "=", after which the server will
application-level outcome. respond with an application-level outcome.
4. OpenID GSS-API Mechanism Specification 4. OpenID GSS-API Mechanism Specification
This section and its sub-sections and appropriate references of it
not referenced elsewhere in this document are not required for SASL This section MUST be observed to properly implement the GSS-API
implementors, but this section MUST be observed to implement the GSS- mechanism that is described below.
API mechanism discussed below.
The OpenID SASL mechanism is actually also a GSS-API mechanism. The The OpenID SASL mechanism is actually also a GSS-API mechanism. The
OpenID user takes the role of the GSS-API Initiator and the OpenID OpenID user takes the role of the GSS-API Initiator and the OpenID
Relying Party takes the role of the GSS-API Acceptor. The OpenId Relying Party takes the role of the GSS-API Acceptor. The OpenID
Provider does not have a role in GSS-API, and is considered an Provider does not have a role in GSS-API and is considered an
internal matter for the OpenID mechanism. The messages are the same, internal matter for the OpenID mechanism. The messages are the same,
but a) the GS2 header on the client's first message and channel but a) the GS2 header on the client's first message and channel
binding data is excluded when OpenID is used as a GSS-API mechanism, binding data are excluded when OpenID is used as a GSS-API mechanism,
and b) the RFC2743 section 3.1 initial context token header is and b) the initial context token header (described in Section 3.1 of
prefixed to the client's first authentication message (context RFC 2743) is prefixed to the client's first authentication message
token). (context token).
The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see The GSS-API OID for the OpenID 2.0 mechanism is 1.3.6.1.5.5.16 (see
IANA considerations). Section 7 for more information). The DER encoding of the OID is 0x2b
0x06 0x01 0x05 0x05 0x10.
OpenID security contexts MUST have the mutual_state flag OpenID security contexts MUST have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential
delegation, therefore OpenID security contexts MUST have the delegation; therefore, OpenID security contexts MUST have the
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
The mutual authentication property of this mechanism relies on The mutual authentication property of this mechanism relies on
successfully comparing the TLS server identity with the negotiated successfully comparing the TLS server identity with the negotiated
target name. Since the TLS channel is managed by the application target name. Since the TLS channel is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to outside of the GSS-API mechanism, the mechanism itself is unable to
confirm the name while the application is able to perform this confirm the name while the application is able to perform this
comparison for the mechanism. For this reason, applications MUST comparison for the mechanism. For this reason, applications MUST
match the TLS server identity with the target name, as discussed in match the TLS server identity with the target name, as discussed in
[RFC6125]. [RFC6125].
The OpenID mechanism does not support per-message tokens or The OpenID mechanism does not support per-message tokens or
GSS_Pseudo_random. GSS_Pseudo_random.
The [RFC5587] mechanism attributes for this mechanism are The [RFC5587] mechanism attributes for this mechanism are
GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT. GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT.
4.1. GSS-API Principal Name Types for OpenID 4.1. GSS-API Principal Name Types for OpenID
OpenID supports standard generic name syntaxes for acceptors such as OpenID supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]).
OpenID supports only a single name type for initiators: OpenID supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
OpenID. OpenID.
OpenID name normalization is covered by the OpenID specification, see OpenID name normalization is covered by the OpenID specification; see
[OpenID] section 7.2. Section 7.2 of [OpenID].
The query, display, and exported name syntaxes for OpenID principal The query, display, and exported name syntaxes for OpenID principal
names are all the same. There are no OpenID-specific name syntaxes names are all the same. There are no OpenID-specific name syntaxes
-- applications should use generic GSS-API name types such as -- applications should use generic GSS-API name types such as
GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see Section 4 of
Section 4). The exported name token does, of course, conform to [RFC2743]). The exported name token does, of course, conform to
[RFC2743], Section 3.2, but the "NAME" part of the token should be Section 3.2 of [RFC2743], but the "NAME" part of the token should be
treated as a potential input string to the OpenID name normalization treated as a potential input string to the OpenID name normalization
rules. For example, the OpenID identifier "https://openid.example/" rules. For example, the OpenID Identifier "https://openid.example/"
will have a GSS_C_NT_USER_NAME value of "https://openid.example/". will have a GSS_C_NT_USER_NAME value of "https://openid.example/".
GSS-API name attributes may be defined in the future to hold the GSS-API name attributes may be defined in the future to hold the
normalized OpenID Identifier. normalized OpenID Identifier.
5. Example 5. Example
Suppose one has an OpenID of https://openid.example, and wishes to Suppose a user has an OpenID of https://openid.example and wishes to
authenticate his IMAP connection to mail.example (where .example is authenticate his IMAP connection to mail.example (where .example is
the top level domain specified in [RFC2606]). The user would input the top-level domain specified in [RFC2606]). The user would input
his Openid into his mail user agent, when he configures the account. his OpenID into his mail user agent when he configures the account.
In this case, no association is attempted between the OpenID RP and In this case, no association is attempted between the OpenID RP and
the OP. The client will make use of the return_to attribute to the OP. The client will make use of the "return_to" attribute to
capture results of the authentication to be redirected to the server. capture results of the authentication to be redirected to the server.
Note the use of [RFC4959] for initial response. The authentication Note the use of [RFC4959] for the initial response. The
on the wire would then look something like the following: authentication on the wire would then look something like the
following:
(S = IMAP server; C = IMAP client) (S = IMAP server; C = IMAP client)
C: < connects to IMAP port> C: < connects to IMAP port>
S: * OK S: * OK
C: C1 CAPABILITY C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8= C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,https://openid.example/". [ This is the base64 encoding of "n,,https://openid.example/".
Server performs discovery on http://openid.example/ ] Server performs discovery on http://openid.example/ ]
S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1 S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1 bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
5pZC5tb2RlPWNoZWNraWRfc2V0dXA= 5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
[ This is the base64 encoding of "https://openid.example/openid/ [ This is the base64 encoding of "https://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0 ?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c &openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/ &openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/ &openid.identity=https://openid.example/
&openid.realm=imap://mail.example &openid.realm=imap://mail.example
&openid.mode=checkid_setup" &openid.mode=checkid_setup"
with line breaks and spaces added here for readibility. with line breaks and spaces added here for readability.
] ]
C: PQ== C: PQ==
[ The client now sends the URL it received to a browser for [ The client now sends the URL it received to a browser for
processing. The user logs into https://openid.example, and processing. The user logs into https://openid.example and
agrees to authenticate imap://mail.example. A redirect is agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser who then connects to passed back to the client browser that then connects to
https://imap.example/consumer via SSL with the results. https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends the "=" From an IMAP perspective, however, the client sends the "="
response, and awaits mail.example. response, and awaits mail.example.
Server mail.example would now contact openid.example with an Server mail.example would now contact openid.example with an
openid.check_authenticate message. After that... openid.check_authentication message. After that...
] ]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy b3QlMjBMZWFy
[ Here the IMAP server has returned an SREG attribute of [ Here, the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear. email=lear@mail.example,fullname=Eliot%20Lear.
Line break in response added in this example for clarity. ] Line break in response added in this example for readability. ]
C: C:
[ In IMAP client must send a blank response after receiving the [ In IMAP, client must send a blank response after receiving
SREG data. ] the SREG data. ]
S: C2 OK S: C2 OK
In this example, the SASL server / RP has made use of a transaction In this example, the SASL server / RP has made use of a transaction
id 1ef888c. ID 1ef888c.
6. Security Considerations 6. Security Considerations
This section will address only security considerations associated This section will address only security considerations associated
with the use of OpenID with SASL and GSS-API. For considerations with the use of OpenID with SASL and GSS-API. For considerations
relating to OpenID in general, the reader is referred to the OpenID relating to OpenID in general, the reader is referred to the OpenID
specification and to other literature [1]. Similarly, for general specification [OpenID] and to other literature [OpReview].
SASL [RFC4422] and GSS-API [RFC5801] Security Considerations, the Similarly, for general SASL [RFC4422] and GSS-API [RFC5801] security
reader is referred to those specifications. considerations, the reader is referred to those specifications.
6.1. Binding OpenIDs to Authorization Identities 6.1. Binding OpenIDs to Authorization Identities
As specified in [RFC4422], the server is responsible for binding As specified in [RFC4422], the server is responsible for binding
credentials to a specific authorization identity. It is therefore credentials to a specific authorization identity. It is therefore
necessary that a registration process takes place in advance that necessary that a registration process takes place in advance that
binds specific OpenIDs to specific authorization identities, or that binds specific OpenIDs to specific authorization identities, or that
only specific trusted OpenID Providers be allowed, where a mapping is only specific trusted OpenID Providers be allowed, where a mapping is
predefined. For example, it could be pre-arranged between an IdP and predefined. For example, it could be prearranged between an IdP and
RP that "https://example.com/user" maps to "user" for purposes of RP that "https://example.com/user" maps to "user" for purposes of
authorization. authorization.
6.2. RP redirected by malicious URL to take an improper action 6.2. RP Redirected by Malicious URL to Take an Improper Action
In the initial SASL client response a user or host can transmit a In the initial SASL client response, a user or host can transmit a
malicious response to the RP for purposes of taking advantage of malicious response to the RP for purposes of taking advantage of
weaknesses in the RP's OpenID implementation. It is possible to add weaknesses in the RP's OpenID implementation. It is possible to add
port numbers to the URL so that the outcome is the RP does a port port numbers to the URL so that the outcome is that the RP does a
scan of the site. The URL could contain an unauthorized host or even port scan of the site. The URL could contain an unauthorized host or
the local host. The URL could contain a protocol other than http or even the local host. The URL could contain a protocol other than
https, such as file or ftp. http or https, such as file or ftp.
One mitigation would be for RPs to have a list of authorized URI One mitigation would be for RPs to have a list of authorized URI
bases. OPs SHOULD only redirect to RPs with the same domain bases. OPs SHOULD only redirect to RPs with the same domain
component of the base URI. RPs MUST NOT automatically retry on component of the base URI. RPs MUST NOT automatically retry on
failed attempts. A log of those sites that fail SHOULD be kept, and failed attempts. A log of those sites that fail SHOULD be kept, and
limitations on queries from clients SHOULD be imposed, just as with limitations on queries from clients SHOULD be imposed, just as with
any other authentication attempt. Applications SHOULD NOT invoke any other authentication attempt. Applications SHOULD NOT invoke
browsers to communicate with OPs that they are not themselves browsers to communicate with OPs that they are not themselves
configured with. configured with.
6.3. User Privacy 6.3. User Privacy
The OP is aware of each RP that a user logs into. There is nothing The OP is aware of each RP that a user logs into. There is nothing
in the protocol to hide this information from the OP. It is not a in the protocol to hide this information from the OP. It is not a
requirement to track the visits, but there is nothing that prohibits requirement to track the visits, but there is nothing that prohibits
the collection of information. SASL servers should be aware that the collection of information. SASL servers should be aware that
OpenID Providers will be able to track - to some extent - user access OpenID Providers will be able to track -- to some extent -- user
to their services and any additional information that OP provides. access to their services and any additional information that OP
provides.
7. IANA Considerations 7. IANA Considerations
The IANA is requested to update the SASL Mechanism Registry using the IANA has updated the "SASL Mechanisms" registry using the following
following template, as described in [RFC4422]. template, as described in [RFC4422].
SASL mechanism name: OPENID20 SASL mechanism name: OPENID20
Security Considerations: See this document Security Considerations: See this document
Published specification: See this document Published specification: See this document
Person & email address to contact for further information: Authors of Person & email address to contact for further information: Authors of
this document this document
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IETF Owner/Change controller: IESG
Note: None Note: None
The IANA is further requested to assign an OID for this GSS mechanism IANA has also assigned an OID for this GSS mechanism in the "SMI
in the SMI numbers registry, with the prefix of Security for Mechanism Codes" registry, with the prefix of
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and
reference this specification in the registry. referencing this specification in the registry.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams,
Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review
and contributions. and contributions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007. December 2007, <http://specs.openid.net/auth/2.0>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2606] Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R. and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism [RFC5587] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", RFC 5587, July 2009. Inquiry APIs", RFC 5587, July 2009.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006. version 1.0", June 2006, <http://openid.net/sreg/1.0>.
[XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier
(XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs,
September 2005.
9.2. Informative References 9.2. Informative References
[RFC1939] Myers, J.G. and M.T. Rose, "Post Office Protocol - Version [OpReview] "Google Sites OpenID Reference Page",
3", STD 53, RFC 1939, May 1996. <http://sites.google.com/site/openidreview/resources>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial Simple Authentication and Security Layer (SASL) Initial
Client Response", RFC 4959, September 2007. Client Response", RFC 4959, September 2007.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Raggett, D. and I. Jacobs, "HTML 4.01 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium
REC-html401-19991224, December 1999, <http://www.w3.org/TR Recommendation REC-html401-19991224, December 1999,
/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
Appendix A. Changes
This section to be removed prior to publication.
o 04 - 07 04 - 07 address LC and review comments, including those of
Stephen Farrell, Steve Kent, and Brian Carpenter.
o 03 Clarifies messages and ordering, and replace the empty message
with a "=" message.
o 02 Address all WGLC comments.
o 01 Specific text around possible improvements for OOB browser
control in security considerations. Also talk about transaction
id.
o 00 WG -00 draft. Slight wording modifications abou design
constraints per Alexey.
o 02 Correct single (significant) error on mechanism name.
o 01 Add nonce discussion, add authorized identity, explain a
definition. Add gs2 support.
o 00 Initial Revision. [XRI2.0] Reed, D., Ed. and D. McAlpin, Ed., "Extensible Resource
Identifier (XRI) Syntax V2.0", OASIS Standard xri-syntax-
V2.0-cs, September 2005, <http://www.oasis-open.org/
committees/download.php/15376/xri-syntax-V2.0-cs.html>.
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 CH-8304 Wallisellen
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com EMail: lear@cisco.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo, 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henry Mauldin Henry Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (800) 553-6387 Phone: +1 (800) 553-6387
Email: hmauldin@cisco.com EMail: hmauldin@cisco.com
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Johan Olof Wallins vag 13
Stockholm, 113 47 171 64 Solna
SE Sweden
Email: simon@josefsson.org EMail: simon@josefsson.org
URI: http://josefsson.org/ URI: http://josefsson.org/
 End of changes. 115 change blocks. 
349 lines changed or deleted 341 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/