draft-ietf-kitten-sasl-openid-06.txt   draft-ietf-kitten-sasl-openid-07.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: March 30, 2012 Nokia Siemens Networks Expires: May 26, 2012 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
September 27, 2011 November 23, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-06 draft-ietf-kitten-sasl-openid-07
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 March 30, 2012. This Internet-Draft will expire on May 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 Simplified BSD License. described in the Simplified 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 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 2. Applicability for application protocols other than HTTP . . . 5
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 9
3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 11 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 10
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 13 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 13 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 18 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 17
6.2. RP redirected by malicious URL to take an improper 6.2. RP redirected by malicious URL to take an improper
action . . . . . . . . . . . . . . . . . . . . . . . . . . 18 action . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 17
7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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 [RFC6120], with the goal of modularizing authentication and
security layers, so that newer mechanisms can be added as needed. security layers, so that newer mechanisms can be added as needed.
This memo specifies just such a mechanism. This memo specifies just such a mechanism.
The Generic Security Service Application Program Interface (GSS-API) The Generic Security Service Application Program Interface (GSS-API)
[RFC2743] provides a framework for applications to support multiple [RFC2743] provides a framework for applications to support multiple
authentication mechanisms through a unified interface. This document authentication mechanisms through a unified interface. This document
defines a pure SASL mechanism for OpenID, but it conforms to the new defines a pure SASL mechanism for OpenID, but it conforms to the new
bridge between SASL and the GSS-API called GS2 [RFC5801]. This means bridge between SASL and the GSS-API called GS2 [RFC5801]. This means
that this document defines both a SASL mechanism and a GSS-API that this document defines both a SASL mechanism and a GSS-API
mechanism. Implementors of the SASL component MAY implement the GSS- mechanism. Implementors of the SASL component MAY implement the GSS-
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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. Minimal changes
specification is appropriate for use when a browser is available. are required to non-web applications, as most of the transaction
occurs through a normal web browser. Hence, this specification is
only appropriate for use when such 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 through messaging required by the OpenID specification is tunneled through
the SASL/GSS-API mechanism. the SASL/GSS-API mechanism.
+-----------+ +-----------+
| | | |
skipping to change at page 4, line 43 skipping to change at page 4, line 43
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terms used in the The reader is assumed to be familiar with the terms used in the
OpenID 2.0 specification. OpenID 2.0 specification.
1.2. Applicability 1.2. Applicability
Because this mechanism transports information that should not be Because this mechanism transports information that should not be
controlled by an attacker, the OpenID mechanism MUST only be used controlled by an attacker, the OpenID mechanism MUST only be used
over channels protected by TLS, 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. [RFC5280][RFC6125]
authenticated channels. [RFC5280][RFC6125]
2. Applicability for non-HTTP Use Cases 2. Applicability for application protocols other than HTTP
OpenID was originally envisioned for HTTP [RFC2616] and 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 can be found in Section 3 of
2.0 specification, is as follows: the OpenID 2.0 specification [OpenID]. The reader is strongly
encouraged to be familiar with the specification before continuing.
1. The end user initiates authentication by presenting a User-
Supplied Identifier to the Relying Party via their User-Agent
(e.g., https://user.example.com).
2. After normalizing the User-Supplied Identifier as described in
Section 7.2 of [OpenID], the Relying Party performs discovery on
the URI specified and establishes the OP Endpoint URL that the
end user uses for authentication. It should be noted that the
User-Supplied Identifier may be an OP Identifier, which allows
selection of a Claimed Identifier at the OP or for the protocol
to proceed without a Claimed Identifier if something else useful
is being done via an extension.
3. The Relying Party and the OP optionally establish an association
-- a shared secret established using Diffie-Hellman Key Exchange.
The OP uses an association to sign subsequent messages and the
Relying Party to verify those messages; this removes the need for
subsequent direct requests to verify the signature after each
authentication request/response. This process is desccribed in
Section 8 of [OpenID].
4. The Relying Party redirects the end user's User-Agent to the OP
with an OpenID Authentication request. This occurs as stated in
Section 10.3 of [RFC2616].
5. The OP authenticates the end user and establishes whether the end
user will authenticate to, and share specific attributes with,
the Relying Party. For instance, the OP often asks the user what
to do. The manner in which the end user authenticates to their
OP and any policies surrounding such authentication is out of
scope of OpenID.
6. The OP redirects the end user's User-Agent back to the Relying
Party with either an assertion that authentication is approved or
a message that authentication failed.
7. The Relying Party verifies the information received from the OP
including checking the Return URL, verifying the discovered
information, checking the nonce, and verifying the signature by
using either the shared key established during the association or
by sending a direct request to the OP.
When considering this flow in the context of SASL, we note that while When considering that flow in the context of SASL, we note that while
the RP and the client both need to change their code to implement the RP and the client both need to change their code to implement
this SASL mechanism, it is a design constraint that the OP behavior this SASL mechanism, it is a design constraint that the OP behavior
remain untouched, in order for implementations to interoperate with remain untouched, in order for implementations to interoperate with
existing IdPs. Hence, an analog flow that interfaces the three existing IdPs. Hence, an analog flow that interfaces the three
parties needs to be created. In the analog, we note that unlike a parties needs to be created. In the analog, we note that unlike a
web server, the SASL server already has some sort of session web server, the SASL server already has some sort of session
(probably a TCP connection) established with the client. However, it (probably a TCP connection) established with the client. However, it
may be necessary for a SASL client to invoke to another application. may be necessary for a SASL client to invoke to another application.
This will be discussed below. By doing so, we externalize much of This will be discussed below. By doing so, we externalize much of
the authentiction from SASL. the authentiction from SASL.
skipping to change at page 8, line 39 skipping to change at page 7, line 39
----- = SASL ----- = SASL
- - - = HTTPS - - - = HTTPS
Note the directionality in SASL is such that the client MUST send the Note the directionality in SASL is such that the client MUST send the
"=" response. Specifically, the SASL client processes the redirect "=" response. Specifically, the SASL client processes the redirect
and then awaits a final SASL decision, while the rest of the OpenID and then awaits a final SASL decision, while the rest of the OpenID
authentication process continues. authentication process continues.
2.1. Binding SASL to OpenID in the Relying Party 2.1. Binding SASL to OpenID in the Relying Party
To ensure that a specific request is bound, and in particular to ease OpenID is meant to be used in serial within the web, where browser
interprocess communication, it may be necessary for the relying party cookies are easily accessible. As such, there are no transaction-ids
to encode some sort of nonce or transaction-id in the URIs it within the protocol. To ensure that a specific request is bound, and
transmits through the client for success or failure. This can be in particular to ease interprocess communication, the relying party
done in any number of ways. Examples would include making changes to MUST encode a nonce or transaction-id in the URIs it transmits
the base URI or otherwise including an additional fragment. through the client for success or failure, either as a base URI or
fragment component to the "return_to" URI. This value is to be used
to uniquely identify each authentication transaction.
2.2. Discussion 2.2. Discussion
As mentioned above OpenID is primarily designed to interact with web- As mentioned above OpenID is primarily designed to interact with web-
based applications. Portions of the authentication stream are only based applications. Portions of the authentication stream are only
defined in the crudest sense. That is, when one is prompted to defined in the crudest sense. That is, when one is prompted to
approve or disapprove an authentication, anything that one might find approve or disapprove an authentication, anything that one might find
on a browser is allowed, including JavaScript, fancy style-sheets, on a browser is allowed, including JavaScript, fancy style-sheets,
etc. Because of this lack of structure, implementations will need to etc. Because of this lack of structure, implementations will need to
invoke a fairly rich browser in order to ensure that the invoke a fairly rich browser in order to ensure that the
authentication can be completed. authentication can be completed.
Once there is an outcome, the SASL server needs to know about it. Once there is an outcome, the SASL server needs to know about it.
The astute will hopefully by now have noticed an "=" client SASL The astute will hopefully by now have noticed an "=" client SASL
response. This is not to say that nothing is happening, but rather response. This is not to say that nothing is happening, but rather
that authentication flow has shifted from SASL to OpenID, and will that authentication flow has shifted from SASL and the client
return when the server has an outcome to hand to the client. The application to OpenID within the browser, and will return to the
alternative to this flow is some signal from the HTML browser to the client application when the server has an outcome to hand to the
SASL client of the results that is in turn passed to the SASL server. client. The alternative to this flow would be some sort of signal
The IPC issue this raises is substantial. Better, we conclude, to from the HTML browser to the SASL client of the results that would in
turn be passed to the SASL server. The inter-process communication
issue this raises is substantial. Better, we conclude, to
externalize the authentication to the browser, and have an "=" client externalize the authentication to the browser, and have an "=" client
response. response.
OpenID is also meant to be used in serial within the web. As such,
there are no transaction-ids within the protocol. A transaction id,
MUST be included by the RP by appending it to the return_to URL.
3. OpenID SASL Mechanism Specification 3. OpenID SASL Mechanism Specification
This section specifies the details of the OpenID SASL mechanism. This section specifies the details of the OpenID SASL mechanism.
Recall section 5 of [RFC4422] for what needs to be described here. Recall section 5 of [RFC4422] for what needs to be described here.
The name of this mechanism "OPENID20". The mechanism is capable of The name of this mechanism "OPENID20". The mechanism is capable of
transferring an authorization identity (via "gs2-header"). The transferring an authorization identity (via "gs2-header"). The
mechanism does not offer a security layer. mechanism does not offer a security layer.
The mechanism is client-first. The first mechanism message from the The mechanism is client-first. The first mechanism message from the
skipping to change at page 15, line 11 skipping to change at page 14, line 11
GSS-API name attributes may be defined in the future to hold the GSS-API name attributes may be defined in the future to hold the
normalized OpenID Identifier. normalized OpenID Identifier.
5. Example 5. Example
Suppose one has an OpenID of https://openid.example, and wishes to Suppose one has an OpenID of https://openid.example, and wishes to
authenticate his IMAP connection to mail.example (where .example is authenticate his IMAP connection to mail.example (where .example is
the top level domain specified in [RFC2606]). The user would input the top level domain specified in [RFC2606]). The user would input
his Openid into his mail user agent, when he configures the account. his Openid into his mail user agent, when he configures the account.
In this case, no association is attempted between the OpenID Consumer In this case, no association is attempted between the OpenID RP and
and the OP. The client will make use of the return_to attribute to the OP. The client will make use of the return_to attribute to
capture results of the authentication to be redirected to the server. capture results of the authentication to be redirected to the server.
Note the use of [RFC4959] for initial response. The authentication Note the use of [RFC4959] for initial response. The authentication
on the wire would then look something like the following: on the wire would then look something like the following:
(S = IMAP server; C = IMAP client) (S = IMAP server; C = IMAP client)
C: < connects to IMAP port> C: < connects to IMAP port>
S: * OK S: * OK
C: C1 CAPABILITY C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
skipping to change at page 18, line 19 skipping to change at page 17, line 19
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 specification and to other literature
<http://sites.google.com/site/openidreview/resources>. Similarly, <http://sites.google.com/site/openidreview/resources>. Similarly,
for general SASL [RFC4422] and GSS-API [RFC5801] Security for general SASL [RFC4422] and GSS-API [RFC5801] Security
Considerations, the reader is referred to those specifications. Considerations, the reader is referred to those specifications.
6.1. Binding OpenIDs to Authorization Identities 6.1. Binding OpenIDs to Authorization Identities
As specified in [RFC4422], the server is responsible for binding As specified in [RFC4422], the server is responsible for binding
credentials to a specific authorization identity. It is therefore credentials to a specific authorization identity. It is therefore
necessary that either some sort of registration process takes place necessary that a registration process takes place in advance that
to register specific OpenIDs, or that only specific trusted OpenID binds specific OpenIDs to specific authorization identities, or that
Providers be allowed. Some out of band knowledge may help this only specific trusted OpenID Providers be allowed, where a mapping is
process along. For instance, users of a particular domain may predefined. For example, it could be pre-arranged between an IdP and
utilize a particular OP that enforces a mapping. RP that "https://example.com/user" maps to "user" for purposes of
authorization.
6.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 response to the RP for purposes of taking advantage of malicious response to the RP for purposes of taking advantage of
weaknesses in the RP's OpenID implementation. It is possible to add weaknesses in the RP's OpenID implementation. It is possible to add
port numbers to the URL so that the outcome is the RP does a port port numbers to the URL so that the outcome is the RP does a port
scan of the site. The URL could send the connection to an internal scan of the site. The URL could contain an unauthorized host or even
host or even the local host, which the attacker would not normally the local host. The URL could contain a protocol other than http or
have access to. The URL could contain a protocol other than http or
https, such as file or ftp. https, such as file or ftp.
To mitigate this attack, implementations should carefully analyze One mitigation would be for RPs to have a list of authorized URI
URLs received, eliminating any that would in some way be privileged. bases. OPs SHOULD only redirect to RPs with the same domain
A log of those sites that fail SHOULD be kept, and limitations on component of the base URI. RPs MUST NOT automatically retry on
queries from clients SHOULD be imposed, just as with any other failed attempts. A log of those sites that fail SHOULD be kept, and
authentication attempt. It is RECOMMENDED that only http or https limitations on queries from clients SHOULD be imposed, just as with
schemes be accepted. any other authentication attempt. Applications SHOULD NOT invoke
browsers to communicate with OPs that they are not themselves
configured with.
6.3. User Privacy 6.3. User Privacy
The OP is aware of each RP that a user logs into. There is nothing The OP is aware of each RP that a user logs into. There is nothing
in the protocol to hide this information from the OP. It is not a in the protocol to hide this information from the OP. It is not a
requirement to track the visits, but there is nothing that prohibits requirement to track the visits, but there is nothing that prohibits
the collection of information. SASL servers should be aware that the collection of information. SASL servers should be aware that
OpenID Providers will be able to track - to some extent - user access OpenID Providers will be able to track - to some extent - user access
to their services and any additional information that OP provides. to their services and any additional information that OP provides.
7. Room for Improvement 7. IANA Considerations
We note one area where there is possible room for improvement over
existing OpenID implementations. Because SASL is often implemented
atop protocols that have required some amount of provisioning, it may
be possible for the SASL client to signal the browser that the given
URL is the beginning of a sensitive transaction, and that increased
scrutiny should be given. A signal of some form would need to come
from an appropriately authorized agent that the sensitive transaction
is complete. An example behavior during this sensitive period might
be increased scrutiny of broken trust chains in certificates, or
perhaps disallowing such trust chains altogether.
8. IANA Considerations
The IANA is requested to update the SASL Mechanism Registry using the The IANA is requested to update the SASL Mechanism Registry using the
following template, as described in [RFC4422]. following template, as described in [RFC4422].
SASL mechanism name: 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
skipping to change at page 21, line 5 skipping to change at page 19, line 5
Owner/Change controller: IETF Owner/Change controller: IETF
Note: None Note: None
The IANA is further requested to assign an OID for this GSS mechanism The IANA is further requested to assign an OID for this GSS mechanism
in the SMI numbers registry, with the prefix of in the SMI numbers registry, with the prefix of
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
reference this specification in the registry. reference this specification in the registry.
9. Acknowledgments 8. Acknowledgments
The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams,
and Klaas Wierenga for their review and contributions. Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review
and contributions.
10. References 9. References
10.1. Normative References 9.1. Normative References
[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.
skipping to change at page 23, line 12 skipping to change at page 21, line 12
(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
(XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs,
September 2005. September 2005.
10.2. Informative References 9.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial Simple Authentication and Security Layer (SASL) Initial
Client Response", RFC 4959, September 2007. Client Response", RFC 4959, September 2007.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "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 04 - 07 04 - 07 address LC and review comments, including those of
Stephen Farrell, Steve Kent, and Brian Carpenter.
o 03 Clarifies messages and ordering, and replace the empty message o 03 Clarifies messages and ordering, and replace the empty message
with a "=" message. with a "=" message.
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
 End of changes. 29 change blocks. 
132 lines changed or deleted 84 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/