draft-ietf-kitten-sasl-saml-ec-00.txt   draft-ietf-kitten-sasl-saml-ec-01.txt 
Network Working Group S. Cantor Network Working Group S. Cantor
Internet-Draft Internet2 Internet-Draft Shibboleth Consortium
Intended status: Standards Track S. Josefsson Intended status: Standards Track S. Josefsson
Expires: March 2, 2012 SJD AB Expires: August 31, 2012 SJD AB
August 30, 2011 February 28, 2012
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-00.txt draft-ietf-kitten-sasl-saml-ec-01.txt
Abstract Abstract
Security Assertion Markup Language (SAML) 2.0 is a generalized Security Assertion Markup Language (SAML) 2.0 is a generalized
framework for the exchange of security-related information between framework for the exchange of security-related information between
asserting and relying parties. Simple Authentication and Security asserting and relying parties. 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 facilitate an Interface (GSS-API) are application frameworks to facilitate an
extensible authentication model. This document specifies a SASL and extensible authentication model. This document specifies a SASL and
GSS-API mechanism for SAML 2.0 that leverages the capabilities of a GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
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 2, 2012. This Internet-Draft will expire on August 31, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
profiles known as the "discovery", or "where are you from?" (WAYF) profiles known as the "discovery", or "where are you from?" (WAYF)
problem. Obviating the need for the RP to interact with the client problem. Obviating the need for the RP to interact with the client
to determine the right IdP (and its network location) is both a user to determine the right IdP (and its network location) is both a user
interface and security improvement. interface and security improvement.
The SAML mechanism described in this document is an adaptation of an The SAML mechanism described in this document is an adaptation of an
existing SAML profile, the Enhanced Client or Proxy (ECP) Profile existing SAML profile, the Enhanced Client or Proxy (ECP) Profile
(V2.0) [SAMLECP20], and therefore does not establish a separate (V2.0) [SAMLECP20], and therefore does not establish a separate
authentication, integrity and confidentiality mechanism. It is authentication, integrity and confidentiality mechanism. It is
anticipated that existing security layers, such as Transport Layer anticipated that existing security layers, such as Transport Layer
Security (TLS), will continued to be used. Security (TLS) or Secure Shell (SSH), will continued to be used.
Figure 1 describes the interworking between SAML and SASL: this Figure 1 describes the interworking between SAML and SASL: this
document requires enhancements to the RP and to the client (as the document requires enhancements to the RP and to the client (as the
two SASL communication endpoints) but no changes to the SAML IdP are two SASL communication endpoints) but no changes to the SAML IdP are
assumed apart from its support for the applicable SAML profile. To assumed apart from its support for the applicable SAML profile. To
accomplish this, a SAML protocol exchange between the RP and the IdP, accomplish this, a SAML protocol exchange between the RP and the IdP,
brokered by the client, is tunneled within SASL. There is no assumed brokered by the client, is tunneled within SASL. There is no assumed
communication between the RP and the IdP, but such communication may communication between the RP and the IdP, but such communication may
occur in conjunction with additional SAML-related profiles not in occur in conjunction with additional SAML-related profiles not in
scope for this document. scope for this document.
skipping to change at page 10, line 33 skipping to change at page 10, line 33
header requirements of the SAML PAOS Binding header requirements of the SAML PAOS Binding
[OASIS.saml-bindings-2.0-os], for compatibility with the existing [OASIS.saml-bindings-2.0-os], for compatibility with the existing
profile. If the client is unable to obtain a response from the IdP, profile. If the client is unable to obtain a response from the IdP,
it responds to the SASL server with a SOAP envelope containing a SOAP it responds to the SASL server with a SOAP envelope containing a SOAP
fault. fault.
4.6. Outcome 4.6. Outcome
The SAML protocol exchange having completed, the SASL server will The SAML protocol exchange having completed, the SASL server will
transmit the outcome to the client depending on local validation of transmit the outcome to the client depending on local validation of
the client responses. the client responses. This outcome is transmitted in accordance with
the application protocol in use.
4.7. Additional Notes 4.7. Additional Notes
Because this mechanism is an adaptation of an HTTP-based profile, Because this mechanism is an adaptation of an HTTP-based profile,
there are a few requirements outlined in [SAMLECP20] that make there are a few requirements outlined in [SAMLECP20] that make
reference to a response URL that is normally used to regulate where reference to a response URL that is normally used to regulate where
the client returns information to the RP. There are also security- the client returns information to the RP. There are also security-
related checks built into the profile that involve this location. related checks built into the profile that involve this location.
For compatibility with existing IdP and profile behavior, and to For compatibility with existing IdP and profile behavior, and to
provide for secure identification of the RP to the client, the SASL provide for secure identification of the RP to the client, the SASL
server MUST populate the responseConsumerURL and server MUST populate the responseConsumerURL and
AssertionConsumerServiceURL attributes with its service name, AssertionConsumerServiceURL attributes with its service name,
expressed as an absolute URI. The parties then perform the steps expressed as an absolute URI. The parties then perform the steps
described in [SAMLECP20] as usual. described in [SAMLECP20] as usual.
Similarly, the use of HTTP status signaling between the RP and client
mandated by [SAMLECP20] may not be applicable.
5. SAML EC GSS-API Mechanism Specification 5. SAML EC GSS-API Mechanism Specification
This section and its sub-sections and all normative references of it This section and its sub-sections and all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism.
The messages are the same, but a) the GS2 header on the client's The messages are the same, but a) the GS2 header on the client's
first message is excluded when SAML EC is used as a GSS-API first message is excluded when SAML EC is used as a GSS-API
mechanism, and b) the RFC2743 section 3.1 initial context token mechanism, and b) the RFC2743 section 3.1 initial context token
skipping to change at page 11, line 26 skipping to change at page 11, line 26
(context token). (context token).
The GSS-API mechanism OID for SAML EC is 1.3.6.1.4.1.11591.4.6. The GSS-API mechanism OID for SAML EC is 1.3.6.1.4.1.11591.4.6.
SAML EC security contexts always have the mutual_state flag SAML EC security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. SAML EC does not support credential (GSS_C_MUTUAL_FLAG) set to TRUE. SAML EC does not support credential
delegation, therefore SAML EC security contexts alway have the delegation, therefore SAML EC 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 server identity from the existing security
target name. Since the TLS channel is managed by the application layer (TLS, SSH, etc.) with the negotiated target name. Since the
outside of the GSS-API mechanism, the mechanism itself is unable to existing security layer is managed by the application outside of the
confirm the name while the application is able to perform this GSS-API mechanism, the mechanism itself is unable to confirm the
comparison for the mechanism. For this reason, applications MUST name. For this reason, applications MUST match the server identity
match the TLS server identity with the target name, as discussed in from the existing security layer with the target name. For TLS, this
[RFC6125]. matching MUST be perfored as discussed in [RFC6125]. For SSH, this
matching MUST be performed as discussed in [RFC4462]. Applications
may rely on the GSS-API mechanism to perform this matching by passing
the server identity as the targ_name parameter to
GSS_Init_sec_context().
The SAML EC mechanism does not support per-message tokens or The SAML EC mechanism does not support per-message tokens or
GSS_Pseudo_random. GSS_Pseudo_random.
The lifetime of a security context established with this mechanism
SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if
any, in the <AuthnStatement> of the SAML assertion received by the
RP.
5.1. GSS-API Principal Name Types for SAML EC 5.1. GSS-API Principal Name Types for SAML EC
SAML EC supports standard generic name syntaxes for acceptors such as SAML EC supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). These GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). These
service names MUST be associated with the SAML "entityID" claimed by service names MUST be associated with the SAML "entityID" claimed by
the RP, such as through the use of SAML metadata the RP, such as through the use of SAML metadata
[OASIS.saml-metadata-2.0-os]. [OASIS.saml-metadata-2.0-os].
SAML EC supports only a single name type for initiators: SAML EC supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
skipping to change at page 23, line 38 skipping to change at page 23, line 38
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[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.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, May 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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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
skipping to change at page 26, line 9 skipping to change at page 26, line 9
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, and Nico The authors would like to thank Klaas Wierenga, Sam Hartman, and Nico
Williams for their contributions. Williams for their contributions.
Appendix B. Changes Appendix B. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o draft-ietf-kitten-sasl-saml-ec-00, Initial Revision, first WG- o 01, SSH language added, noted non-assumption of HTTP error
adopted draft. Removed support for unsolicited SAML responses. handling, added guidance on life of security context.
o 00, Initial Revision, first WG-adopted draft. Removed support for
unsolicited SAML responses.
Authors' Addresses Authors' Addresses
Scott Cantor Scott Cantor
Internet2 Shibboleth Consortium
2740 Airport Drive 2740 Airport Drive
Columbus, Ohio 43219 Columbus, Ohio 43219
United States United States
Phone: +1 614 247 6147 Phone: +1 614 247 6147
Email: cantor.2@osu.edu Email: cantor.2@osu.edu
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Hagagatan 24
 End of changes. 13 change blocks. 
18 lines changed or deleted 39 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/