draft-ietf-kitten-sasl-openid-00.txt   draft-ietf-kitten-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: February 14, 2011 Nokia Siemens Networks Expires: August 4, 2011 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
August 13, 2010 January 31, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-00 draft-ietf-kitten-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) 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.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on August 4, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
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 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 non-HTTP Use Cases . . . . . . . . . . . . . 5
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10
skipping to change at page 2, line 40 skipping to change at page 2, line 35
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15
6.2. RP redirected by malicious URL to take an improper 6.2. RP redirected by malicious URL to take an improper
action . . . . . . . . . . . . . . . . . . . . . . . . . . 15 action . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15
6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 20 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 10, line 5 skipping to change at page 9, line 20
The astute will hopefully by now have noticed an empty client SASL The astute will hopefully by now have noticed an empty client SASL
challenge. This is not to say that nothing is happening, but rather challenge. This is not to say that nothing is happening, but rather
that authentication flow has shifted from SASL to OpenID, and will that authentication flow has shifted from SASL to OpenID, and will
return when the server has an outcome to hand to the client. The return when the server has an outcome to hand to the client. The
alternative to this flow is some signal from the HTML browser to the alternative to this flow is some signal from the HTML browser to the
SASL client of the results that is in turn passed to the SASL server. SASL client of the results that is in turn passed to the SASL server.
The IPC issue this raises is substantial. Better, we conclude, to The IPC issue this raises is substantial. Better, we conclude, to
externalize the authentication to the browser, and have an empty externalize the authentication to the browser, and have an empty
client challenge. client challenge.
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,
can be included by the RP by appending it to the return_to URL.
3. OpenID SASL Mechanism Specification 3. OpenID SASL Mechanism Specification
Based on the previous figure, the following operations are performed 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 "OPENID20" in the list of session initiation, it displays the name "OPENID20" in the list of
supported SASL mechanisms. supported SASL mechanisms.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
The XRI syntax is defined in [XRI2.0]. URI is specified in The XRI syntax is defined in [XRI2.0]. URI is specified in
[RFC3986]. [RFC3986].
3.3. Authentication Request 3.3. Authentication Request
The SASL Server sends an OpenID message that contains an openid.mode The SASL Server sends an OpenID message that contains an openid.mode
of either "checkid_immediate" or "checkid_setup", as specified in of either "checkid_immediate" or "checkid_setup", as specified in
Section 9.1 of the OpenID 2.0 specification. Section 9.1 of the OpenID 2.0 specification.
As part of this request, the SASL server MUST append a unique
transaction id to the &quote;return_to" portion of the request. The
form of this transaction is left to the RP to decide, but SHOULD be
large enough to be resistant to being guessed or attacked.
The client now sends that request via an HTTP GET to the OP, as if The client now sends that request via an HTTP GET to the OP, as if
redirected to do so from an HTTP server. redirected to do so from an HTTP server.
The client MUST handle both user authentication to the OP and The client MUST handle both user authentication to the OP and
confirmation or rejection of the authentiation of the RP. confirmation or rejection of the authentiation of the RP.
After all authentication has been completed by the OP, and after the After all authentication has been completed by the OP, and after the
response has been sent to the client, the client will relay the response has been sent to the client, the client will relay the
response to the Relying Party via HTTP or SSL. response to the Relying Party via HTTP or SSL.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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.
7. IANA Considerations 7. Room for Improvement
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 it should
increase scrutiny of invalid credentials. How this would be done is
beyond the scope of this specification, but may be the subject of
future updates. For instance, the browser may wish to fail the
request entirely if the certificate is invalid and has not been
accessed prior to this point. One thing that this would require
would be the exposure of a "return_to" URL by the SASL server in case
of such failures, so that the authentication is not left hanging.
8. IANA Considerations
The IANA is requested to register the following SASL profile: The IANA is requested to register the following SASL profile:
SASL mechanism profile: OPENID20 SASL mechanism profile: OPENID20
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
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
8. Acknowledgments 9. Acknowledgments
The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their
review and contributions. review and contributions.
9. Normative References 10. Normative References
[I-D.ietf-sasl-gs2] [I-D.ietf-sasl-gs2]
Josefsson, S. and N. Williams, "Using GSS-API Mechanisms Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20
(work in progress), January 2010. (work in progress), January 2010.
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007. December 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 20, line 9 skipping to change at page 21, line 9
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 Specific text around possible improvements for OOB browser
control in security considerations. Also talk about transaction
id.
o 00 WG -00 draft. Slight wording modifications abou design o 00 WG -00 draft. Slight wording modifications abou design
constraints per Alexey. constraints per Alexey.
o 02 Correct single (significant) error on mechanism name. o 02 Correct single (significant) error on mechanism name.
o 01 Add nonce discussion, add authorized identity, explain a o 01 Add nonce discussion, add authorized identity, explain a
definition. Add gs2 support. definition. Add gs2 support.
o 00 Initial Revision. o 00 Initial Revision.
 End of changes. 15 change blocks. 
24 lines changed or deleted 47 lines changed or added

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