draft-ietf-kitten-sasl-openid-04.txt   draft-ietf-kitten-sasl-openid-05.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: January 12, 2012 Nokia Siemens Networks Expires: March 26, 2012 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
July 11, 2011 September 23, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-04 draft-ietf-kitten-sasl-openid-05
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 January 12, 2012. This Internet-Draft will expire on March 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 11 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 11
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 13 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 13
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 13 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 13
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 18 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 18
6.2. RP redirected by malicious URL to take an improper 6.2. RP redirected by malicious URL to take an improper
action . . . . . . . . . . . . . . . . . . . . . . . . . . 18 action . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 18 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 19 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 19
6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
XMPP [RFC3920], with the goal of modularizing authentication and XMPP [RFC3920], 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. We want to point out that the GSS-API interface is mechanism. Implementors of the SASL component MAY implement the GSS-
optional for SASL implementers, and the GSS-API considerations can be API interface as well.
avoided in environments that uses SASL directly without GSS-API.
As currently envisioned, this mechanism is to allow the interworking As currently envisioned, this mechanism is to allow the interworking
between SASL and OpenID in order to assert identity and other between SASL and OpenID in order to assert identity and other
attributes to relying parties. As such, while servers (as relying attributes to relying parties. As such, while servers (as relying
parties) will advertise SASL mechanisms, clients will select the parties) will advertise SASL 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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
associated semantic, the idea being that the user would be redirected associated semantic, the idea being that the user would be redirected
by the Relying Party to an identity provider who authenticates the by the Relying Party to an identity provider who authenticates the
user, and then sends identity information and other attributes user, and then sends identity information and other attributes
(either directly or indirectly) to the Relying Party. The identity (either directly or indirectly) to the Relying Party. The identity
provider in the OpenID specifications is referred to as an OpenID provider in the OpenID specifications is referred to as an OpenID
Provider (OP). The actual protocol flow, as copied from the OpenID Provider (OP). The actual protocol flow, as copied from the OpenID
2.0 specification, is as follows: 2.0 specification, is as follows:
1. The end user initiates authentication by presenting a User- 1. The end user initiates authentication by presenting a User-
Supplied Identifier to the Relying Party via their User-Agent Supplied Identifier to the Relying Party via their User-Agent
(e.g., http://user.example.com). (e.g., https://user.example.com).
2. After normalizing the User-Supplied Identifier as described in 2. After normalizing the User-Supplied Identifier as described in
Section 7.2 of [OpenID], the Relying Party performs discovery on Section 7.2 of [OpenID], the Relying Party performs discovery on
it and establishes the OP Endpoint URL that the end user uses for the URI specified and establishes the OP Endpoint URL that the
authentication. It should be noted that the User-Supplied end user uses for authentication. It should be noted that the
Identifier may be an OP Identifier, which allows selection of a User-Supplied Identifier may be an OP Identifier, which allows
Claimed Identifier at the OP or for the protocol to proceed selection of a Claimed Identifier at the OP or for the protocol
without a Claimed Identifier if something else useful is being to proceed without a Claimed Identifier if something else useful
done via an extension. is being done via an extension.
3. The Relying Party and the OP optionally establish an association 3. 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 Exchange.
The OP uses an association to sign subsequent messages and the The OP uses an association to sign subsequent messages and the
Relying Party to verify those messages; this removes the need for Relying Party to verify those messages; this removes the need for
subsequent direct requests to verify the signature after each subsequent direct requests to verify the signature after each
authentication request/response. This process is desccribed in authentication request/response. This process is desccribed in
Section 8 of [OpenID]. Section 8 of [OpenID].
4. The Relying Party redirects the end user's User-Agent to the OP 4. The Relying Party redirects the end user's User-Agent to the OP
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Party with either an assertion that authentication is approved or Party with either an assertion that authentication is approved or
a message that authentication failed. a message that authentication failed.
7. The Relying Party verifies the information received from the OP 7. The Relying Party verifies the information received from the OP
including checking the Return URL, verifying the discovered including checking the Return URL, verifying the discovered
information, checking the nonce, and verifying the signature by information, checking the nonce, and verifying the signature by
using either the shared key established during the association or using either the shared key established during the association or
by sending a direct request to the OP. by sending a direct request to the OP.
When considering this flow in the context of SASL, we note that while When considering this flow in the context of SASL, we note that while
the RP and the client both must change their code to implement this the RP and the client both need to change their code to implement
SASL mechanism, it is a design constraint that the OP behavior remain this SASL mechanism, it is a design constraint that the OP behavior
untouched, in order for implementations to interoperate with existing remain untouched, in order for implementations to interoperate with
IdPs. Hence, an analog flow that interfaces the three parties needs existing IdPs. Hence, an analog flow that interfaces the three
to be created. In the analog, we note that unlike a web server, the parties needs to be created. In the analog, we note that unlike a
SASL server already has some sort of session (probably a TCP web server, the SASL server already has some sort of session
connection) established with the client. However, it may be (probably a TCP connection) established with the client. However, it
necessary to redirect a SASL client to another application. This may be necessary for a SASL client to invoke to another application.
will be discussed below. By doing so, we externalize much of the This will be discussed below. By doing so, we externalize much of
authentiction from SASL. the authentiction from SASL.
The steps are shown from below: The steps are listed below:
1. The Relying Party or SASL server advertises support for the SASL 1. The Relying Party or SASL server advertises support for the SASL
OpenID mechanism to the client. OpenID mechanism 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
skipping to change at page 7, line 26 skipping to change at page 7, line 26
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.
The manner in which the end user is authenticated to their The manner in which the end user is authenticated to their
respective OP and any policies surrounding such authentication respective OP and any policies surrounding such authentication
is out of scope of OpenID and and hence also out of scope for is out of scope of OpenID and and hence also out of scope for
this specification. This step happens out of band from SASL. 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 over HTTP the redirect of the OP result to the RP. transmits over HTTP/TLS the redirect of the OP result to the RP.
This step happens out of band from SASL. 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 be expected to respond. Again this step happens out of should be expected to 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.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
|<- - -(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)- - - + - - - - - - <| HTTP(s) Indirect id_res |<- - -(9)- - - + - - - - - - <| HTTPs Indirect id_res
| | | | | |
|<- - -(10)- - - - - - - - - ->| Optional check_authenticate |<- - -(10)- - - - - - - - - ->| Optional check_authenticate
| | | | | |
|>-----(11)---->| | SASL completion with status |>-----(11)---->| | SASL completion with status
----- = SASL ----- = SASL
- - - = HTTP or 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, it processes the redirect and then "=" response. Specifically, the SASL client processes the redirect
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
To ensure that a specific request is bound, and in particular to ease To ensure that a specific request is bound, and in particular to ease
interprocess communication, it may be necessary for the relying party interprocess communication, it may be necessary for the relying party
to encode some sort of nonce in the URIs it transmits through the to encode some sort of nonce or transaction-id in the URIs it
client for success or failure. This can be done in any number of transmits through the client for success or failure. This can be
ways. Examples would include making changes to the base URI or done in any number of ways. Examples would include making changes to
otherwise including an additional fragment. the base URI or otherwise including an additional fragment.
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 insure 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.
The astute will hopefully by now have noticed an "=" client SASL The astute will hopefully by now have noticed an "=" client SASL
response. This is not to say that nothing is happening, but rather response. This is not to say that nothing is happening, but rather
that authentication flow has shifted from SASL to OpenID, and will that authentication flow has shifted from SASL to OpenID, and will
return when the server has an outcome to hand to the client. The return when the server has an outcome to hand to the client. The
alternative to this flow is some signal from the HTML browser to the alternative to this flow is some signal from the HTML browser to the
SASL client of the results that is in turn passed to the SASL server. SASL client of the results that is in turn passed to the SASL server.
The IPC issue this raises is substantial. Better, we conclude, to The IPC 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.
OpenID is also meant to be used in serial within the web. As such, OpenID is also meant to be used in serial within the web. As such,
there are no transaction-ids within the protocol. A transaction id, there are no transaction-ids within the protocol. A transaction id,
can be included by the RP by appending it to the return_to URL. MUST be included by the RP by appending it to the return_to URL.
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 "OPENID20". The mechanism is capable of
transferring an authorization identity (via "gs2-header"). The transferring an authorization identity (via "gs2-header"). The
mechanism does not offer a security layer. mechanism does not offer a security layer.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
The third mechanism message is from client to the server, and is the The third mechanism message is from client to the server, and is the
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 XRI or 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. The GS2 header carries the optional authorization
identity. 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 / XRI ; 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 "gs2-header" is specified in [RFC5801], and it is used as
follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-
flag" MUST be "n" because channel binding is not supported by this flag" MUST be "n" because channel binding is not supported by this
mechanism. The "gs2-authzid" carries the optional authorization mechanism. The "gs2-authzid" carries the optional authorization
identity. identity.
The XRI syntax is defined in [XRI2.0]. URI is specified in URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0]
[RFC3986].
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
confirmation or rejection of the authentiation of the RP. confirmation or rejection of the authentiation by the RP via this
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(S), as specified previously in response to the Relying Party via HTTP/TLS, as specified previously
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 or HTTPS, as specified in the OpenID specification, client via HTTP/TLS, as specified in the OpenID specification, using
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]. They are encoded as
follows: 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 ambersand (&) 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 12, line 13 skipping to change at page 12, line 14
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
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 all normative references of it This section and its sub-sections and appropriate references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are not required for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but this section MUST be observed to implement the GSS-
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 is 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 RFC2743 section 3.1 initial context token header is
prefixed to the client's first authentication message (context prefixed to the client's first authentication message (context
token). token).
The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see
IANA considerations). IANA considerations).
OpenID security contexts always 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 alway 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].
skipping to change at page 14, line 15 skipping to change at page 14, line 16
OpenID name normalization is covered by the OpenID specification, see OpenID name normalization is covered by the OpenID specification, see
[OpenID] section 7.2. [OpenID] section 7.2.
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 [RFC2743],
Section 4). The exported name token does, of course, conform to Section 4). The exported name token does, of course, conform to
[RFC2743], Section 3.2, but the "NAME" part of the token should be [RFC2743], Section 3.2, 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. rules. For example, the OpenID identifier "https://openid.example/"
will have a GSS_C_NT_USER_NAME value of "http://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 http://openid.example, and wishes to Suppose one 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 Consumer In this case, no association is attempted between the OpenID Consumer
and the OP. The client will make use of the return_to attribute to and 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 initial response. The authentication
on the wire would then look something like the following: 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 biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw== C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,http://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: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA== 5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
[ This is the base64 encoding of "http://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 readibility.
] ]
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 http://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 who 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_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 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 to receive data
that is included in a success response. ] that is included in a success response. ]
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. Similarly, for general SASL specification and to other literature
and GSS-API Security Considerations, the reader is referred to those <http://sites.google.com/site/openidreview/resources>. Similarly,
specifications. for general SASL [RFC4422] and GSS-API [RFC5801] Security
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 either some sort of registration process takes place necessary that either some sort of registration process takes place
to register specific OpenIDs, or that only specific trusted OpenID to register specific OpenIDs, or that only specific trusted OpenID
Providers be allowed. Some out of band knowledge may help this Providers be allowed. Some out of band knowledge may help this
process along. For instance, users of a particular domain may process along. For instance, users of a particular domain may
utilize a particular OP that enforces a mapping. utilize a particular OP that enforces a mapping.
skipping to change at page 18, line 38 skipping to change at page 18, line 39
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 the RP does a port
scan of the site. The URL could send the connection to an internal scan of the site. The URL could send the connection to an internal
host or even the local host, which the attacker would not normally host or even the local host, which the attacker would not normally
have access to. The URL could contain a protocol other than http or have access to. The URL could contain a protocol other than http or
https, such as file or ftp. https, such as file or ftp.
To mitigate this attack, implementations should carefully analyze To mitigate this attack, implementations should carefully analyze
URLs received, eliminating any that would in some way be privileged. URLs received, eliminating any that would in some way be privileged.
A log of those sites that fail SHOULD be kept, and limitations on A log of those sites that fail SHOULD be kept, and limitations on
queries from clients should be imposed, just as with any other queries from clients SHOULD be imposed, just as with any other
authentication attempt. It is RECOMMENDED that only http or https authentication attempt. It is RECOMMENDED that only http or https
schemas be accepted. schemes be accepted.
6.3. Session Swapping (Cross-Site Request Forgery)
There is no defined mechanism in the OpenID protocol to bind the
OpenID session to the user's browser. An attacker may forge a cross-
site request in the log-in form, which has the user logging into a
proper RP as the attacker. The user would not recognize they are
logged into the site as the attacker, and so may reveal information
at the RP. Cross-site request forgery is a widely exploited
vulnerability at web sites. This is only concern in the context SASL
in as much as the client is not configured with the Relying Party
(e.g., SASL server) in a safe manner.
6.4. 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 track - to some extent - user access to OpenID Providers will be able to track - to some extent - user access
their services and any additional information that OP provides. to their services and any additional information that OP provides.
6.5. Collusion between RPs
It is possible for RPs to link data that they have collected on you.
By using the same identifier to log into every RP, collusion between
RPs is possible. In OpenID 2.0, directed identity was introduced.
Directed identity allows the OP to transform the identifier the user
typed in to another identifier. This way the RP would never see the
actual user identifier, but a randomly generated identifier. This is
an option the user has to understand and decide to use if the OP is
supporting it.
7. Room for Improvement 7. Room for Improvement
We note one area where there is possible room for improvement over We note one area where there is possible room for improvement over
existing OpenID implementations. Because SASL is often implemented existing OpenID implementations. Because SASL is often implemented
atop protocols that have required some amount of provisioning, it may atop protocols that have required some amount of provisioning, it may
be possible for the SASL client to signal the browser that the given be possible for the SASL client to signal the browser that the given
URL is the beginning of a sensitive transaction, and that increased URL is the beginning of a sensitive transaction, and that increased
scrutiny should be given. A signal of some form would need to come scrutiny should be given. A signal of some form would need to come
from an appropriately authorized agent that the sensitive transaction from an appropriately authorized agent that the sensitive transaction
skipping to change at page 24, line 28 skipping to change at page 23, line 28
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[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.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/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 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.
 End of changes. 42 change blocks. 
111 lines changed or deleted 91 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/