draft-ietf-kitten-sasl-openid-07.txt   draft-ietf-kitten-sasl-openid-08.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH Internet-Draft Cisco Systems GmbH
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: May 26, 2012 Nokia Siemens Networks Expires: August 25, 2012 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
November 23, 2011 February 24, 2012
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-07 draft-ietf-kitten-sasl-openid-08
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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2012. This Internet-Draft will expire on August 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for application protocols other than HTTP . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 7
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 9 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8
3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 10 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 10
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 11
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 17 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14
6.2. RP redirected by malicious URL to take an improper 6.2. RP redirected by malicious URL to take an improper action 14
action . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
OpenID [OpenID] is a web-based three-party protocol that provides a OpenID [OpenID] is a web-based three-party protocol that provides a
means for a user to offer identity assertions and other attributes to means for a user to offer identity assertions and other attributes to
a web server (Relying Party) via the help of an identity provider. 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] (SASL) is
used by application protocols such IMAP [RFC3501], POP [RFC1939] and used by application protocols such IMAP [RFC3501], POP [RFC1939] and
XMPP [RFC6120], with the goal of modularizing authentication and 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.
As currently envisioned, this mechanism is to allow the interworking This mechanism specifies interworking between SASL and OpenID in
between SASL and OpenID in order to assert identity and other order to assert identity and other attributes to relying parties. As
attributes to relying parties. As such, while servers (as relying such, while SASL servers (as relying parties) will advertise SASL
parties) will advertise SASL mechanisms, clients will select the mechanisms, clients will select the OpenID mechanism.
OpenID mechanism.
The OpenID mechanism described in this memo aims to re-use the OpenID The OpenID mechanism described in this memo aims to re-use 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. It
is anticipated that existing security layers, such as Transport Layer is anticipated that existing security layers, such as Transport Layer
Security (TLS) [RFC5246], will continued to be used. Minimal changes Security (TLS) [RFC5246], continue to be used. Minimal changes are
are required to non-web applications, as most of the transaction required to non-web applications, as most of the transaction occurs
occurs through a normal web browser. Hence, this specification is through a normal web browser. Hence, this specification is only
only appropriate for use when such a browser is available. 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 indirect
messaging required by the OpenID specification is tunneled through messaging required by the OpenID specification is tunneled through
the SASL/GSS-API mechanism. the SASL/GSS-API mechanism.
+-----------+ +-----------+
| | | Relying |
>| Relying | >| Party / |
/ | Party | / | SASL |
// | | // | 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 OpenID was originally envisioned for HTTP [RFC2616] and HTML [W3C
[W3C.REC-html401-19991224] based communications, and with the .REC-html401-19991224] based communications, and with the associated
associated semantic, the idea being that the user would be redirected semantic, the idea being that the user would be redirected by the
by the Relying Party to an identity provider who authenticates the Relying Party to an identity provider who authenticates the user, and
user, and then sends identity information and other attributes then sends identity information and other attributes (either directly
(either directly or indirectly) to the Relying Party. The identity or indirectly) to the Relying Party. The identity provider in the
provider in the OpenID specifications is referred to as an OpenID OpenID specifications is referred to as an OpenID Provider (OP). The
Provider (OP). The actual protocol flow can be found in Section 3 of actual protocol flow can be found in Section 3 of the OpenID 2.0
the OpenID 2.0 specification [OpenID]. The reader is strongly specification [OpenID]. The reader is strongly encouraged to be
encouraged to be familiar with the specification before continuing. familiar with the 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 authentiction from SASL.
The steps are listed below: The steps are listed below:
1. The Relying Party or SASL server advertises support for the SASL 1. The SASL server advertises support for the SASL OpenID mechanism
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 -- a shared secret established using Diffie-Hellman Key Exchange.
Exchange. The OP uses an association to sign subsequent The OP uses an association to validate those messages through the
messages and the Relying Party to verify those messages; this use of an HMAC; this removes the need for subsequent direct
removes the need for subsequent direct requests to verify the requests to verify the signature after each authentication
signature after each authentication request/response. 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. to obtain an assertion in the form of an indirect request. These
These messages are passed through the client rather than messages are passed through the client rather than directly
directly between the RP and the OP. OpenID defines two methods between the RP and the OP. OpenID defines two methods for
for indirect communication, namely HTTP redirects and HTML form indirect communication, namely HTTP redirects and HTML form
submission. Both mechanisms are not directly applicable for submission. Both mechanisms are not directly applicable for
usage with SASL. To ensure that a standard OpenID 2.0 capable usage with SASL. To ensure that a standard OpenID 2.0 capable OP
OP can be used a new method is defined in this document that can be used a new method is defined in this document that
requires the OpenID message content to be encoded using a requires the OpenID message content to be encoded using a
Universal Resource Idenitifier (URI). [RFC3986] Universal Resource Idenitifier (URI). [RFC3986] Note that any
Internationalized Resource Identifiers (IRIs) must be normalized
to URIs by the SASL client, as specified in [RFC3987], prior to
transmitting them to the SASL server.
6. The SASL client now sends an response consisting of "=", to 6. The SASL client now sends an response consisting of "=", to
indicate that authentication continues via the normal OpenID indicate that authentication continues via the normal OpenID
flow. 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 either by 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 client optionally authenticates to the OP and then
approves or disapproves authentication to the Relying Party. approves or disapproves authentication to the Relying Party. For
The manner in which the end user is authenticated to their reasons of its own the OP has the option of not authenticating a
respective OP and any policies surrounding such authentication request. The manner in which the end user is authenticated to
is out of scope of OpenID and and hence also out of scope for their respective OP and any policies surrounding such
this specification. This step happens out of band from SASL. authentication is out of scope of OpenID and and hence also out
of scope for this specification. 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 response via the client browser or handler. The client transmits
transmits over HTTP/TLS the redirect of the OP result to the RP. over HTTP/TLS the redirect of the OP result to the RP. This step
This step happens out of band from SASL. 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 be expected to respond. Again this step happens out of should respond. Again this step happens out of band from SASL.
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. 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
skipping to change at page 7, line 42 skipping to change at page 7, line 42
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 interprocess 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, either as 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. to uniquely identify each authentication transaction. The nonce
value MUST be at least 2^32 large and large enough to handle well in
excess of the number of concurrent transactions a SASL server shall
see.
2.2. Discussion 2.2. Discussion
As mentioned above OpenID is primarily designed to interact with web- As mentioned above OpenID is primarily designed to interact with web-
based applications. Portions of the authentication stream are only based applications. Portions of the authentication stream are only
defined in the crudest sense. That is, when one is prompted to 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, fancy 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 fairly rich browser in order to ensure that the
authentication can be completed. authentication can 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.
skipping to change at page 9, line 35 skipping to change at page 9, line 13
fixed message consisting of "=". 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. The GS2 header carries the optional authorization specification.
identity.
initial-response = gs2-header Auth-Identifier initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier Auth-Identifier = Identifier ; authentication identifier
Identifier = URI ; Identifier is specified in Identifier = URI ; Identifier is specified in
; Sec. 7.2 of the OpenID 2.0 spec. ; Sec. 7.2 of the OpenID 2.0 spec.
The "gs2-header" is specified in [RFC5801], and it is used as The syntax and semantics of the "gs2-header" are specified in
follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- [RFC5801], and we use it here with the following limitations: The
flag" MUST be "n" because channel binding is not supported by this "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n"
mechanism. The "gs2-authzid" carries the optional authorization because channel binding is not supported by this mechanism.
identity.
URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0] URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0]
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.
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 SHOULD be large
enough to be resistant to being guessed or attacked. 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
skipping to change at page 10, line 42 skipping to change at page 10, line 16
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 previsiously 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 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 and 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 [RFC4422] Section 3.6. 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]. They are encoded as that are listed in Section 4 of [SREG1.0].SREG attributes are encoded
follows: 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 concatentation 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
skipping to change at page 11, line 19 skipping to change at page 10, line 42
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 [RFC4422] Section 3.6 explicitly prohibits additional information in
an unsuccessful authentication outcome. Therefore, the openid.error an unsuccessful authentication outcome. Therefore, the openid.error
and openid.error_code are to be sent as an additional challenge in and openid.error_code are to be sent as an additional challenge in
the event of an unsuccessful outcome. In this case, as the protocol the event of an unsuccessful outcome. In this case, as the protocol
is lock step, the client will follow with an additional exchange is lock step, the client will follow with an additional exchange
containing "=", after which the server will respond with an containing "=", after which the server will respond with an
application-level outcome. 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 This section and its sub-sections and appropriate references of it
not referenced elsewhere in this document are not required for SASL not referenced elsewhere in this document are not required for SASL
implementors, but this section MUST be observed to implement the GSS- implementors, but this section MUST be observed to implement the GSS-
API mechanism discussed 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,
skipping to change at page 15, line 49 skipping to change at page 13, line 49
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_authenticate 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 clarity. ]
C: C:
[ In IMAP client must send a blank response to receive data [ In IMAP client must send a blank response after receiving the
that is included in a success response. ] 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 specification and to other literature [1]. Similarly, for general
<http://sites.google.com/site/openidreview/resources>. Similarly, SASL [RFC4422] and GSS-API [RFC5801] Security Considerations, the
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 pre-arranged 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
skipping to change at page 20, line 15 skipping to change at page 15, line 39
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.
[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. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D.E. 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, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
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.
[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.
skipping to change at page 21, line 14 skipping to change at page 16, line 39
[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.
[XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier
(XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs,
September 2005. September 2005.
9.2. Informative References 9.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J.G. and M.T. Rose, "Post Office Protocol - Version
STD 53, RFC 1939, May 1996. 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]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Hors, A., Raggett, D. and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium Recommendation
Recommendation REC-html401-19991224, December 1999, REC-html401-19991224, December 1999, <http://www.w3.org/TR
<http://www.w3.org/TR/1999/REC-html401-19991224>. /1999/REC-html401-19991224>.
Appendix A. Changes Appendix A. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 04 - 07 04 - 07 address LC and review comments, including those of o 04 - 07 04 - 07 address LC and review comments, including those of
Stephen Farrell, Steve Kent, and Brian Carpenter. Stephen Farrell, Steve Kent, and Brian Carpenter.
o 03 Clarifies messages and ordering, and replace the empty message o 03 Clarifies messages and ordering, and replace the empty message
with a "=" message. with a "=" message.
skipping to change at page 23, line 10 skipping to change at page 17, line 36
o 01 Add nonce discussion, add authorized identity, explain a o 01 Add nonce discussion, add authorized identity, explain a
definition. Add gs2 support. definition. Add gs2 support.
o 00 Initial Revision. o 00 Initial Revision.
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
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 Hagagatan 24
Stockholm 113 47 Stockholm, 113 47
SE SE
Email: simon@josefsson.org Email: simon@josefsson.org
URI: http://josefsson.org/ URI: http://josefsson.org/
 End of changes. 53 change blocks. 
166 lines changed or deleted 165 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/