| TOC |
|
OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on February 16, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
1.1.
Terminology
1.2.
Applicability
2.
Applicability for non-HTTP Use Cases
2.1.
Binding SASL to OpenID in the Relying Party
2.2.
Discussion
3.
OpenID SASL Mechanism Specification
3.1.
Advertisement
3.2.
Initiation
3.3.
Authentication Request
3.4.
Server Response
4.
OpenID GSS-API Mechanism Specification
4.1.
GSS-API Principal Name Types for OpenID
5.
Example
6.
Security Considerations
6.1.
Binding OpenIDs to Authorization Identities
6.2.
RP redirected by malicious URL to take an improper action
6.3.
Session Swapping (Cross-Site Request Forgery)
6.4.
User Privacy
6.5.
Collusion between RPs
7.
IANA Considerations
8.
Acknowledgments
9.
Normative References
Appendix A.
Changes
§
Authors' Addresses
| TOC |
OpenID (OpenID Foundation, “OpenID Authentication 2.0 - Final,” December 2007.) [OpenID] is a three-party protocol that provides a means for a user to offer identity assertions and other attributes to a web server (Relying Party) via the help of an identity provider. The purpose of this system is to provide a way to verify that an end user controls an identifier.
Simple Authentication and Security Layer (SASL) (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) [RFC4422] (SASL) is used by application protocols such IMAP, POP and XMPP, with the goal of modularizing authentication and security layers, so that newer mechanisms can be added as needed. This memo specifies just such a mechanism.
The Generic Security Service Application Program Interface (GSS-API) (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) [RFC2743] provides a framework for applications to support multiple authentication mechanisms through a unified interface. This document defines a pure SASL mechanism for OpenID, but it conforms to the new bridge between SASL and the GSS-API called GS2 (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) [I‑D.ietf‑sasl‑gs2]. 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 is optional for SASL implementers, and the GSS-API considerations can be avoided in environments that uses SASL directly without GSS-API.
As currently envisioned, this mechanism is to allow the interworking between SASL and OpenID in order to assert identity and other attributes to relying parties. As such, while servers (as relying parties) will advertise SASL mechanisms, clients will select the OpenID mechanism.
The OpenID mechanism described in this memo aims to re-use the available OpenID specification to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS), will continued to be used.
Figure 1 (Interworking Architecture) describes the interworking between OpenID and SASL. This document requires enhancements to the Relying Party and to the Client (as the two SASL communication end points) but no changes to the OpenID Provider (OP) are necessary. To accomplish this goal indirect messaging required by the OpenID specification is tunneled within SASL.
+-----------+
| |
>| Relying |
/ | Party |
// | |
// +-----------+
// ^
OpenID // +--|--+
// | O| |
/ S | p| |
// A | e| |
// S | n| |
// L | I| |
// | D| |
</ +--|--+
+------------+ v
| | +----------+
| OpenID | OpenID | |
| Provider |<--------------->| Client |
| | | |
+------------+ +----------+
| Figure 1: Interworking Architecture |
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
The reader is assumed to be familiar with the terms used in the OpenID 2.0 specification.
| TOC |
Because this mechanism transports information that should not be controlled by an attacker, the OpenID mechanism MUST only be used over channels protected by TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246], and the client MUST successfully validate the server certificate, or similar integrity protected and authenticated channels.
| TOC |
OpenID was originally envisioned for HTTP/HTML based communications, and with the associated semantic, the idea being that the user would be redirected by the Relying Party to an identity provider who authenticates the user, and then sends identity information and other attributes (either directly or indirectly) to the Relying Party. The identity provider in the OpenID specifications is referred to as an OpenID Provider (OP). The actual protocol flow, as copied from the OpenID 2.0 specification, is as follows:
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 SASL mechanism, it is a design constraint that the OP behavior remain untouched, in order for implementations to interoperate with existing IdPs. Hence, an analog flow that interfaces the three parties needs to be created. In the analog, we note that unlike a web server, the SASL server already has some sort of session (probably a TCP connection) established with the client. However, it may be necessary to redirect a SASL client to another application. This will be discussed below. By doing so, we externalize much of the authentiction from SASL.
The steps are shown from below:
SASL Serv. Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client Empty Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional check_authenticate
| | |
|>-----(11)---->| | SASL completion with status
----- = SASL
- - - = HTTP or SSL
Note the directionality in SASL is such that the client MUST send an empty response. Specifically, it processes the redirect and then awaits a final SASL decision, while the rest of the OpenID authentication process continues.
| TOC |
To ensure that a specific request is bound, and in particular to ease interprocess communication, it may be necessary for the relying party 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 ways. Examples would include making changes to the base URI or otherwise including an additional fragment.
| TOC |
As mentioned above OpenID is primarily designed to interact with web-based applications. Portions of the authentication stream are only defined in the crudest sense. That is, when one is prompted to approve or disapprove an authentication, anything that one might find on a browser is allowed, including JavaScript, fancy style-sheets, etc. Because of this lack of structure, implementations will need to invoke a fairly rich browser in order to insure that the authentication can be completed.
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 challenge. This is not to say that nothing is happening, but rather that authentication flow has shifted from SASL to OpenID, and will 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 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 externalize the authentication to the browser, and have an empty client challenge.
| TOC |
Based on the previous figure, the following operations are performed with the OpenId SASL mechanism:
| TOC |
To advertise that a server supports OpenID, during application session initiation, it displays the name "OPENID20" in the list of supported SASL mechanisms.
| TOC |
A client initiates an OpenID authentication with SASL by sending the GS2 header followed by the XRI or URI, as specified in the OpenID specification. The GS2 header carries the optional authorization identity.
initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI | XRI ; Identifer is specified in
; Sec. 7.2 of the OpenID 2.0 spec.
The "gs2-header" is specified in [I‑D.ietf‑sasl‑gs2] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.), and it is used 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 mechanism. The "gs2-authzid" carries the optional authorization identity.
The XRI syntax is defined in [XRI2.0] (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” September 2005.). URI is specified in [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).
| TOC |
The SASL Server sends an OpenID message that contains an openid.mode of either "checkid_immediate" or "checkid_setup", as specified in Section 9.1 of the OpenID 2.0 specification.
The client now sends that request via an HTTP GET to the OP, as if redirected to do so from an HTTP server.
The client MUST handle both user authentication to the OP and confirmation or rejection of the authentiation of the RP.
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 to the Relying Party via HTTP or SSL.
| TOC |
The Relying Party now validates the response it received from the client via HTTP or SSL, as specified in the OpenID specification.
The response by the Relying Party consists of an application specific response code indicating success or failure of authentication. In the additional data, the server MAY include OpenID Simple Registry (SREG) attributes that are listed in Section 4 of [SREG1.0] (OpenID Foundation, “OpenID Simple Registration Extension version 1.0,” June 2006.). They are encoded as follows:
For example: email=lear@example.com&fullname=Eliot%20Lear
More formally:
outcome_data = [ sreg_avp *( "," sreg_avp ) ]
sreg_avp = sreg_attr "=" sreg_val
sreg_attr = sreg_word
sreg_val = sreg_word
sreg_word = 1* ( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3896
; unreserved from Section 2.3 of RFC 3896
If the application protocol allows, openid.error and openid.error_code and any other useful diagnostic information SHOULD be included in authentication failures.
| TOC |
This section and its sub-sections and all normative references of it not referenced elsewhere in this document are INFORMATIONAL for SASL implementors, but they are NORMATIVE for GSS-API implementors.
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 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.
OpenID security contexts always have the mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential delegation, therefore OpenID security contexts alway have the deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
The OpenID mechanism does not support per-message tokens or GSS_Pseudo_random.
| TOC |
OpenID supports standard generic name syntaxes for acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.), Section 4.1).
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 OpenID.
OpenID name normalization is covered by the OpenID specification, see [OpenID] (OpenID Foundation, “OpenID Authentication 2.0 - Final,” December 2007.) section 7.2.
The query, display, and exported name syntaxes for OpenID principal names are all the same. There are no OpenID-specific name syntaxes -- applications should use generic GSS-API name types such as GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.), Section 4). The exported name token does, of course, conform to [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.), Section 3.2, but the "NAME" part of the token should be treated as a potential input string to the OpenID name normalization rules.
GSS-API name attributes may be defined in the future to hold the normalized OpenID Identifier.
| TOC |
Suppose one has an OpenID of http://openid.example, and wishes to authenticate his IMAP connection to mail.example (where .example is the top level domain specified in [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” June 1999.)). The user would input his Openid into his mail user agent, when he configures the account. 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 capture results of the authentication to be redirected to the server. The authentication on the wire would then look something like the following:
(S = IMAP server; C = IMAP client)
C: < connects to IMAP port>
S: * OK
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw==
[ This is the base64 encoding of "n,,http://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z
PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p
ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt
ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w
ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v
cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls
LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA==
[ This is the base64 encoding of "http://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup"
with line breaks and spaces added here for readibility.
]
C:
[ The client now sends the URL it received to a browser for
processing. The user logs into http://openid.example, and
agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser who then connects to
https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends an empty
response, and awaits mail.example.
Server mail.example would now contact openid.example with an
openid.check_authenticate message. After that...
]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy
[ Here the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear.
Line break added in this example for clarity. ]
C:
[ In IMAP client must send a blank response to receive data
that is included in a success response. ]
S: C2 OK
| TOC |
This section will address only security considerations associated with the use of OpenID with SASL applications. For considerations relating to OpenID in general, the reader is referred to the OpenID specification and to other literature. Similarly, for general SASL Security Considerations, the reader is referred to that specification.
| TOC |
As specified in [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.), the server is responsible for binding credentials to a specific authorization identity. It is therefore necessary that either some sort of registration process takes place to register specific OpenIDs, or that only specific trusted OpenID Providers be allowed. Some out of band knowledge may help this process along. For instance, users of a particular domain may utilize a particular OP that enforces a mapping.
| TOC |
In the initial SASL client response a user or host can transmit a malicious response to the RP for purposes of taking advantage of 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 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 have access to. The URL could contain a protocol other than http or https, such as file or ftp.
To mitigate this attack, implementations should carefully analyze URLs received, eliminating any that would in some way be privileged. A log of those sites that fail SHOULD be kept, and limitations on queries from clients should be imposed, just as with any other authentication attempt.
| TOC |
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.
| TOC |
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 requirement to track the visits, but there is nothing that prohibits the collection of information. SASL servers should be aware that OpenID Providers will be track - to some extent - user access to their services and any additional information that OP provides.
| TOC |
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.
| TOC |
The IANA is requested to register the following SASL profile:
SASL mechanism profile: OPENID20
Security Considerations: See this document
Published Specification: See this document
For further information: Contact the authors of this document.
Owner/Change controller: the IETF
Note: None
| TOC |
The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their review and contributions.
| TOC |
| TOC |
This section to be removed prior to publication.
| TOC |
| Eliot Lear | |
| Cisco Systems GmbH | |
| Richtistrasse 7 | |
| Wallisellen, ZH CH-8304 | |
| Switzerland | |
| Phone: | +41 44 878 9200 |
| Email: | lear@cisco.com |
| Hannes Tschofenig | |
| Nokia Siemens Networks | |
| Linnoitustie 6 | |
| Espoo 02600 | |
| Finland | |
| Phone: | +358 (50) 4871445 |
| Email: | Hannes.Tschofenig@gmx.net |
| URI: | http://www.tschofenig.priv.at |
| Henry Mauldin | |
| Cisco Systems, Inc. | |
| 170 West Tasman Drive | |
| San Jose, CA 95134 | |
| USA | |
| Phone: | +1 (800) 553-6387 |
| Email: | hmauldin@cisco.com |
| Simon Josefsson | |
| SJD AB | |
| Hagagatan 24 | |
| Stockholm 113 47 | |
| SE | |
| Email: | simon@josefsson.org |
| URI: | http://josefsson.org/ |