draft-ietf-kitten-sasl-saml-ec-11.txt   draft-ietf-kitten-sasl-saml-ec-12.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: July 17, 2014 SJD AB Expires: July 2, 2015 SJD AB
January 13, 2014 December 29, 2014
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-11.txt draft-ietf-kitten-sasl-saml-ec-12.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 July 17, 2014. This Internet-Draft will expire on July 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . 16 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 . . . . . . . . . 18 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
5.6.2. Service Naming Considerations . . . . . . . . . . . . 19 5.6.2. Service Naming Considerations . . . . . . . . . . . . 19
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30
skipping to change at page 4, line 44 skipping to change at page 4, line 44
The mechanisms specified in this document allow a SASL- or GSS-API- The mechanisms specified in this document allow a SASL- or GSS-API-
enabled server to act as a SAML relying party, or service provider enabled server to act as a SAML relying party, or service provider
(SP), by advertising this mechanism as an option for SASL or GSS-API (SP), by advertising this mechanism as an option for SASL or GSS-API
clients that support the use of SAML to communicate identity and clients that support the use of SAML to communicate identity and
attribute information. Clients supporting this mechanism are termed attribute information. Clients supporting this mechanism are termed
"enhanced clients" in SAML terminology because they understand the "enhanced clients" in SAML terminology because they understand the
federated authentication model and have specific knowledge of the federated authentication model and have specific knowledge of the
IdP(s) associated with the user. This knowledge, and the ability to IdP(s) associated with the user. This knowledge, and the ability to
act on it, addresses a significant problem with browser-based SAML act on it, addresses a significant problem with browser-based SAML
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. In a "dumb" client such as a web browser, various intrusive
to determine the right IdP (and its network location) is both a user user interface techniques are used to determine the appropriate IdP
interface and security improvement. to use because the request to the IdP is generated as an HTTP
redirect by the RP, which does not generally have prior knowledge of
the IdP to use. Obviating the need for the RP to interact with the
client to determine the right IdP (and its network location) is both
a user 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].
authentication, integrity and confidentiality mechanism. It is
anticipated that existing security layers, such as Transport Layer
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 8, line 12 skipping to change at page 8, line 12
an additional, though limited, defense against MITM attacks). an additional, though limited, defense against MITM attacks).
This completes the SAML exchange. This completes the SAML exchange.
6. The RP now has sufficient identity information to approve the 6. The RP now has sufficient identity information to approve the
original HTTP request or not, and acts accordingly. Everything original HTTP request or not, and acts accordingly. Everything
between the original request and this response can be thought of between the original request and this response can be thought of
as an "interruption" of the original HTTP exchange. as an "interruption" of the original HTTP exchange.
When considering this flow in the context of an arbitrary application When considering this flow in the context of an arbitrary application
protocol and SASL, the RP and the client both must change their code protocol and SASL, the RP and the client both must change their code
to implement this SASL mechanism, but the IdP can remain untouched. to implement this SASL mechanism, but the IdP can remain unmodified.
The existing RP/client exchange that is tunneled through HTTP maps The existing RP/client exchange that is tunneled through HTTP maps
well to the tunneling of that same exchange in SASL. In the parlance well to the tunneling of that same exchange in SASL. In the parlance
of SASL [RFC4422], this mechanism is "client-first" for consistency of SASL [RFC4422], this mechanism is "client-first" for consistency
with GS2. The steps are shown below: with GS2. The steps are shown below:
1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS
mechanisms. mechanisms.
2. The client initiates a SASL authentication with SAML20EC or 2. The client initiates a SASL authentication with SAML20EC or
SAML20EC-PLUS. SAML20EC-PLUS.
skipping to change at page 8, line 50 skipping to change at page 8, line 50
such that the client MUST interact with the IdP in order to complete such that the client MUST interact with the IdP in order to complete
any SASL exchange with the RP. The assertions issued by the IdP for any SASL exchange with the RP. The assertions issued by the IdP for
the purposes of the profile, and by extension this SASL mechanism, the purposes of the profile, and by extension this SASL mechanism,
are short lived, and therefore cannot be cached by the client for are short lived, and therefore cannot be cached by the client for
later use. later use.
Encompassed in step four is the client-driven selection of the IdP, Encompassed in step four is the client-driven selection of the IdP,
authentication to it, and the acquisition of a response to provide to authentication to it, and the acquisition of a response to provide to
the SASL server. These processes are all external to SASL. the SASL server. These processes are all external to SASL.
Note also that unlike an HTTP-based profile, the IdP cannot
participate in the selection of, or evaluation of, the location to
which the SASL Client Response will be delivered by the client. The
use of GSS-API Channel Binding is an important mitigation of the risk
of a "Man in the Middle" attack between the client and RP, as is the
use of a negotiated or derived session key in whatever protocol is
secured by this mechanism.
With all of this in mind, the typical flow appears as follows: With all of this in mind, the typical flow appears as follows:
SASL Serv. Client IdP SASL Serv. Client IdP
|>-----(1)----->| | Advertisement |>-----(1)----->| | Advertisement
| | | | | |
|<-----(2)-----<| | Initiation |<-----(2)-----<| | Initiation
| | | | | |
|>-----(3)----->| | SASL Server Response |>-----(3)----->| | SASL Server Response
| | | | | |
| |<- - -(4)- - >| SOAP AuthnRequest + user authn | |<- - -(4)- - >| SOAP AuthnRequest + user authn
skipping to change at page 12, line 11 skipping to change at page 12, line 11
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 parties then perform the steps described in its service name. The service name is used directly rather than
[SAMLECP20] as usual. 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 SASL server by the
identity provider, such as through the use of SAML metadata
[OASIS.saml-metadata-2.0-os].
Similarly, the use of HTTP status signaling between the RP and client Finally, note that the use of HTTP status signaling between the RP
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 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
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 "mutual-auth" option set in the initial client
response. The security context mutual_state flag is set to TRUE only response. The security context mutual_state flag is set to TRUE only
if the server digitally signs its SAML <AuthnRequest> message, and if the server digitally signs its SAML <AuthnRequest> message and the
the identity provider signals this to the client in an <ecp: signature and signing credential are appropriately verified by the
RequestAuthenticated> SOAP header block. identity provider. The identity provider signals this to the client
in an <ecp:RequestAuthenticated> SOAP header block.
If the mutual_state flag is not requested, or is not set, then the
security layer managed by the application outside of the GSS-API
mechanism is responsible for authenticating the acceptor. In this
case, applications MUST match the server identity from the existing
security layer with the target name. For TLS, this matching MUST be
performed as discussed in [RFC6125]. For SSH, this matching MUST be
performed as discussed in [RFC4462].
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
applied. applied.
5.1. GSS-API Credential Delegation 5.1. GSS-API Credential Delegation
This mechanism supports credential delegation through the issuance of This mechanism can support credential delegation through the issuance
SAML assertions that the issuing identity provider will accept as of SAML assertions that an identity provider will accept as proof of
proof of authentication by a service on behalf of a subject. An authentication by a service on behalf of a subject. An initiator may
initiator may request delegation of its credentials by setting the request delegation of its credentials by setting the "del" option
"del" option field in the initial client response to field in the initial client response to
"urn:oasis:names:tc:SAML:2.0:conditions:delegation". "urn:oasis:names:tc:SAML:2.0:conditions:delegation".
An acceptor, upon receipt of this constant, requests a delegated An acceptor, upon receipt of this constant, requests a delegated
assertion by including in its <AuthnRequest> message a <Conditions> assertion by including in its <AuthnRequest> message a <Conditions>
element containing an <AudienceRestriction> identifying the IdP as a element containing an <AudienceRestriction> identifying the IdP as a
desired audience for the assertion(s) to be issued. In the event desired audience for the assertion(s) to be issued. In the event
that the specific identity provider to be used is unknown, the that the specific identity provider to be used is unknown, the
constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be
used as a stand-in, per Section 2.3.2 of [SAMLECP20]. used as a stand-in, per Section 2.3.2 of [SAMLECP20].
skipping to change at page 15, line 36 skipping to change at page 15, line 31
Algorithm XML attribute identifies a mechanism for key derivation. Algorithm XML attribute identifies a mechanism for key derivation.
It is omitted to identify the use of an Identity Provider-generated It is omitted to identify the use of an Identity Provider-generated
key (see following section) or will contain a URI value identifying a key (see following section) or will contain a URI value identifying a
derivation mechanism defined outside this specification. Each header derivation mechanism defined outside this specification. Each header
block's mustUnderstand and actor attributes MUST be set to "1" and block's mustUnderstand and actor attributes MUST be set to "1" and
"http://schemas.xmlsoap.org/soap/actor/next" respectively. "http://schemas.xmlsoap.org/soap/actor/next" respectively.
In the acceptor's first response message containing its SAML request, In the acceptor's first response message containing its SAML request,
one or more <samlec:SessionKey> SOAP header blocks MUST be included. one or more <samlec:SessionKey> SOAP header blocks MUST be included.
The element MUST contain one or more <EncType> elements containing The element MUST contain one or more <EncType> elements containing
the name of a supported encryption type defined in accordance with the number of a supported encryption type defined in accordance with
[RFC3961]. Encryption types should be provided in order of [RFC3961]. Encryption types should be provided in order of
preference by the acceptor. preference by the acceptor.
In the final client response message, a single <samlec:SessionKey> In the final client response message, a single <samlec:SessionKey>
SOAP header block MUST be included. A single <EncType> element MUST SOAP header block MUST be included. A single <EncType> element MUST
be included to identify the chosen encryption type used by the be included to identify the chosen encryption type used by the
initiator. initiator.
All parties MUST support the "aes128-cts-hmac-sha1-96" encryption All parties MUST support the "aes128-cts-hmac-sha1-96" encryption
type, defined by [RFC3962]. type, number 17, defined by [RFC3962].
Further details depend on the mechanism used, one of which is Further details depend on the mechanism used, one of which is
described in the following section. described in the following section.
5.3.1. Generated by Identity Provider 5.3.1. Generated by Identity Provider
The identity provider, if issuing a bearer assertion for use with The identity provider, if issuing a bearer assertion for use with
this mechanism, SHOULD provide a generated key for use by the this mechanism, SHOULD provide a generated key for use by the
initiator and acceptor. This key is used as pseudorandom input to initiator and acceptor. This key is used as pseudorandom input to
the "random-to-key" function for a specific encryption type defined the "random-to-key" function for a specific encryption type defined
in accordance with [RFC3961]. The key is base64-encoded and placed in accordance with [RFC3961]. The key is base64-encoded and placed
inside a <samlec:GeneratedKey> element. The identity provider does inside a <samlec:GeneratedKey> element. The identity provider does
not participate in the selection of the encryption type and simply not participate in the selection of the encryption type and simply
generates enough pseudorandom bits to supply key material to the generates enough pseudorandom bits to supply key material to the
other parties. other parties.
The resulting <samlec:GeneratedKey> element is placed within the The resulting <samlec:GeneratedKey> element is placed within the
<saml:Advice> element of the assertion issued. The identity provider <saml:Advice> element of the assertion issued. The identity provider
SHOULD encrypt the assertion; if channel binding is not used, the MUST encrypt the assertion (implying that it MUST have the means to
assertion MUST be encrypted. If multiple assertions are issued do so, typically knowledge of a key associated with the RP). If
(allowed, but not typical), the element need only be included in one multiple assertions are issued (allowed, but not typical), the
of the assertions issued for use by the relying party. element need only be included in one of the assertions issued for use
by the relying party.
A copy of the element is also added as a SOAP header block in the A copy of the element is also added as a SOAP header block in the
response from the identity provider to the client (and then removed response from the identity provider to the client (and then removed
when constructing the response to the acceptor). when constructing the response to the acceptor).
If this mechanism is used by the initiator, then the <samlec: If this mechanism is used by the initiator, then the <samlec:
SessionKey> SOAP header block attached to the final client response SessionKey> SOAP header block attached to the final client response
message will identify this via the omission of the Algorithm message will identify this via the omission of the Algorithm
attribute and will identify the chosen encryption type using the attribute and will identify the chosen encryption type using the
<samlec:EncType> element: <samlec:EncType> element:
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
Both the initiator and acceptor MUST execute the chosen encryption Both the initiator and acceptor MUST execute the chosen encryption
type's random-to-key function over the pseudorandom value provided by type's random-to-key function over the pseudorandom value provided by
the <samlec:GeneratedKey> element. The result of that function is the <samlec:GeneratedKey> element. The result of that function is
used as the protocol key. used as the protocol and session key. Support for subkeys from the
initiator or acceptor is not specified.
5.3.2. Alternate Key Derivation Mechanisms 5.3.2. Alternate Key Derivation Mechanisms
In the event that a client is proving possession of a secret or In the event that a client is proving possession of a secret or
private key, a formal key agreement algorithm might be supported. private key, a formal key agreement algorithm might be supported.
This specification does not define such a mechanism, but the <samlec: This specification does not define such a mechanism, but the <samlec:
SessionKey> element is extensible to allow for future work in this SessionKey> element is extensible to allow for future work in this
space by means of the Algorithm attribute and an optional <ds: space by means of the Algorithm attribute and an optional <ds:
KeyInfo> child element to carry extensible content related to key KeyInfo> child element to carry extensible content related to key
establishment. establishment.
However a key is derived, the <samlec:EncType> element will identify However a key is derived, the <samlec:EncType> element will identify
the chosen encrytion type, and both the initiator and acceptor MUST the chosen encrytion type, and both the initiator and acceptor MUST
execute the encryption type's random-to-key function over the result execute the encryption type's random-to-key function over the result
of the key agreement or derivation process. The result of that of the key agreement or derivation process. The result of that
function is used as the protocol key. function is used as the protocol key.
skipping to change at page 19, line 31 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. Such a name is applications that use the Kerberos GSS-API mechanism. As noted above
used directly by this mechanism as the effective in the SASL mechanism notes, such a name is used directly by this
AssertionConsumerService "location" associated with the service. mechanism as the effective AssertionConsumerService "location"
associated with the service.
This value is used in the construction of the responseConsumerURL and This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison AssertionConsumerServiceURL attributes, and for eventual comparison
and validation by the client before completing the exchange. The and validation by the client before completing the exchange. The
value MUST be securely associated with the SAML entityID claimed by service name is used directly rather than transformed into an
the server by the identity provider, such as through the use of SAML absolute URI if it is not already one, and MUST be percent-encoded
metadata [OASIS.saml-metadata-2.0-os]. 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].
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 21, line 32 skipping to change at page 21, line 32
UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M
OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No
ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu
ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t
Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv
c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz
aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s
ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv
YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT
OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l
eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMTI4LWN0cy1obWFjLXNoYTEt eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+MTc8L3NhbWxlYzpFbmNUeXBlPgog
OTY8L3NhbWxlYzpFbmNUeXBlPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMjU2 ICAgICA8c2FtbGVjOkVuY1R5cGU+MTg8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNh
LWN0cy1obWFjLXNoYTEtOTY8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNhbWxlYzpT bWxlYzpTZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxz
ZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxzYW1scDpB YW1scDpBdXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9u
dXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9uPSIyLjAi PSIyLjAiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAg
IElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAgIFByb3Rv IFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJp
Y29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdz bmRpbmdzOlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0i
OlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4 eG1wcEB4bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5z
bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9 OnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgog
InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAg ICAgICAgaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1
aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAg ZXI+CiAgICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUi
ICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAg CiAgICAgICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFt
ICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZv ZWlkLWZvcm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB
cm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNv dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0
bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250 aG5Db250ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FN
ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6 TDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAg
YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z ICAgPC9zYW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJl
YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl cXVlc3RlZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4K
ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6 ICA8L1M6Qm9keT4KPC9TOkVudmVsb3BlPgo=
Qm9keT4KPC9TOkVudmVsb3BlPg==
</challenge> </challenge>
The Base64 [RFC4648] decoded envelope: The Base64 [RFC4648] decoded envelope:
<S:Envelope <S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header> <S:Header>
<paos:Request xmlns:paos="urn:liberty:paos:2003-08" <paos:Request xmlns:paos="urn:liberty:paos:2003-08"
skipping to change at page 22, line 29 skipping to change at page 22, line 28
<ecp:Request <ecp:Request
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
S:mustUnderstand="1" ProviderName="Jabber at example.com"> S:mustUnderstand="1" ProviderName="Jabber at example.com">
<saml:Issuer>https://xmpp.example.com</saml:Issuer> <saml:Issuer>https://xmpp.example.com</saml:Issuer>
</ecp:Request> </ecp:Request>
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:EncType>aes256-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>18</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:AuthnRequest <samlp:AuthnRequest
ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z" ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"> AssertionConsumerServiceURL="xmpp@xmpp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com https://xmpp.example.com
</saml:Issuer> </saml:Issuer>
skipping to change at page 26, line 17 skipping to change at page 26, line 17
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header> <S:Header>
<paos:Response xmlns:paos="urn:liberty:paos:2003-08" <paos:Response xmlns:paos="urn:liberty:paos:2003-08"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/> S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/>
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:Response ID="d43h94r389309r" Version="2.0" <samlp:Response ID="d43h94r389309r" Version="2.0"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d" IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
Destination="xmpp@xmpp.example.com"> Destination="xmpp@xmpp.example.com">
<saml:Issuer>https://saml.example.org</saml:Issuer> <saml:Issuer>https://saml.example.org</saml:Issuer>
<samlp:Status> <samlp:Status>
<samlp:StatusCode <samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
skipping to change at page 32, line 28 skipping to change at page 32, line 28
[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.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005. Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006. Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
skipping to change at page 35, line 30 skipping to change at page 35, line 30
<complexType name="SessionKeyType"> <complexType name="SessionKeyType">
<sequence> <sequence>
<element ref="samlec:EncType" maxOccurs="unbounded"/> <element ref="samlec:EncType" maxOccurs="unbounded"/>
<element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:KeyInfo" minOccurs="0"/>
</sequence> </sequence>
<attribute ref="S:mustUnderstand" use="required"/> <attribute ref="S:mustUnderstand" use="required"/>
<attribute ref="S:actor" use="required"/> <attribute ref="S:actor" use="required"/>
<attribute name="Algorithm"/> <attribute name="Algorithm"/>
</complexType> </complexType>
<element name="EncType" type="string"/> <element name="EncType" type="integer"/>
<element name="GeneratedKey" type="samlec:GeneratedKeyType"/> <element name="GeneratedKey" type="samlec:GeneratedKeyType"/>
<complexType name="GeneratedKeyType"> <complexType name="GeneratedKeyType">
<simpleContent> <simpleContent>
<extension base="base64Binary"> <extension base="base64Binary">
<attribute ref="S:mustUnderstand"/> <attribute ref="S:mustUnderstand"/>
<attribute ref="S:actor"/> <attribute ref="S:actor"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
skipping to change at page 37, line 9 skipping to change at page 37, 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 12, clarifying comments based on WG feedback, with a normative
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
o 09, align delegation signaling to updated ECP draft o 09, align delegation signaling to updated ECP draft
o 08, more corrections, added a delegation signaling header o 08, more corrections, added a delegation signaling header
o 07, corrections, revised section on delegation o 07, corrections, revised section on delegation
 End of changes. 27 change blocks. 
73 lines changed or deleted 89 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/