draft-ietf-kitten-sasl-saml-ec-08.txt   draft-ietf-kitten-sasl-saml-ec-09.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: November 07, 2013 SJD AB Expires: November 14, 2013 SJD AB
May 06, 2013 May 13, 2013
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-08.txt draft-ietf-kitten-sasl-saml-ec-09.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
SAML-aware "enhanced client" to address significant barriers to SAML-aware "enhanced client" to address significant barriers to
federated authentication in a manner that encourages reuse of federated authentication in a manner that encourages reuse of
existing SAML bindings and profiles designed for non-browser existing SAML bindings and profiles designed for non-browser
scenarios. scenarios.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 07, 2013. This Internet-Draft will expire on November 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . 5 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7
4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 7 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 10
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11
4.4. User Authentication with Identity Provider . . . . . . . 9 4.4. User Authentication with Identity Provider . . . . . . . . 11
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 9 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . 9 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 11
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 10 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13
5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 11 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13
5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14
5.3. Session Key Derivation . . . . . . . . . . . . . . . . . 12 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 15
5.3.1. Generated by Identity Provider . . . . . . . . . . . 13 5.3.1. Generated by Identity Provider . . . . . . . . . . . . 16
5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16
5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . 14 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 17
5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . 15 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17
5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . 15 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 18
5.6.1. User Naming Considerations . . . . . . . . . . . . . 16 5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18
5.6.2. Service Naming Considerations . . . . . . . . . . . . 16 5.6.2. Service Naming Considerations . . . . . . . . . . . . 19
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . 24 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . 25 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 25 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 26 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . 26 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Normative References for GSS-API Implementers . . . . . . 28 9.2. Normative References for GSS-API Implementers . . . . . . 32
9.3. Informative References . . . . . . . . . . . . . . . . . 29 9.3. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 30 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 36
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Security Assertion Markup Language (SAML) 2.0 Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] is a modular specification that provides [OASIS.saml-core-2.0-os] is a modular specification that provides
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.
skipping to change at page 7, line 21 skipping to change at page 9, line 5
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.
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
| | | | | |
|<-----(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 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" and/ application session initiation, it displays the name "SAML20EC"
or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the
latter indicating support for channel binding). latter indicating support for channel binding).
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 ("init-resp") is as The format of the initial client response ("initresp") is as follows:
follows:
hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"
mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \
"WantAuthnRequestsSigned" "WantAuthnRequestsSigned"
del = "y" del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation"
init-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del] initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del]
The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate
whether the client supports channel binding. This takes the place of whether the client supports channel binding. This takes the place of
the PAOS HTTP header extension used in [SAMLECP20] to indicate the PAOS HTTP header extension used in [SAMLECP20] to indicate
channel binding support. channel binding support.
The optional "gs2-authzid" field holds the authorization identity, as The optional "gs2-authzid" field holds the authorization identity, as
requested by the client. requested by the client.
The optional "hok" field is a constant that signals the client's The optional "hok" field is a constant that signals the client's
skipping to change at page 10, line 37 skipping to change at page 13, line 25
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 identity provider signals this to the client in an the identity provider signals this to the client in an <ecp:
<ecp:RequestAuthenticated> SOAP header block. RequestAuthenticated> SOAP header block.
If the mutual_state flag is not requested, or is not set, then the 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 security layer managed by the application outside of the GSS-API
mechanism is responsible for authenticating the acceptor. In this mechanism is responsible for authenticating the acceptor. In this
case, applications MUST match the server identity from the existing case, applications MUST match the server identity from the existing
security layer with the target name. For TLS, this matching MUST be 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 [RFC6125]. For SSH, this matching MUST be
performed as discussed in [RFC4462]. 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
skipping to change at page 11, line 14 skipping to change at page 13, line 50
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 supports credential delegation through the issuance of
SAML assertions that the issuing identity provider will accept as SAML assertions that the issuing identity provider will accept as
proof of authentication by a service on behalf of a subject. An proof of authentication by a service on behalf of a subject. An
initiator may request delegation of its credentials by setting the initiator may request delegation of its credentials by setting the
"del" option field in the initial client response to "y". "del" option field in the initial client response to
"urn:oasis:names:tc:SAML:2.0:conditions:delegation".
An acceptor, upon receipt of this flag, 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. Upon receipt of desired audience for the assertion(s) to be issued. In the event
an assertion satisfying this property, and containing a that the specific identity provider to be used is unknown, the
<SubjectConfirmation> element that the acceptor can satisfy, the constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be
used as a stand-in, per Section 2.3.2 of [SAMLECP20].
Upon receipt of an assertion satisfying this property, and containing
a <SubjectConfirmation> element that the acceptor can satisfy, the
security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set
to TRUE. to TRUE.
The identity provider, if it issues a delegated assertion to the The identity provider, if it issues a delegated assertion to the
acceptor, MUST include in the SOAP response to the initiator a acceptor, MUST include in the SOAP response to the initiator a
<samlec:Delegated> SOAP header block, indicating that delegation was <samlec:Delegated> SOAP header block, indicating that delegation was
enabled. It has no content, other than mandatory SOAP attributes (an enabled. It has no content, other than mandatory SOAP attributes (an
example follows): example follows):
<samlec:Delegated xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:Delegated xmlns:samlec="urn:ietf:params:xml:ns:samlec"
skipping to change at page 13, line 39 skipping to change at page 16, line 28
<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 SHOULD encrypt the assertion; if channel binding is not used, the
assertion MUST be encrypted. If multiple assertions are issued assertion MUST be encrypted. If multiple assertions are issued
(allowed, but not typical), the element need only be included in one (allowed, but not typical), the element need only be included in one
of the assertions issued for use by the relying party. 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 If this mechanism is used by the initiator, then the <samlec:
<samlec:SessionKey> SOAP header block attached to the final client SessionKey> SOAP header block attached to the final client response
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>aes128-cts-hmac-sha1-96</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 key.
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 This specification does not define such a mechanism, but the <samlec:
<samlec:SessionKey> element is extensible to allow for future work in
this space by means of the Algorithm attribute and an optional SessionKey> element is extensible to allow for future work in this
<ds:KeyInfo> child element to carry extensible content related to key space by means of the Algorithm attribute and an optional <ds:
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.
5.4. Per-Message Tokens 5.4. Per-Message Tokens
skipping to change at page 16, line 17 skipping to change at page 18, line 49
The GSS_C_NT_USER_NAME form represents the name of an individual The GSS_C_NT_USER_NAME form represents the name of an individual
user. Clients often rely on this value to determine the appropriate user. Clients often rely on this value to determine the appropriate
credentials to use in authenticating to the identity provider, and credentials to use in authenticating to the identity provider, and
supply it to the server for use by the acceptor. supply it to the server for use by the acceptor.
Upon successful completion of this mechanism, the server MUST Upon successful completion of this mechanism, the server MUST
construct the authenticated initiator name based on the <saml:NameID> construct the authenticated initiator name based on the <saml:NameID>
element in the assertion it successfully validated. The name is element in the assertion it successfully validated. The name is
constructed as a UTF-8 string in the following form: constructed as a UTF-8 string in the following form:
name = element-value "!" Format "!" NameQualifier name = element-value "!" Format "!" NameQualifier
"!" SPNameQualifier "!" SPProvidedID "!" SPNameQualifier "!" SPProvidedID
The "element-value" token refers to the content of the <saml:NameID> The "element-value" token refers to the content of the <saml:NameID>
element. The other tokens refer to the identically named XML element. The other tokens refer to the identically named XML
attributes defined for use with the element. If an attribute is not attributes defined for use with the element. If an attribute is not
present, which is common, it is omitted (i.e., replaced with the present, which is common, it is omitted (i.e., replaced with the
empty string). The Format value is never omitted; if not present, empty string). The Format value is never omitted; if not present,
the SAML-equivalent value of "urn:oasis:names:tc:SAML:1.1:nameid- the SAML-equivalent value of
format:unspecified" is used. "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used.
Not all SAML assertions contain a <saml:NameID> element. In the Not all SAML assertions contain a <saml:NameID> element. In the
event that no such element is present, including the exceptional event that no such element is present, including the exceptional
cases of a <saml:BaseID> element or a <saml:EncryptedID> element that cases of a <saml:BaseID> element or a <saml:EncryptedID> element that
cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used
for the initiator name. for the initiator name.
As noted in the previous section, it is expected that most As noted in the previous section, it is expected that most
applications able to rely on SAML authentication would make use of applications able to rely on SAML authentication would make use of
naming extensions to obtain additional information about the user naming extensions to obtain additional information about the user
skipping to change at page 19, line 21 skipping to change at page 22, line 9
bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250 bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250
ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6 ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6
YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z
YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl
ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6 ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6
Qm9keT4KPC9TOkVudmVsb3BlPg== 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"
messageID="c3a4f8b9c2d" S:mustUnderstand="1" messageID="c3a4f8b9c2d" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
responseConsumerURL="xmpp@xmpp.example.com" responseConsumerURL="xmpp@xmpp.example.com"
service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"/> service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"/>
<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>aes128-cts-hmac-sha1-96</samlec:EncType>
<samlec:EncType>aes256-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>aes256-cts-hmac-sha1-96</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>
<samlp:NameIDPolicy AllowCreate="true" <samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<samlp:RequestedAuthnContext Comparison="exact"> <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef> <saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef> </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext> </samlp:RequestedAuthnContext>
</samlp:AuthnRequest> </samlp:AuthnRequest>
</S:Body> </S:Body>
</S:Envelope>
</S:Envelope>
Step 5 (alt): Server returns error to client: Step 5 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/> <incorrect-encoding/>
</failure> </failure>
</stream:stream> </stream:stream>
Step 6: Client relays the request to IdP in a SOAP message Step 6: Client relays the request to IdP in a SOAP message
transmitted over HTTP (over TLS). HTTP portion not shown, use of transmitted over HTTP (over TLS). HTTP portion not shown, use of
skipping to change at page 21, line 7 skipping to change at page 24, line 5
<!-- same as above --> <!-- same as above -->
</samlp:AuthnRequest> </samlp:AuthnRequest>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
Step 7: IdP responds to client with a SOAP response containing a SAML Step 7: IdP responds to client with a SOAP response containing a SAML
<Response> containing a short-lived SSO assertion (shown as an <Response> containing a short-lived SSO assertion (shown as an
encrypted variant in the example). A generated key is included in encrypted variant in the example). A generated key is included in
the assertion and in a header for the client. the assertion and in a header for the client.
<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>
<ecp:Response S:mustUnderstand="1" <ecp:Response S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"/> AssertionConsumerServiceURL="xmpp@xmpp.example.com"/>
<samlec:GeneratedKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"> <samlec:GeneratedKey xmlns:samlec="urn:ietf:params:xml:ns:samlec">
3w1wSBKUosRLsU69xGK7dg== 3w1wSBKUosRLsU69xGK7dg==
</samlec:GeneratedKey> </samlec:GeneratedKey>
</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"/>
</samlp:Status> </samlp:Status>
<saml:EncryptedAssertion> <saml:EncryptedAssertion>
<!-- contents elided, copy of samlec:GeneratedKey in Advice --> <!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
Step 8: Client sends SOAP envelope containing the SAML <Response> as Step 8: Client sends SOAP envelope containing the SAML <Response> as
a response to the SASL server's challenge: a response to the SASL server's challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT
QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h
bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj
aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K
ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6 ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6
skipping to change at page 22, line 25 skipping to change at page 26, line 5
dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg
ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl
bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj
ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft
bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K
</response> </response>
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: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>aes128-cts-hmac-sha1-96</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"/>
</samlp:Status> </samlp:Status>
<saml:EncryptedAssertion> <saml:EncryptedAssertion>
<!-- contents elided, copy of samlec:GeneratedKey in Advice --> <!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
Step 9: Server informs client of successful authentication: Step 9: Server informs client of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication: Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/> <temporary-auth-failure/>
</failure> </failure>
skipping to change at page 27, line 6 skipping to change at page 31, line 12
Registrant Contact: the IESG Registrant Contact: the IESG
9. References 9. References
9.1. Normative References 9.1. Normative References
[OASIS.saml-bindings-2.0-os] [OASIS.saml-bindings-2.0-os]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard saml- Language (SAML) V2.0", OASIS
bindings-2.0-os, March 2005. Standard saml-bindings-2.0-os, March 2005.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml- Markup Language (SAML) V2.0", OASIS Standard saml-core-
core-2.0-os, March 2005. 2.0-os, March 2005.
[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.
[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.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
S.D., Leach, P.J., 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, [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface "Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure (GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, May 2006. Shell (SSH) Protocol", RFC 4462, May 2006.
skipping to change at page 28, line 5 skipping to change at page 32, line 8
(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
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[SAMLECP20] [SAMLECP20]
Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile
Version 2.0", OASIS Working Draft OASIS.sstc-saml- Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp-
ecp-v2.0-wd07, April 2013. v2.0-wd07, April 2013.
[W3C.soap11] [W3C.soap11]
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
"Simple Object Access Protocol (SOAP) 1.1", W3C Note "Simple Object Access Protocol (SOAP) 1.1", W3C
soap11, May 2000, <http://www.w3.org/TR/SOAP/>. Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>.
9.2. Normative References for GSS-API Implementers 9.2. Normative References for GSS-API Implementers
[I-D.ietf-abfab-gss-eap-naming] [I-D.ietf-abfab-gss-eap-naming]
Hartman, S. and J. Howlett, "Name Attributes for the GSS- Hartman, S. and J. Howlett, "Name Attributes for the GSS-
API EAP mechanism", draft-ietf-abfab-gss-eap-naming-07 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-07
(work in progress), November 2012. (work in progress), November 2012.
[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.
[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, July Interface (GSS-API) Mechanism: Version 2", RFC 4121,
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
Kerberos V Generic Security Service Application Program Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006. Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC5554] Williams, N., "Clarifications and Extensions to the [RFC5554] Williams, N., "Clarifications and Extensions to the
Generic Security Service Application Program Interface Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554, May (GSS-API) for the Use of Channel Bindings", RFC 5554,
2009. May 2009.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
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.
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S. [RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "Generic Security Service Application Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions", RFC Programming Interface (GSS-API) Naming Extensions",
6680, August 2012. RFC 6680, August 2012.
9.3. Informative References 9.3. Informative References
[OASIS.saml-metadata-2.0-os] [OASIS.saml-metadata-2.0-os]
Cantor, S., Moreh, J., Philpott, R., and E. Maler, Cantor, S., Moreh, J., Philpott, R., and E. Maler,
"Metadata for the Security Assertion Markup Language "Metadata for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March (SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
2005. March 2005.
[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.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006. Windows", RFC 4559, June 2006.
[W3C.REC-xmlschema-1] [W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
2001, <http://www.w3.org/TR/xmlschema-1/>. May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[WSS-SAML] [WSS-SAML]
Monzillo, R., "Web Services Security SAML Token Profile Monzillo, R., "Web Services Security SAML Token Profile
Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile,
May 2012. May 2012.
Appendix A. XML Schema Appendix A. XML Schema
The following schema formally defines the The following schema formally defines the
"urn:ietf:params:xml:ns:samlec" namespace used in this document, in "urn:ietf:params:xml:ns:samlec" namespace used in this document, in
skipping to change at page 31, 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 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
o 06, simplified session key schema, moved responsibility for o 06, simplified session key schema, moved responsibility for
random-to-key to the endpoints, and defined advertisement of random-to-key to the endpoints, and defined advertisement of
session key algorithm and enctypes by acceptor session key algorithm and enctypes by acceptor
o 05, revised session key material, added requirement for random-to- o 05, revised session key material, added requirement for random-to-
key, revised XML schema to capture enctype name, updated GSS key, revised XML schema to capture enctype name, updated GSS
 End of changes. 35 change blocks. 
204 lines changed or deleted 212 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/