draft-ietf-kitten-sasl-saml-ec-13.txt   draft-ietf-kitten-sasl-saml-ec-14.txt 
Network Working Group S. Cantor Network Working Group S. Cantor
Internet-Draft Shibboleth Consortium Internet-Draft Shibboleth Consortium
Intended status: Standards Track S. Josefsson Intended status: Standards Track S. Josefsson
Expires: March 28, 2016 SJD AB Expires: April 12, 2016 SJD AB
September 25, 2015 October 10, 2015
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-13.txt draft-ietf-kitten-sasl-saml-ec-14.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 28, 2016. This Internet-Draft will expire on April 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7
4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 10 4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 10
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11
4.4. User Authentication with Identity Provider . . . . . . . . 11 4.4. User Authentication with Identity Provider . . . . . . . . 11
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 11 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 12
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13
5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13
5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14
5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 15 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 15
5.3.1. Generated by Identity Provider . . . . . . . . . . . . 15 5.3.1. Generated by Identity Provider . . . . . . . . . . . . 15
5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16
5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 17 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 17
5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17
5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 17 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 17
5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18 5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18
skipping to change at page 10, line 5 skipping to change at page 10, line 5
|<-----(5)-----<| | SASL Client Response |<-----(5)-----<| | SASL Client Response
| | | | | |
|>-----(6)----->| | Server sends Outcome |>-----(6)----->| | Server sends Outcome
| | | | | |
----- = SASL ----- = SASL
- - - = SOAP over HTTPS (external to SASL) - - - = SOAP over HTTPS (external to SASL)
Figure 2: Authentication flow Figure 2: Authentication flow
4. SAML SASL Mechanism Specification 4. SAML Enhanced Client SASL Mechanism Specification
Based on the previous figures, the following operations are defined Based on the previous figures, the following operations are defined
by the SAML SASL mechanism: by the SAML SASL mechanism:
4.1. Advertisement 4.1. Advertisement
To advertise that a server supports this mechanism, during To advertise that a server supports this mechanism, during
application session initiation, it displays the name "SAML20EC" application session initiation, it displays the name "SAML20EC"
and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms.
latter indicating support for channel binding).
In accordance with [RFC5801] the "-PLUS" variant indicates that the
server supports channel binding and would be selected by a client
with that capability.
4.2. Initiation 4.2. Initiation
A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If
supported by the application protocol, the client MAY include an supported by the application protocol, the client MAY include an
initial response, otherwise it waits until the server has issued an initial response, otherwise it waits until the server has issued an
empty challenge (because the mechanism is client-first). empty challenge (because the mechanism is client-first).
The format of the initial client response ("initresp") is as follows: The format of the initial client response ("initresp") is as follows:
skipping to change at page 11, line 39 skipping to change at page 11, line 42
as defined in [RFC5246]. as defined in [RFC5246].
4.5. Client Response 4.5. Client Response
Assuming a response is obtained from the IdP, the client responds to Assuming a response is obtained from the IdP, the client responds to
the SASL server with a SOAP envelope constructed in accordance with the SASL server with a SOAP envelope constructed in accordance with
section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP
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,
or must otherwise signal, failure, it responds to the SASL server or must otherwise signal failure, it responds to the SASL server with
with a SOAP envelope containing a SOAP fault. a SOAP envelope containing a SOAP 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. This outcome is transmitted in accordance with the client responses. This outcome is transmitted in accordance with
the application protocol in use. 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 mutual authentication, the SASL server MUST populate the provide for mutual authentication, the SASL server MUST populate the
responseConsumerURL and AssertionConsumerServiceURL attributes with responseConsumerURL and AssertionConsumerServiceURL attributes with
its service name. The service name is used directly rather than its service name. As discussed in Section 5.6.2, most SASL profiles
transformed into an absolute URI if it is not already one, and MUST rely on a service name format of "service@host", but regardless of
be percent-encoded per [RFC3986]. the form, the service name is used directly rather than transformed
into an absolute URI if it is not already one, and MUST be percent-
encoded per [RFC3986].
The value MUST be securely associated with the SAML entityID claimed The IdP MUST securely associate the service name with the SAML
by the SASL server by the identity provider, such as through the use entityID claimed by the SASL server, such as through the use of SAML
of SAML metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL
a SASL service's <SPSSODescriptor> role MUST contain a corresponding service's <SPSSODescriptor> role MUST contain a corresponding
<AssertionConsumerService> whose Location attribute contains the <AssertionConsumerService> whose Location attribute contains the
appropriate service name, as described above. The Binding attribute appropriate service name, as described above. The Binding attribute
MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or
"urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with
older implementations of the ECP profile in existing identity older implementations of the ECP profile in existing identity
provider software). provider software).
Finally, note that the use of HTTP status signaling between the RP Finally, note that the use of HTTP status signaling between the RP
and client mandated by [SAMLECP20] may not be applicable. 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 Enhanced Client SASL 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 [RFC5801] header on the
first message is excluded when SAML EC is used as a GSS-API client's 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
header is prefixed to the client's first authentication message header is prefixed to the client's first authentication message
(context token). (context token).
The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see
IANA considerations). The DER encoding of the OID is TBD. IANA considerations). The DER encoding of the OID is TBD.
The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE,
resulting in the "mutual-auth" option set in the initial client resulting in the "mut" option set in the initial client response.
response. The security context mutual_state flag is set to TRUE only The security context mutual_state flag is set to TRUE only if the
if the server digitally signs its SAML <AuthnRequest> message and the server digitally signs its SAML <AuthnRequest> message and the
signature and signing credential are appropriately verified by the signature and signing credential are appropriately verified by the
identity provider. The identity provider signals this to the client identity provider. The identity provider signals this to the client
in an <ecp:RequestAuthenticated> SOAP header block. in an <ecp:RequestAuthenticated> SOAP header block.
The lifetime of a security context established with this mechanism The lifetime of a security context established with this mechanism
SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if
any, in the <AuthnStatement> element(s) of the SAML assertion(s) any, in the <AuthnStatement> element(s) of the SAML assertion(s)
received by the RP. By convention, in the rare case that multiple received by the RP. By convention, in the rare case that multiple
valid/confirmed assertions containing <AuthnStatement> elements are valid/confirmed assertions containing <AuthnStatement> elements are
received, the most restrictive SessionNotOnOrAfter is generally received, the most restrictive SessionNotOnOrAfter is generally
skipping to change at page 19, line 22 skipping to change at page 19, line 22
case, or in cases in which the SAML name is pseudonymous or transient case, or in cases in which the SAML name is pseudonymous or transient
in nature. The ability to express the SAML name in in nature. The ability to express the SAML name in
GSS_C_NT_USER_NAME form is intended for compatibility with GSS_C_NT_USER_NAME form is intended for compatibility with
applications that cannot make use of additional information. applications that cannot make use of additional information.
5.6.2. Service Naming Considerations 5.6.2. Service Naming Considerations
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
on a host; it is textually represented as "service@host". This name on a host; it is textually represented as "service@host". This name
form is required by most SASL profiles and is used by many existing form is required by most SASL profiles and is used by many existing
applications that use the Kerberos GSS-API mechanism. As noted above applications that use the Kerberos GSS-API mechanism. As described
in the SASL mechanism notes, such a name is used directly by this in in the SASL mechanism's Section 4.7, such a name is used directly
mechanism as the effective AssertionConsumerService "location" by this mechanism as the effective AssertionConsumerService
associated with the service. "location" associated with the service and applied in IdP
verification of the request against the claimed SAML entityID.
This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison
and validation by the client before completing the exchange. The
service name is used directly rather than transformed into an
absolute URI if it is not already one, and MUST be percent-encoded
per [RFC3986]. The value MUST be securely associated with the SAML
entityID claimed by the server by the identity provider, such as
through the use of SAML metadata [OASIS.saml-metadata-2.0-os], as
described previously.
6. Example 6. Example
Suppose the user has an identity at the SAML IdP saml.example.org and Suppose the user has an identity at the SAML IdP saml.example.org and
a Jabber Identifier (jid) "somenode@example.com", and wishes to a Jabber Identifier (jid) "somenode@example.com", and wishes to
authenticate his XMPP connection to xmpp.example.com (and example.com authenticate his XMPP connection to xmpp.example.com (and example.com
and example.org have established a SAML-capable trust relationship). and example.org have established a SAML-capable trust relationship).
The authentication on the wire would then look something like the The authentication on the wire would then look something like the
following: following:
skipping to change at page 38, line 9 skipping to change at page 38, line 9
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, Nico The authors would like to thank Klaas Wierenga, Sam Hartman, Nico
Williams, Jim Basney, and Venkat Yekkirala for their contributions. Williams, Jim Basney, and Venkat Yekkirala for their contributions.
Appendix C. Changes Appendix C. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 14, address some minor comments
o 13, clarify SAML metadata usage, adding a recommended Binding o 13, clarify SAML metadata usage, adding a recommended Binding
value alongside the backward-compatibility usage of PAOS value alongside the backward-compatibility usage of PAOS
o 12, clarifying comments based on WG feedback, with a normative o 12, clarifying comments based on WG feedback, with a normative
change to use enctype numbers instead of names change to use enctype numbers instead of names
o 11, update EAP Naming reference to RFC o 11, update EAP Naming reference to RFC
o 10, update SAML ECP reference to final CS o 10, update SAML ECP reference to final CS
 End of changes. 14 change blocks. 
38 lines changed or deleted 36 lines changed or added

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