draft-ietf-kitten-sasl-saml-04.txt   draft-ietf-kitten-sasl-saml-05.txt 
Network Working Group K. Wierenga Network Working Group K. Wierenga
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track E. Lear Intended status: Standards Track E. Lear
Expires: January 12, 2012 Cisco Systems GmbH Expires: May 3, 2012 Cisco Systems GmbH
S. Josefsson S. Josefsson
SJD AB SJD AB
July 11, 2011 October 31, 2011
A SASL and GSS-API Mechanism for SAML A SASL and GSS-API Mechanism for SAML
draft-ietf-kitten-sasl-saml-04.txt draft-ietf-kitten-sasl-saml-05.txt
Abstract Abstract
Security Assertion Markup Language (SAML) has found its usage on the Security Assertion Markup Language (SAML) has found its usage on the
Internet for Web Single Sign-On. Simple Authentication and Security Internet for Web Single Sign-On. Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks to generalize Interface (GSS-API) are application frameworks to generalize
authentication. This memo specifies a SASL mechanism and a GSS-API authentication. This memo specifies a SASL mechanism and a GSS-API
mechanism for SAML 2.0 that allows the integration of existing SAML mechanism for SAML 2.0 that allows the integration of existing SAML
Identity Providers with applications using SASL and GSS-API. Identity Providers with applications using SASL and GSS-API.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 12, 2012. This Internet-Draft will expire on May 3, 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 3, line 19 skipping to change at page 3, line 19
various means for a user to be identified to a relying party (RP) various means for a user to be identified to a relying party (RP)
through the exchange of (typically signed) assertions issued by an through the exchange of (typically signed) assertions issued by an
identity provider (IdP). It includes a number of protocols, protocol identity provider (IdP). It includes a number of protocols, protocol
bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
[OASIS.saml-profiles-2.0-os] designed for different use cases. [OASIS.saml-profiles-2.0-os] designed for different use cases.
Simple Authentication and Security Layer (SASL) [RFC4422] is a Simple Authentication and Security Layer (SASL) [RFC4422] is a
generalized mechanism for identifying and authenticating a user and generalized mechanism for identifying and authenticating a user and
for optionally negotiating a security layer for subsequent protocol for optionally negotiating a security layer for subsequent protocol
interactions. SASL is used by application protocols like IMAP interactions. SASL is used by application protocols like IMAP
[RFC3501], POP [RFC1939] and XMPP [RFC3920]. The effect is to make [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make
modular authentication, so that newer authentication mechanisms can modular authentication, so that newer authentication mechanisms can
be added as needed. This memo specifies just such a mechanism. be added as needed. 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 programming interface. authentication mechanisms through a unified programming interface.
This document defines a pure SASL mechanism for SAML, but it conforms This document defines a pure SASL mechanism for SAML, but it conforms
to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. to the new bridge between SASL and the GSS-API called GS2 [RFC5801].
This means that this document defines both a SASL mechanism and a 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 GSS-API mechanism. We want to point out that the GSS-API interface
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Applicability Because this mechanism transports information that Applicability Because this mechanism transports information that
should not be controlled by an attacker, the SAML mechanism MUST only should not be controlled by an attacker, the SAML mechanism MUST only
be used over channels protected by TLS, and the client MUST be used over channels protected by TLS, and the client MUST
successfully validate the server certificate, or similar integrity successfully validate the server certificate, or similar integrity
protected and authenticated channels. [RFC5280][RFC6125] protected and authenticated channels. [RFC5280][RFC6125]
2. Applicability for non-HTTP Use Cases 2. Applicability for non-HTTP Use Cases
While SAML itself is merely a markup language, its common use case While SAML itself is merely a markup language, its common use case
these days is with HTTP [RFC2616] and HTML these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML
[W3C.REC-html401-19991224]. What follows is a typical flow: [W3C.REC-html401-19991224]. What follows is a typical flow:
1. The browser requests a resource of a Relying Party (RP) (via an 1. The browser requests a resource of a Relying Party (RP) (via an
HTTP request). HTTP request).
2. The RP sends an HTTP redirect as described in Section 10.3 of 2. The RP sends an HTTP redirect as described in Section 10.3 of
[RFC2616] to the browser to the Identity Provider (IdP) or an IdP [RFC2616] to the browser to the Identity Provider (IdP) or an IdP
discovery service with an authentication request that contains discovery service with an authentication request that contains
the name of resource being requested, some sort of a cookie and a the name of resource being requested, some sort of a cookie and a
return URL [RFC1738], return URL [RFC3986],
3. The user authenticates to the IdP and perhaps authorizes the 3. The user authenticates to the IdP and perhaps authorizes the
authentication to the service provider. authentication to the service provider.
4. In its authentication response, the IdP redirects (via an HTTP 4. In its authentication response, the IdP redirects (via an HTTP
redirect) the browser back to the RP with an authentication redirect) the browser back to the RP with an authentication
assertion (stating that the IdP vouches that the subject has assertion (stating that the IdP vouches that the subject has
successfully authenticated), optionally along with some successfully authenticated), optionally along with some
additional attributes. additional attributes.
skipping to change at page 21, line 30 skipping to change at page 21, line 30
[OASIS.saml-profiles-2.0-os] [OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. Standard OASIS.saml-profiles-2.0-os, March 2005.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[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.
[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 [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
skipping to change at page 22, line 26 skipping to change at page 22, line 22
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(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.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 Raggett, D., Jacobs, I., and A. Hors, "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>.
9.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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 6120, March 2011.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Scott Cantor, Joe Hildebrand, Josh The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank
Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their
review and contributions. review and contributions.
Appendix B. Changes Appendix B. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 05 Fixed references per ID-nits
o 04 Added request for IANA assignment, few text clarifications o 04 Added request for IANA assignment, few text clarifications
o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov
o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos
o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott
Cantor Cantor
o 01 Added authorization identity, added GSS-API specifics, added o 01 Added authorization identity, added GSS-API specifics, added
 End of changes. 13 change blocks. 
15 lines changed or deleted 14 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/