draft-ietf-kitten-sasl-openid-02.txt   draft-ietf-kitten-sasl-openid-03.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: October 29, 2011 Nokia Siemens Networks Expires: December 16, 2011 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
April 27, 2011 June 14, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-02 draft-ietf-kitten-sasl-openid-03
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 October 29, 2011. This Internet-Draft will expire on December 16, 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5
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. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 11
3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11
3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 13
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 13
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 action . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 16 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 18
6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 19
6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 17 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 19
7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 18 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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
used by application protocols such IMAP [RFC3501], POP [RFC1939] and used by application protocols such IMAP [RFC3501], POP [RFC1939] and
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 [I-D.ietf-sasl-gs2]. bridge between SASL and the GSS-API called GS2 [RFC5801]. This means
This means that this document defines both a SASL mechanism and a that this document defines both a SASL mechanism and a GSS-API
GSS-API mechanism. We want to point out that the GSS-API interface mechanism. We want to point out that the GSS-API interface is
is optional for SASL implementers, and the GSS-API considerations can optional for SASL implementers, and the GSS-API considerations can be
be avoided in environments that uses SASL directly without GSS-API. 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
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. This Security (TLS) [RFC5246], will continued to be used. This
specification is appropriate for use when a browser is available. 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 through
SASL. the SASL/GSS-API mechanism.
+-----------+ +-----------+
| | | |
>| Relying | >| Relying |
/ | Party | / | Party |
// | | // | |
// +-----------+ // +-----------+
// ^ // ^
OpenID // +--|--+ OpenID // +--|--+
// | O| | // | O| | G
/ S | p| | / S | p| | S
// A | e| | // A | e| | S
// S | n| | // S | n| | A
// L | I| | // L | I| | P
// | D| | // | D| | I
</ +--|--+ </ +--|--+
+------------+ v +------------+ v
| | +----------+ | | +----------+
| OpenID | OpenID | | | OpenID | OpenID | |
| Provider |<--------------->| Client | | Provider |<--------------->| Client |
| | | | | | | |
+------------+ +----------+ +------------+ +----------+
Figure 1: Interworking Architecture Figure 1: Interworking Architecture
skipping to change at page 4, line 44 skipping to change at page 4, line 44
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, or similar integrity protected and validate the server certificate, or similar integrity protected and
authenticated channels.[RFC5280][RFC6125] authenticated channels. [RFC5280][RFC6125]
2. Applicability for non-HTTP Use Cases 2. Applicability for non-HTTP Use Cases
OpenID was originally envisioned for HTTP [RFC2616]/HTML OpenID was originally envisioned for HTTP [RFC2616] and HTML
[W3C.REC-html401-19991224] based communications, and with the [W3C.REC-html401-19991224] based communications, and with the
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-
skipping to change at page 6, line 29 skipping to change at page 6, line 29
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 authentication and transmits the 2. The client initiates a SASL authentication and transmits the
User-Supplied Identifier. User-Supplied Identifier as its first response. The SASL
mechanism is client-first, and as explained in [RFC4422] the
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. 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
skipping to change at page 7, line 5 skipping to change at page 7, line 7
to obtain an assertion in the form of an indirect request. to obtain an assertion in the form of an indirect request.
These messages are passed through the client rather than These messages are passed through the client rather than
directly between the RP and the OP. OpenID defines two methods directly between the RP and the OP. OpenID defines two methods
for indirect communication, namely HTTP redirects and HTML form for 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 can be used a new method is defined in this document that OP 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]
6. The SASL client now sends an empty response, as authentication 6. The SASL client now sends an response consisting of "=", to
continues via the normal OpenID flow. indicate that authentication continues via the normal OpenID
flow.
7. At this point the client application MUST construct a URL 7. At this point the client application MUST construct a URL
containing the content received in the previous message from the containing the content received in the previous message from the
RP. This URL is transmitted to the OP either by the SASL client RP. This URL is transmitted to the OP 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.
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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
| | | | | |
|<-----(2)-----<| | Initiation |<-----(2)-----<| | Initiation
| | | | | |
|> - - (3) - - - - - - - - - ->| Discovery |> - - (3) - - - - - - - - - ->| Discovery
| | | |
|>- - -(4)- - - - - - - - - - >| Association |>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <| |<- - -(4)- - - - - - - - - - <|
| | | | | |
|>-----(5)----->| | Indirect Auth Request |>-----(5)----->| | Indirect Auth Request
| | | | | |
|<-----(6)-----<| | Client Empty 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)- - - + - - - - - - <| 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 HTTPS - - - = 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 the
empty response. Specifically, it processes the redirect and then "=" 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
to encode some sort of nonce in the URIs it transmits through the to encode some sort of nonce in the URIs it transmits through the
client for success or failure. This can be done in any number of client for success or failure. This can be done in any number of
ways. Examples would include making changes to the base URI or ways. Examples would include making changes to the base URI or
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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 insure 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 empty client SASL The astute will hopefully by now have noticed an "=" client SASL
challenge. 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 empty externalize the authentication to the browser, and have an "=" client
client challenge. 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. can be included by the RP by appending it to the return_to URL.
3. OpenID SASL Mechanism Specification 3. OpenID SASL Mechanism Specification
Based on the previous figure, the following operations are performed This section specifies the details of the OpenID SASL mechanism.
with the OpenId SASL mechanism: Recall section 5 of [RFC4422] for what needs to be described here.
3.1. Advertisement The name of this mechanism "OPENID20". The mechanism is capable of
transferring an authorization identity (via "gs2-header"). The
mechanism does not offer a security layer.
To advertise that a server supports OpenID, during application The mechanism is client-first. The first mechanism message from the
session initiation, it displays the name "OPENID20" in the list of client to the server is the "initial-response" described below. As
supported SASL mechanisms. described in [RFC4422], if the application protocol does not support
sending a client-response together with the authentication request,
the server will send an empty server-challenge to let the client
begin.
3.2. Initiation The second mechanism message is from the server to the client, the
"authentication_request" described below.
The third mechanism message is from client to the server, and is the
fixed message consisting of "=".
The fourth mechanism message is from the server to the client,
described below as "outcome_data" (with SREG attributes), sent as
additional data when indicating a successful outcome.
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 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 ; Identifier 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 [RFC5801], and it is used as
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 The XRI syntax is defined in [XRI2.0]. URI is specified in
[RFC3986]. [RFC3986].
3.3. Authentication Request 3.2. Authentication Request
The SASL Server sends an OpenID message that contains an openid.mode The SASL Server sends the URL resulting from the OpenID
of either "checkid_immediate" or "checkid_setup", as specified in authentication request, containing an "openid.mode" of either
Section 9.1 of the OpenID 2.0 specification. "checkid_immediate" or "checkid_setup", as specified in Section 9.1
of the OpenID 2.0 specification.
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 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, as specified response to the Relying Party via HTTP(S), as specified previously in
previously in the transaction. the transaction ("return_to").
3.4. 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 or HTTPS, as specified in the OpenID specification,
using the URI given previsiously in the transaction. using the "return_to" URI given previsiously in the transaction.
The response by the Relying Party consists of an application specific The response by the Relying Party constitutes a SASL mechanism
response code indicating success or failure of authentication. In outcome, and SHALL be used to set state in the server accordingly,
the additional data, the server MAY include OpenID Simple Registry and it shall be used by the server to report that state to the SASL
(SREG) attributes that are listed in Section 4 of [SREG1.0]. They client as described in [RFC4422] Section 3.6. In the additional
are encoded as follows: data, the server MAY include OpenID Simple Registry (SREG) attributes
that are listed in Section 4 of [SREG1.0]. They 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
separated by an ambersand (&) and encode as one would a URI, separated by an ambersand (&) 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
In the case of failures, openid.error and openid.error_code and any In the case of failures, the response MUST follow this syntax:
other appropriate diagnostic information SHOULD be reported to the
user, when possible, through the application protocol. outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp )
3.4. Error Handling
[RFC4422] Section 3.6 explicitly prohibits additional information in
an unsuccessful authentication outcome. Therefore, the openid.error
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
is lock step, the client will follow with an additional exchange
containing "=", after which the server will respond with an
application-level outcome.
4. OpenID GSS-API Mechanism Specification 4. OpenID GSS-API Mechanism Specification
This section and its sub-sections and 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 OpenID user takes the role of the GSS-API Initiator and the OpenID
message and channel binding data is excluded when OpenID is used as a Relying Party takes the role of the GSS-API Acceptor. The OpenId
GSS-API mechanism, and b) the RFC2743 section 3.1 initial context Provider does not have a role in GSS-API, and is considered an
token header is prefixed to the client's first authentication message internal matter for the OpenID mechanism. The messages are the same,
(context token). 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,
and b) the RFC2743 section 3.1 initial context token header is
prefixed to the client's first authentication message (context
token).
The GSS-API mechanism OID for OpenID is 1.3.6.1.4.1.11591.4.5. The GSS-API mechanism OID for OpenID is 1.3.6.1.4.1.11591.4.5.
OpenID security contexts always have the mutual_state flag OpenID security contexts always 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 alway 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
successfully comparing the TLS server identity with the negotiated
target name. Since the TLS channel is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to
confirm the name while the application is able to perform this
comparison for the mechanism. For this reason, applications MUST
match the TLS server identity with the target name, as discussed in
[RFC6125].
The OpenID mechanism does not support per-message tokens or The OpenID mechanism does not support per-message tokens or
GSS_Pseudo_random. GSS_Pseudo_random.
The [RFC5587] mechanism attributes for this mechanism are
GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT.
4.1. GSS-API Principal Name Types for OpenID 4.1. GSS-API Principal Name Types for OpenID
OpenID supports standard generic name syntaxes for acceptors such as OpenID supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).
OpenID supports only a single name type for initiators: OpenID supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
OpenID. OpenID.
OpenID name normalization is covered by the OpenID specification, see OpenID name normalization is covered by the OpenID specification, see
skipping to change at page 14, line 31 skipping to change at page 16, line 31
LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA== LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA==
[ This is the base64 encoding of "http://openid.example/openid/ [ This is the base64 encoding of "http://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: 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 http://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 an empty 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 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 applications. 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. Similarly, for general SASL
Security Considerations, the reader is referred to that and GSS-API Security Considerations, the reader is referred to those
specification. 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 19, line 7 skipping to change at page 21, line 7
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
is complete. An example behavior during this sensitive period might is complete. An example behavior during this sensitive period might
be increased scrutiny of broken trust chains in certificates, or be increased scrutiny of broken trust chains in certificates, or
perhaps disallowing such trust chains altogether. perhaps disallowing such trust chains altogether.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to register the following SASL profile: The IANA is requested to update the SASL Mechanism Registry using the
following template, as described in [RFC4422].
SASL mechanism profile: OPENID20 SASL mechanism name: OPENID20
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published specification: See this document
For further information: Contact the authors of this document. Person & email address to contact for further information: Authors of
this document
Owner/Change controller: the IETF Intended usage: COMMON
Owner/Change controller: 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 Melnikov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams,
review and contributions. and Klaas Wierenga for their review and contributions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sasl-gs2]
Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20
(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
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. 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.,
skipping to change at page 21, line 45 skipping to change at page 23, line 40
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
Inquiry APIs", RFC 5587, July 2009.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006. version 1.0", June 2006.
[XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier
skipping to change at page 23, line 9 skipping to change at page 25, line 9
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 Hors, A., Jacobs, I., and D. Raggett, "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
with a "=" message.
o 02 Address all WGLC comments. 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.
 End of changes. 46 change blocks. 
99 lines changed or deleted 158 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/