draft-ietf-kitten-sasl-openid-03.txt   draft-ietf-kitten-sasl-openid-04.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: December 16, 2011 Nokia Siemens Networks Expires: January 12, 2012 Nokia Siemens Networks
H. Mauldin H. Mauldin
Cisco Systems, Inc. Cisco Systems, Inc.
S. Josefsson S. Josefsson
SJD AB SJD AB
June 14, 2011 July 11, 2011
A SASL & GSS-API Mechanism for OpenID A SASL & GSS-API Mechanism for OpenID
draft-ietf-kitten-sasl-openid-03 draft-ietf-kitten-sasl-openid-04
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 December 16, 2011. This Internet-Draft will expire on January 12, 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 11, line 12 skipping to change at page 11, line 12
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.2. Authentication Request 3.2. Authentication Request
The SASL Server sends the URL resulting from the OpenID The SASL Server sends the URL resulting from the OpenID
authentication request, containing an "openid.mode" of either authentication request, containing an "openid.mode" of either
"checkid_immediate" or "checkid_setup", as specified in Section 9.1 "checkid_immediate" or "checkid_setup", as specified in Section 9.1
of the OpenID 2.0 specification. of the OpenID 2.0 specification.
authentication_request = URI authentication-request = URI
As part of this request, the SASL server MUST append a unique As part of this request, the SASL server MUST append a unique
transaction id to the "return_to" portion of the request. The form transaction id to the "return_to" portion of the request. The form
of this transaction is left to the RP to decide, but SHOULD be large of this transaction is left to the RP to decide, but SHOULD be large
enough to be resistant to being guessed or attacked. enough to be resistant to being guessed or attacked.
The client now sends that request via an HTTP GET to the OP, as if The client now sends that request via an HTTP GET to the OP, as if
redirected to do so from an HTTP server. redirected to do so from an HTTP server.
The client MUST handle both user authentication to the OP and The client MUST handle both user authentication to the OP and
skipping to change at page 12, line 5 skipping to change at page 12, line 5
1. Strip "openid.sreg." from each attribute name. 1. Strip "openid.sreg." from each attribute name.
2. Treat the concatentation of results as URI parameters that are 2. Treat the concatentation of results as URI parameters that are
separated by an ambersand (&) and encode as one would a URI, separated by an ambersand (&) and encode as one would a URI,
absent the scheme, authority, and the question mark. absent the scheme, authority, and the question mark.
For example: email=lear@example.com&fullname=Eliot%20Lear For example: email=lear@example.com&fullname=Eliot%20Lear
More formally: More formally:
outcome_data = [ sreg_avp *( "," sreg_avp ) ] outcome-data = [ sreg-avp *( "," sreg-avp ) ]
sreg_avp = sreg_attr "=" sreg_val sreg-avp = sreg-attr "=" sreg-val
sreg_attr = sreg_word sreg-attr = sreg-word
sreg_val = sreg_word sreg-val = sreg-word
sreg_word = 1* ( unreserved / pct-encoded ) sreg-word = 1*( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3986 ; pct-encoded from Section 2.1 of RFC 3986
; unreserved from Section 2.3 of RFC 3986 ; unreserved from Section 2.3 of RFC 3986
In the case of failures, the response MUST follow this syntax: In the case of failures, the response MUST follow this syntax:
outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp ) outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp )
3.4. Error Handling 3.4. Error Handling
[RFC4422] Section 3.6 explicitly prohibits additional information in [RFC4422] Section 3.6 explicitly prohibits additional information in
skipping to change at page 13, line 22 skipping to change at page 13, line 22
OpenID user takes the role of the GSS-API Initiator and the OpenID OpenID user takes the role of the GSS-API Initiator and the OpenID
Relying Party takes the role of the GSS-API Acceptor. The OpenId Relying Party takes the role of the GSS-API Acceptor. The OpenId
Provider does not have a role in GSS-API, and is considered an Provider does not have a role in GSS-API, and is considered an
internal matter for the OpenID mechanism. The messages are the same, internal matter for the OpenID mechanism. The messages are the same,
but a) the GS2 header on the client's first message and channel 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, 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 and b) the RFC2743 section 3.1 initial context token header is
prefixed to the client's first authentication message (context prefixed to the client's first authentication message (context
token). token).
The GSS-API mechanism OID for OpenID is 1.3.6.1.4.1.11591.4.5. The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see
IANA considerations).
OpenID security contexts always have the mutual_state flag OpenID security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential
delegation, therefore OpenID security contexts alway have the delegation, therefore OpenID security contexts alway have the
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
The mutual authentication property of this mechanism relies on The mutual authentication property of this mechanism relies on
successfully comparing the TLS server identity with the negotiated successfully comparing the TLS server identity with the negotiated
target name. Since the TLS channel is managed by the application target name. Since the TLS channel is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to outside of the GSS-API mechanism, the mechanism itself is unable to
skipping to change at page 22, line 5 skipping to change at page 21, line 25
Person & email address to contact for further information: Authors of Person & email address to contact for further information: Authors of
this document this document
Intended usage: COMMON Intended usage: COMMON
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
in the SMI numbers registry, with the prefix of
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
reference this specification in the registry.
9. Acknowledgments 9. 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. and Klaas Wierenga for their review and contributions.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 24, line 28 skipping to change at page 24, line 28
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. 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.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
Appendix A. Changes Appendix A. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 03 Clarifies messages and ordering, and replace the empty message o 03 Clarifies messages and ordering, and replace the empty message
with a "=" message. with a "=" message.
 End of changes. 9 change blocks. 
12 lines changed or deleted 18 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/