< draft-lear-ietf-sasl-openid-00.txt   draft-lear-ietf-sasl-openid-01.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: July 23, 2010 Nokia Siemens Networks Expires: January 8, 2011 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
January 19, 2010 S. Josefsson
SJD AB
July 7, 2010
A SASL Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-lear-ietf-sasl-openid-00.txt draft-lear-ietf-sasl-openid-01
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) is an application Simple Authentication and Security Layer (SASL) and the Generic
framework to generalize authentication. This memo specifies a SASL Security Service Application Program Interface (GSS-API) are
mechanism for OpenID that allows the integration of existing OpenID application frameworks to generalize authentication. This memo
Identity Providers with applications using SASL. 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 47
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2010. This Internet-Draft will expire on January 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5
2.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 10 3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5.1. Binding OpenIDs to Authorization Identities . . . . . . . 14 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. RP redirected by malicious URL to take an improper 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
action . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15
5.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 14 6.2. RP redirected by malicious URL to take an improper
5.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 action . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 15 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
OpenID [OpenID] is a three-party protocol that provides a means for a OpenID [OpenID] is a three-party protocol that provides a means for a
user to offer identity assertions and other attributes to a web user to offer identity assertions and other attributes to a web
server (Relying Party) via the help of an identity provider. The 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 purpose of this system is to provide a way to verify that an end user
controls an identifier. 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, POP and XMPP, with the goal
of modularizing authentication and security layers, so that newer of modularizing authentication and security layers, so that newer
mechanisms can be added as needed. This memo specifies just such a mechanisms can be added as needed. This memo specifies just such a
mechanism. mechanism.
The Generic Security Service Application Program Interface (GSS-API)
[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 [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 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
available OpenID specification to a maximum extent and therefore does available OpenID specification to a maximum extent and therefore does
not establish a separate authentication, integrity and not establish a separate authentication, integrity and
confidentiality mechanism. It is anticipated that existing security confidentiality mechanism. It is anticipated that existing security
skipping to change at page 5, line 5 skipping to change at page 4, line 38
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terms used in the The reader is assumed to be familiar with the terms used in the
OpenID 2.0 specification. OpenID 2.0 specification.
1.2. Applicability
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 [RFC5246], and the client MUST
successfully validate the server certificate, or similar integrity
protected and authenticated channels.
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/HTML based communications,
and with the associated semantic, the idea being that the user would and with the associated semantic, the idea being that the user would
be redirected by the Relying Party to an identity provider who be redirected by the Relying Party to an identity provider who
authenticates the user, and then sends identity information and other authenticates the user, and then sends identity information and other
attributes (either directly or indirectly) to the Relying Party. The attributes (either directly or indirectly) to the Relying Party. The
actual protocol flow, as copied from the OpenID 2.0 specification, is identity provider in the OpenID specifications is referred to as an
as follows: OpenID 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, the Relying Party
performs discovery on it and establishes the OP Endpoint URL that performs discovery on it and establishes the OP Endpoint URL that
the end user uses for authentication. It should be noted that the end user uses for authentication. It should be noted that
the User-Supplied Identifier may be an OP Identifier, which the User-Supplied Identifier may be an OP Identifier, which
allows selection of a Claimed Identifier at the OP or for the allows selection of a Claimed Identifier at the OP or for the
skipping to change at page 8, line 37 skipping to change at page 8, line 37
|>-----(11)---->| | SASL completion with status |>-----(11)---->| | SASL completion with status
----- = SASL ----- = SASL
- - - = HTTP or SSL - - - = HTTP or SSL
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. Discussion 2.1. Binding SASL to OpenID in the Relying Party
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.
2.2. Discussion
As mentioned above OpenID is primarily designed to interact with web- As mentioned above OpenID is primarily designed to interact with web-
based applications. Portions of the authentication stream are only based applications. Portions of the authentication stream are only
defined in the crudest sense. That is, when one is prompted to defined in the crudest sense. That is, when one is prompted to
approve or disapprove an authentication, anything that one might find approve or disapprove an authentication, anything that one might find
on a browser is allowed, including JavaScript, fancy style-sheets, on a browser is allowed, including JavaScript, fancy style-sheets,
etc. Because of this lack of structure, implementations will need to etc. Because of this lack of structure, implementations will need to
invoke a fairly rich browser in order to insure that the invoke a fairly rich browser in order to insure that the
authentication can be completed. authentication can be completed.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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 empty
client challenge. client challenge.
3. OpenID SASL Mechanism Specification 3. OpenID SASL Mechanism Specification
Based on the previous figure, the following operations are performed Based on the previous figure, the following operations are performed
with the OPENID SASL mechanism: with the OpenId SASL mechanism:
3.1. Advertisement 3.1. Advertisement
To advertise that a server supports OpenID, during application To advertise that a server supports OpenID, during application
session initiation, it displays the name "OPENID" in the list of session initiation, it displays the name "OPENID2.0" in the list of
supported SASL mechanisms. supported SASL mechanisms.
3.2. Initiation 3.2. Initiation
A client initiates an OpenID authentication with SASL by the XRI or A client initiates an OpenID authentication with SASL by sending the
URI, as specified in the OpenID specification. Additionally, the GS2 header followed by the XRI or URI, as specified in the OpenID
supported version of OpenID is indicated. specification. The GS2 header carries the optional authorization
identity.
initial-response = Identifier UTF8NUL openid-version initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI | XRI ; Identifer is specified in Identifier = URI | XRI ; Identifer is specified in
; Sec. 7.2 of the OpenID 2.0 spec. ; Sec. 7.2 of the OpenID 2.0 spec.
; XRI as specified by OASIS 2.0 Syntax
; URI is specified in RFC 3986.
openid-version = 1*DIGIT [ "." 1*DIGIT ]
The XRI syntax is defined in [XRI2.0]. 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-
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]. URI is specified in
[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.
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.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 3896
; unreserved from Section 2.3 of RFC 3896 ; unreserved from Section 2.3 of RFC 3896
If the application protocol allows, openid.error and If the application protocol allows, openid.error and
openid.error_code and any other useful diagnostic information SHOULD openid.error_code and any other useful diagnostic information SHOULD
be included in authentication failures. be included in authentication failures.
4. Example 4. OpenID GSS-API Mechanism Specification
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.
4.1. GSS-API Principal Name Types for OpenID
OpenID supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 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] 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],
Section 4). The exported name token does, of course, conform to
[RFC2743], 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.
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 The authentication on the wire would then look something like the
following: 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=OPENID S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID aHR0cDovL29wZW5pZC5leGFtcGxlLwAy C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw==
[ This is the base64 encoding of "http://openid.example/\02" [ 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. with line breaks and spaces added here for readibility.
Server performs discovery on https://openid.example/ ]
S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5zPWh
0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5pZC5yZX
R1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3VtZXImb3Blb
mlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8mb3Bl
bmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1wbGUvJm9wZW5
pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW5pZC5tb2RlPW
NoZWNraWRfc2V0dXA=
[ 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
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup
] ]
C: C:
[ 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 an empty
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: C2 OK [OPENID ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbW S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
U9RWxpb3QlMjBMZWFy] authenticated. 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:
[ In IMAP client must send a blank response to receive data
that is included in a success response. ]
S: C2 OK
5. 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.
5.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.
5.2. RP redirected by malicious URL to take an improper action 6.2. RP redirected by malicious URL to take an improper action
In the initial SASL client response a user or host can transmit a In the initial SASL client response a user or host can transmit a
malicious to the RP for purposes of taking advantage of weaknesses in malicious response to the RP for purposes of taking advantage of
the RP's OpenID implementation. It is possible to add port numbers weaknesses in the RP's OpenID implementation. It is possible to add
to the URL so that the outcome is the RP does a port scan of the port numbers to the URL so that the outcome is the RP does a port
site. The URL could send the connection to an internal host or even scan of the site. The URL could send the connection to an internal
the local host, which the attacker would not normally have access to. host or even the local host, which the attacker would not normally
The URL could contain a protocol other than http or https, such as have access to. The URL could contain a protocol other than http or
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.
5.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
in as much as the client is not configured with the Relying Party in as much as the client is not configured with the Relying Party
(e.g., SASL server) in a safe manner. (e.g., SASL server) in a safe manner.
5.4. User Privacy 6.4. User Privacy
The OP is aware of each RP that a user logs into. There is nothing The OP is aware of each RP that a user logs into. There is nothing
in the protocol to hide this information from the OP. It is not a in the protocol to hide this information from the OP. It is not a
requirement to track the visits, but there is nothing that prohibits requirement to track the visits, but there is nothing that prohibits
the collection of information. SASL servers should be aware that the collection of information. SASL servers should be aware that
OpenID Providers will be track - to some extent - user access to OpenID Providers will be track - to some extent - user access to
their services and any additional information that OP provides. their services and any additional information that OP provides.
5.5. Collusion between RPs 6.5. Collusion between RPs
It is possible for RPs to link data that they have collected on you. 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 By using the same identifier to log into every RP, collusion between
RPs is possible. In OpenID 2.0, directed identity was introduced. RPs is possible. In OpenID 2.0, directed identity was introduced.
Directed identity allows the OP to transform the identifier the user Directed identity allows the OP to transform the identifier the user
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.
6. IANA Considerations 7. 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: OPENID SASL mechanism profile: 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. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Owner/Change controller: the IETF
Note: None Note: None
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark
Crispin, and Klaas Wierenga for their review and contributions. Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their
review and contributions.
8. Normative References 9. 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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 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
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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.
Appendix A. Changes Appendix A. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 01 Add nonce discussion, add authorized identity, explain a
definition.
o 00 Initial Revision. o 00 Initial Revision.
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
skipping to change at line 609 skipping to change at page 21, line 34
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henry Mauldin Henry Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (800) 553-6387 Phone: +1 (800) 553-6387
Email: hmauldin@cisco.com Email: hmauldin@cisco.com
Simon Josefsson
SJD AB
Hagagatan 24
Stockholm 113 47
SE
Email: simon@josefsson.org
URI: http://josefsson.org/
 End of changes. 40 change blocks. 
81 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/