draft-ietf-kitten-sasl-openid-01.txt   draft-ietf-kitten-sasl-openid-02.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: August 4, 2011 Nokia Siemens Networks Expires: October 29, 2011 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
January 31, 2011 April 27, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-01 draft-ietf-kitten-sasl-openid-02
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 August 4, 2011. This Internet-Draft will expire on October 29, 2011.
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 28 skipping to change at page 2, line 28
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10
3.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10 3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10
3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11 3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 16
6.2. RP redirected by malicious URL to take an improper 6.2. RP redirected by malicious URL to take an improper
action . . . . . . . . . . . . . . . . . . . . . . . . . . 15 action . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 16
6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 17
6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 17
7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 17 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
OpenID [OpenID] is a three-party protocol that provides a means for a OpenID [OpenID] is a web-based three-party protocol that provides a
user to offer identity assertions and other attributes to a web means for a user to offer identity assertions and other attributes to
server (Relying Party) via the help of an identity provider. The a web server (Relying Party) via the help of an identity provider.
purpose of this system is to provide a way to verify that an end user The purpose of this system is to provide a way to verify that an end
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, POP and XMPP, with the goal used by application protocols such IMAP [RFC3501], POP [RFC1939] and
of modularizing authentication and security layers, so that newer XMPP [RFC3920], with the goal of modularizing authentication and
mechanisms can be added as needed. This memo specifies just such a security layers, so that newer mechanisms can be added as needed.
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 [I-D.ietf-sasl-gs2]. bridge between SASL and the GSS-API called GS2 [I-D.ietf-sasl-gs2].
This means that this document defines both a SASL mechanism and a This means that this document defines both a SASL mechanism and a
GSS-API mechanism. We want to point out that the GSS-API interface GSS-API mechanism. We want to point out that the GSS-API interface
is optional for SASL implementers, and the GSS-API considerations can is optional for SASL implementers, and the GSS-API considerations can
be avoided in environments that uses SASL directly without GSS-API. be 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 The OpenID mechanism described in this memo aims to re-use the OpenID
available OpenID specification to a maximum extent and therefore does mechanism to the maximum extent and therefore does not establish a
not establish a separate authentication, integrity and separate authentication, integrity and confidentiality mechanism. It
confidentiality mechanism. It is anticipated that existing security is anticipated that existing security layers, such as Transport Layer
layers, such as Transport Layer Security (TLS), will continued to be Security(TLS) [RFC5246], will continued to be used. This
used. specification is appropriate for use when 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 within messaging required by the OpenID specification is tunneled within
SASL. SASL.
+-----------+ +-----------+
| | | |
skipping to change at page 4, line 42 skipping to change at page 4, line 42
"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 [RFC5246], and the client MUST over channels protected by TLS, and the client MUST successfully
successfully validate the server certificate, or similar integrity validate the server certificate, or similar integrity protected and
protected and authenticated channels. authenticated channels.[RFC5280][RFC6125]
2. Applicability for non-HTTP Use Cases 2. Applicability for non-HTTP Use Cases
OpenID was originally envisioned for HTTP/HTML based communications, OpenID was originally envisioned for HTTP [RFC2616]/HTML
and with the associated semantic, the idea being that the user would [W3C.REC-html401-19991224] based communications, and with the
be redirected by the Relying Party to an identity provider who associated semantic, the idea being that the user would be redirected
authenticates the user, and then sends identity information and other by the Relying Party to an identity provider who authenticates the
attributes (either directly or indirectly) to the Relying Party. The user, and then sends identity information and other attributes
identity provider in the OpenID specifications is referred to as an (either directly or indirectly) to the Relying Party. The identity
OpenID Provider (OP). The actual protocol flow, as copied from the provider in the OpenID specifications is referred to as an OpenID
OpenID 2.0 specification, is as follows: Provider (OP). The actual protocol flow, as copied from the OpenID
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., http://user.example.com).
2. After normalizing the User-Supplied Identifier, the Relying Party 2. After normalizing the User-Supplied Identifier as described in
performs discovery on it and establishes the OP Endpoint URL that Section 7.2 of [OpenID], the Relying Party performs discovery on
the end user uses for authentication. It should be noted that it and establishes the OP Endpoint URL that the end user uses for
the User-Supplied Identifier may be an OP Identifier, which authentication. It should be noted that the User-Supplied
allows selection of a Claimed Identifier at the OP or for the Identifier may be an OP Identifier, which allows selection of a
protocol to proceed without a Claimed Identifier if something Claimed Identifier at the OP or for the protocol to proceed
else useful is being done via an extension. without a Claimed Identifier if something else useful 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. authentication request/response. This process is desccribed in
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
with an OpenID Authentication request. This occurs as stated in with an OpenID Authentication request. This occurs as stated in
Section 10.3 of [RFC2616]. Section 10.3 of [RFC2616].
5. The OP authenticates the end user and establishes whether the end 5. The OP authenticates the end user and establishes whether the end
user will authenticate to, and share specific attributes with, user will authenticate to, and share specific attributes with,
the Relying Party. For instance, the OP often asks the user what the Relying Party. For instance, the OP often asks the user what
to do. The manner in which the end user authenticates to their to do. The manner in which the end user authenticates to their
OP and any policies surrounding such authentication is out of OP and any policies surrounding such authentication is out of
skipping to change at page 6, line 24 skipping to change at page 6, line 28
connection) established with the client. However, it may be connection) established with the client. However, it may be
necessary to redirect a SASL client to another application. This necessary to redirect a SASL client to another application. This
will be discussed below. By doing so, we externalize much of the will be discussed below. By doing so, we externalize much of the
authentiction from SASL. authentiction from SASL.
The steps are shown from below: The steps are shown from 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 authentiation and transmits the 2. The client initiates a SASL authentication and transmits the
User-Supplied Identifier as well as an optional return_to User-Supplied Identifier.
parameter.
3. After normalizing the User-Supplied Identifier, the Relying 3. After normalizing the User-Supplied Identifier as discussed in
Party performs discovery on it and establishes the OP Endpoint [OpenID], the Relying Party performs discovery on it and
URL that the end user uses for authentication. establishes the OP Endpoint URL that the end user uses for
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. The OP uses an association to sign subsequent Exchange. The OP uses an association to sign subsequent
messages and the Relying Party to verify those messages; this messages and the Relying Party to verify those messages; this
removes the need for subsequent direct requests to verify the removes the need for subsequent direct requests to verify the
signature after each authentication request/response. signature after each authentication request/response.
5. The Relying Party transmits an authentication request to the OP 5. The Relying Party transmits an authentication request to the OP
to obtain an assertion in the form of an indirect request. to obtain an assertion in the form of an indirect request.
skipping to change at page 8, line 30 skipping to change at page 8, line 30
| | | | | |
| |<- - (8)- - ->| Client / OP Auth. (ext.) | |<- - (8)- - ->| Client / OP Auth. (ext.)
| | | | | |
|<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res |<- - -(9)- - - + - - - - - - <| HTTP(s) 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 SSL - - - = HTTP or HTTPS
Note the directionality in SASL is such that the client MUST send an Note the directionality in SASL is such that the client MUST send an
empty response. Specifically, it processes the redirect and then empty response. Specifically, it processes the redirect and then
awaits a final SASL decision, while the rest of the OpenID 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
skipping to change at page 10, line 25 skipping to change at page 10, line 25
3.2. Initiation 3.2. 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 XRI or 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 ; Identifer is specified in Identifier = URI / XRI ; 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 [I-D.ietf-sasl-gs2], and it is used The "gs2-header" is specified in [I-D.ietf-sasl-gs2], and it is used
as follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- as 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 The XRI syntax is defined in [XRI2.0]. URI is specified in
[RFC3986]. [RFC3986].
3.3. Authentication Request 3.3. Authentication Request
The SASL Server sends an OpenID message that contains an openid.mode The SASL Server sends an OpenID message that contains an openid.mode
of either "checkid_immediate" or "checkid_setup", as specified in of either "checkid_immediate" or "checkid_setup", as specified in
Section 9.1 of the OpenID 2.0 specification. Section 9.1 of the OpenID 2.0 specification.
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 &quote;return_to" portion of the request. The transaction id to the "return_to" portion of the request. The form
form of this transaction is left to the RP to decide, but SHOULD be of this transaction is left to the RP to decide, but SHOULD be large
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 of the RP.
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 or SSL. response to the Relying Party via HTTP or SSL, as specified
previously in the transaction.
3.4. Server Response 3.4. 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 SSL, as specified in the OpenID specification. client via HTTP or HTTPS, as specified in the OpenID specification,
using the URI given previsiously in the transaction.
The response by the Relying Party consists of an application specific The response by the Relying Party consists of an application specific
response code indicating success or failure of authentication. In response code indicating success or failure of authentication. In
the additional data, the server MAY include OpenID Simple Registry the additional data, the server MAY include OpenID Simple Registry
(SREG) attributes that are listed in Section 4 of [SREG1.0]. They (SREG) attributes that are listed in Section 4 of [SREG1.0]. They
are encoded as follows: are encoded as follows:
1. Strip "openid.sreg." from each attribute name. 1. Strip "openid.sreg." from each attribute name.
2. Treat the concatentation of results as URI parameters that are 2. Treat the concatentation of results as URI parameters that are
skipping to change at page 11, line 36 skipping to change at page 11, line 38
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 3896 ; pct-encoded from Section 2.1 of RFC 3986
; unreserved from Section 2.3 of RFC 3896 ; unreserved from Section 2.3 of RFC 3986
If the application protocol allows, openid.error and In the case of failures, openid.error and openid.error_code and any
openid.error_code and any other useful diagnostic information SHOULD other appropriate diagnostic information SHOULD be reported to the
be included in authentication failures. user, when possible, through the application protocol.
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 all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
The OpenID SASL mechanism is actually also a GSS-API mechanism. The The OpenID SASL mechanism is actually also a GSS-API mechanism. The
messages are the same, but a) the GS2 header on the client's first messages are the same, but a) the GS2 header on the client's first
message and channel binding data is excluded when OpenID is used as a message and channel binding data is excluded when OpenID is used as a
skipping to change at page 13, line 14 skipping to change at page 13, line 14
5. Example 5. Example
Suppose one has an OpenID of http://openid.example, and wishes to Suppose one has an OpenID of http://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.
The authentication on the wire would then look something like the Note the use of [RFC4959] for initial response. The authentication
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 biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw==
[ This is the base64 encoding of "n,,http://openid.example/". [ This is the base64 encoding of "n,,http://openid.example/".
skipping to change at page 15, line 5 skipping to change at page 14, line 52
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 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
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 applications. For considerations with the use of OpenID with SASL applications. 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. Similarly, for general SASL
Security Considerations, the reader is referred to that Security Considerations, the reader is referred to that
specification. specification.
6.1. Binding OpenIDs to Authorization Identities 6.1. Binding OpenIDs to Authorization Identities
skipping to change at page 15, line 39 skipping to change at page 16, line 39
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. authentication attempt. It is RECOMMENDED that only http or https
schemas be accepted.
6.3. Session Swapping (Cross-Site Request Forgery) 6.3. Session Swapping (Cross-Site Request Forgery)
There is no defined mechanism in the OpenID protocol to bind the 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- 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 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 proper RP as the attacker. The user would not recognize they are
logged into the site as the attacker, and so may reveal information logged into the site as the attacker, and so may reveal information
at the RP. Cross-site request forgery is a widely exploited at the RP. Cross-site request forgery is a widely exploited
vulnerability at web sites. This is only concern in the context SASL vulnerability at web sites. This is only concern in the context SASL
skipping to change at page 17, line 10 skipping to change at page 18, line 10
typed in to another identifier. This way the RP would never see the typed in to another identifier. This way the RP would never see the
actual user identifier, but a randomly generated identifier. This is 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 an option the user has to understand and decide to use if the OP is
supporting it. 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 it should be possible for the SASL client to signal the browser that the given
increase scrutiny of invalid credentials. How this would be done is URL is the beginning of a sensitive transaction, and that increased
beyond the scope of this specification, but may be the subject of scrutiny should be given. A signal of some form would need to come
future updates. For instance, the browser may wish to fail the from an appropriately authorized agent that the sensitive transaction
request entirely if the certificate is invalid and has not been is complete. An example behavior during this sensitive period might
accessed prior to this point. One thing that this would require be increased scrutiny of broken trust chains in certificates, or
would be the exposure of a "return_to" URL by the SASL server in case perhaps disallowing such trust chains altogether.
of such failures, so that the authentication is not left hanging.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to register the following SASL profile: The IANA is requested to register the following SASL profile:
SASL mechanism profile: OPENID20 SASL mechanism profile: OPENID20
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
skipping to change at page 20, line 5 skipping to change at page 21, line 5
Owner/Change controller: the IETF Owner/Change controller: the IETF
Note: None Note: None
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their
review and contributions. review and contributions.
10. Normative References 10. References
10.1. Normative References
[I-D.ietf-sasl-gs2] [I-D.ietf-sasl-gs2]
Josefsson, S. and N. Williams, "Using GSS-API Mechanisms Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20
(work in progress), January 2010. (work in progress), January 2010.
[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
skipping to change at page 20, line 38 skipping to change at page 21, line 40
[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 3986, January 2005. RFC 3986, 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.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006. version 1.0", June 2006.
[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.
10.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial
Client Response", RFC 4959, September 2007.
[W3C.REC-html401-19991224]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999,
<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 02 Address all WGLC comments.
o 01 Specific text around possible improvements for OOB browser o 01 Specific text around possible improvements for OOB browser
control in security considerations. Also talk about transaction control in security considerations. Also talk about transaction
id. id.
o 00 WG -00 draft. Slight wording modifications abou design o 00 WG -00 draft. Slight wording modifications abou design
constraints per Alexey. constraints per Alexey.
o 02 Correct single (significant) error on mechanism name. o 02 Correct single (significant) error on mechanism name.
o 01 Add nonce discussion, add authorized identity, explain a o 01 Add nonce discussion, add authorized identity, explain a
 End of changes. 30 change blocks. 
80 lines changed or deleted 126 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/