draft-ietf-kitten-sasl-saml-ec-05.txt   draft-ietf-kitten-sasl-saml-ec-06.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: June 6, 2013 SJD AB Expires: August 2, 2013 SJD AB
December 3, 2012 January 29, 2013
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-05.txt draft-ietf-kitten-sasl-saml-ec-06.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 June 6, 2013. This Internet-Draft will expire on August 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
4.4. User Authentication with Identity Provider . . . . . . . . 10 4.4. User Authentication with Identity Provider . . . . . . . . 10
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12
5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12
5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13 5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13
5.2.1. Generated by Identity Provider . . . . . . . . . . . . 13 5.2.1. Generated by Identity Provider . . . . . . . . . . . . 14
5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14 5.2.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14
5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15
5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15
5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15
5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16 5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16
5.5.2. Service Naming Considerations . . . . . . . . . . . . 17 5.5.2. Service Naming Considerations . . . . . . . . . . . . 17
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Normative References for GSS-API Implementers . . . . . . 30 9.2. Normative References for GSS-API Implementers . . . . . . 30
9.3. Informative References . . . . . . . . . . . . . . . . . . 31 9.3. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Appendix A. XML Schema . . . . . . . . . . . . . . . 32 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 33
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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 13, line 23 skipping to change at page 13, line 23
described by [SAMLECP20]. described by [SAMLECP20].
5.2. Session Key Derivation 5.2. Session Key Derivation
Some GSS-API features (discussed in the following sections) require a Some GSS-API features (discussed in the following sections) require a
session key be established as a result of security context session key be established as a result of security context
establishment. In the common case of a "bearer" assertion in SAML, a establishment. In the common case of a "bearer" assertion in SAML, a
mechanism is defined to communicate a key to both parties via the mechanism is defined to communicate a key to both parties via the
identity provider. In other cases such as assertions based on identity provider. In other cases such as assertions based on
"holder of key" confirmation bound to a client-controlled key, there "holder of key" confirmation bound to a client-controlled key, there
may be additional methods supported. may be additional methods defined in the future, and extension points
are provided for this purpose.
Information defining or describing the session key, or a process for Information defining or describing the session key, or a process for
deriving one, is communicated using a <samlec:SessionKey> element, deriving one, is communicated between the initiator and acceptor
defined by the XML schema in Appendix A. This element can be used as using a <samlec:SessionKey> element, defined by the XML schema in
a SOAP header block or as an extension within a SAML assertion, Appendix A. This element is a SOAP header block. The content of the
depending on the context of communication. The content of the element further depends on the specific use in the mechanism. The
element further depends on the specific use in the mechanism and is Algorithm XML attribute identifies a mechanism for key derivation.
discussed below. It is omitted to identify the use of an Identity Provider-generated
key (see following section) or will contain a URI value identifying a
derivation mechanism defined outside this specification. Each header
block's mustUnderstand and actor attributes MUST be set to "1" and
"http://schemas.xmlsoap.org/soap/actor/next" respectively.
In the acceptor's first response message containing its SAML request,
one or more <samlec:SessionKey> SOAP header blocks MUST be included.
The element MUST contain one or more <EncType> elements containing
the name of a supported encryption type defined in accordance with
[RFC3961].
In the final client response message, a single <samlec:SessionKey>
SOAP header block MUST be included. A single <EncType> element MUST
be included to identify the chosen encryption type used by the
initiator.
All parties MUST support the "aes128-cts-hmac-sha1-96" encryption
type, defined by [RFC3962].
Further details depend on the mechanism used, one of which is
described in the following section.
5.2.1. Generated by Identity Provider 5.2.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 the protocol key for a initiator and acceptor. This key is used as the protocol key for a
specific encryption type defined in accordance with [RFC3961]. The specific encryption type defined in accordance with [RFC3961]. The
key is base64-encoded and placed inside a <samlec:GeneratedKey> key is base64-encoded and placed inside a <samlec:GeneratedKey>
element. element. The identity provider does not participate in the selection
of the encryption type and simply generates enough pseudorandom bits
to supply key material to the other parties.
Regardless of the encryption type chosen, the identity provider MUST The resulting <samlec:GeneratedKey> element is placed within the
produce a key by generating sufficient pseudorandom bits and <saml:Advice> element of the assertion issued. A copy of the element
executing the chosen encryption type's random-to-key function over is also added as a SOAP header block in the response from the
the input. The result of that function is the key to be encoded and identity provider to the client.
placed inside the element.
The resulting <samlec:GeneratedKey> element is placed within a If this mechanism is used by the initiator, then the <samlec:
<samlec:SessionKey> element whose EncType XML attribute is set to the SessionKey> SOAP header block attached to the final client response
appropriate encryption type name used. The <samlec:SessionKey> message will identify this via the omission of the Algorithm
element is placed within the <saml:Advice> element of the assertion attribute and will identify the chosen encryption type using the
issued. A copy of the element is also added as a SOAP header block <samlec:EncType> element:
in the response from the identity provider to the client.
The identity provider is left to determine which encryption type the <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
parties should use. It is unspecified how the initiator's xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
capabilities are determined in this respect, but the acceptor MAY S:mustUnderstand="1"
indicate the encryption types it supports in its SAML metadata by S:actor="http://schemas.xmlsoap.org/soap/actor/next">
means of a <samlec:SessionKeyMethod> element in a <samlmd:Extensions> <samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType>
element, and an identity provider may leverage this information. The <samlec:SessionKey>
omission of the element's Algorithm XML attribute represents support
for the key generation mechanism described in this section. Zero or
more <samlec:EncType> elements may appear, each contaning an
encryption type name supported.
All parties MUST support the "aes128-cts-hmac-sha1-96" encryption Both the initiator and acceptor MUST execute the chosen encryption
type, defined by [RFC3962]. type's random-to-key function over the pseudorandom value provided by
the <samlec:GeneratedKey> element. The result of that function is
used as the protocol key.
5.2.2. Derived Session Keys 5.2.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 may be supported. For private key, a formal key agreement algorithm might be supported.
example, if the server has an elliptic curve public key, the ECDH-ES This specification does not define such a mechanism, but the <samlec:
key agreement algorithm, as defined in [XMLENC11] may be used. SessionKey> element is extensible to allow for future work in this
space by means of the Algorithm attribute and an optional <ds:
In such a case, the initiator communicates to the acceptor what KeyInfo> child element to carry extensible content related to key
algorithm to use and any inputs to the process using a <samlec: establishment.
SessionKey> SOAP header block containing a <ds:KeyInfo> element,
added to the client response to the acceptor. The <ds:KeyInfo>
element will typically contain an <xenc11:DerivedKey> or <xenc:
AgreementMethod> element conforming to [XMLENC11]. The <ds:KeyInfo>
element may also contain other extensible content related to key
establishment mechanisms defined elsewhere.
As in the method described above, the outer element's EncType XML
attribute is set to the encryption type name from the registry
established by [RFC3961].
Regardless of the encryption type chosen, initiator and acceptor MUST However a key is derived, the <samlec:EncType> element will identify
execute the chosen encryption type's random-to-key function over the the chosen encrytion type, and both the initiator and acceptor MUST
result of the key agreement or derivation process. The result of execute the encryption type's random-to-key function over the result
that function is used as the protocol key. of the key agreement or derivation process. The result of that
function is used as the protocol key.
5.3. Per-Message Tokens 5.3. Per-Message Tokens
The per-message tokens SHALL be the same as those for the Kerberos V5 The per-message tokens SHALL be the same as those for the Kerberos V5
GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections).
The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state
(GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail
(GSS_C_CONF_FLAG) security context flags are always set to TRUE. (GSS_C_INTEG_FLAG) security context flags are always set to TRUE.
The "protocol key" SHALL be a key established in a manner described The "protocol key" SHALL be a key established in a manner described
in the previous section. "Specific keys" are then derived as usual in the previous section. "Specific keys" are then derived as usual
as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962].
The terms "protocol key" and "specific key" are Kerberos V5 terms The terms "protocol key" and "specific key" are Kerberos V5 terms
[RFC3961]. [RFC3961].
SAML20EC is PROT_READY as soon as the SAML response message has been SAML20EC is PROT_READY as soon as the SAML response message has been
seen. seen.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
biwsLA== biwsLA==
</auth> </auth>
The initial response is "n,," which signals that channel binding is The initial response is "n,," which signals that channel binding is
not used, there is no authorization identity, and the client does not not used, there is no authorization identity, and the client does not
support key-based confirmation or want mutual authentication. support key-based confirmation or want mutual authentication.
Step 5: Server sends a challenge to client in the form of a SOAP Step 5: Server sends a challenge to client in the form of a SOAP
envelope containing its SAML <AuthnRequest>: envelope containing its SAML <AuthnRequest>:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT
LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h
TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj
cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K
bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy
ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 MDAzLTA4IgogICAgICBtZXNzYWdlSUQ9ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRl
cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u cnN0YW5kPSIxIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2Fw
c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj Lm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIHJlc3BvbnNlQ29uc3VtZXJVUkw9
ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg InhtcHBAeG1wcC5leGFtcGxlLmNvbSIKICAgICAgc2VydmljZT0idXJuOm9hc2lz
ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB Om5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4KICAgIDxlY3A6
TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M
cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No
PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu
bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t
L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv
dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz
ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s
PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv
c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT
CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l
TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMTI4LWN0cy1obWFjLXNoYTEt
ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl OTY8L3NhbWxlYzpFbmNUeXBlPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMjU2
YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu LWN0cy1obWFjLXNoYTEtOTY8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNhbWxlYzpT
MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB ZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxzYW1scDpB
dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u dXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9uPSIyLjAi
dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj IElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAgIFByb3Rv
bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu Y29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdz
Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ OlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4
IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9
ZT4NCg== InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAg
</challenge> aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAg
ICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAg
ICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZv
cm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNv
bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250
ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6
YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z
YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl
ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6
Qm9keT4KPC9TOkVudmVsb3BlPg==
</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"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType>
<samlec:EncType>aes256-cts-hmac-sha1-96</samlec:EncType>
<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"
skipping to change at page 21, line 20 skipping to change at page 21, line 29
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body> <S:Body>
<samlp:AuthnRequest> <samlp:AuthnRequest>
<!-- 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 session key is included in the encrypted variant in the example). A generated key is included in
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:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:GeneratedKey xmlns:samlec="urn:ietf:params:xml:ns:samlec">
EncType="aes128-cts-hmac-sha1-96"> 3w1wSBKUosRLsU69xGK7dg==
<samlec:GeneratedKey> </samlec:GeneratedKey>
3w1wSBKUosRLsU69xGK7dg== </S:Header>
</samlec:GeneratedKey> <S:Body>
</samlec:SessionKey> <samlp:Response ID="d43h94r389309r" Version="2.0"
</S:Header> IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
<S:Body> Destination="xmpp@xmpp.example.com">
<samlp:Response ID="d43h94r389309r" Version="2.0" <saml:Issuer>https://saml.example.org</saml:Issuer>
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d" <samlp:Status>
Destination="xmpp@xmpp.example.com"> <samlp:StatusCode
<saml:Issuer>https://saml.example.org</saml:Issuer> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<samlp:Status> </samlp:Status>
<samlp:StatusCode <saml:EncryptedAssertion>
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> <!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</samlp:Status> </saml:EncryptedAssertion>
<saml:EncryptedAssertion> </samlp:Response>
<!-- contents elided, copy of samlec:SessionKey in Advice --> </S:Body>
</saml:EncryptedAssertion> </S:Envelope>
</samlp:Response>
</S:Body>
</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'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT
LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h
TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj
cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K
eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6
aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt MjAwMy0wOCIKICAgICAgUzphY3Rvcj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v
dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 cmcvc29hcC9hY3Rvci9uZXh0IgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIiBy
L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 ZWZUb01lc3NhZ2VJRD0iNmMzYTRmOGI5YzJkIi8+CiAgICA8c2FtbGVjOlNlc3Np
cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy b25LZXkgeG1sbnM6c2FtbGVjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNhbWxl
LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz YyIKICAgICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29h
dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 cC9lbnZlbG9wZS8iCiAgICAgIFM6bXVzdFVuZGVyc3RhbmQ9IjEiCiAgICAgIFM6
ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s YWN0b3I9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvYWN0b3IvbmV4
cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 dCI+CiAgICAgIDxzYW1sZWM6RW5jVHlwZT5hZXMxMjgtY3RzLWhtYWMtc2hhMS05
ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg Njwvc2FtbGVjOkVuY1R5cGU+CiAgICA8c2FtbGVjOlNlc3Npb25LZXk+CiAgPC9T
ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg OkhlYWRlcj4KICA8UzpCb2R5PgogICAgPHNhbWxwOlJlc3BvbnNlIElEPSJkNDNo
ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk OTRyMzg5MzA5ciIgVmVyc2lvbj0iMi4wIgogICAgICAgIElzc3VlSW5zdGFudD0i
QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu MjAwNy0xMi0xMFQxMTo0MjozNFoiIEluUmVzcG9uc2VUbz0iYzNhNGY4YjljMmQi
dmVsb3BlPg0K CiAgICAgICAgRGVzdGluYXRpb249InhtcHBAeG1wcC5leGFtcGxlLmNvbSI+CiAg
</response> ICAgIDxzYW1sOklzc3Vlcj5odHRwczovL3NhbWwuZXhhbXBsZS5vcmc8L3NhbWw6
SXNzdWVyPgogICAgICA8c2FtbHA6U3RhdHVzPgogICAgICAgIDxzYW1scDpTdGF0
dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg
ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl
bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj
ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft
bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K
</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"/>
</S:Header> <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
<S:Body> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
<samlp:Response ID="d43h94r389309r" Version="2.0" S:mustUnderstand="1"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d" S:actor="http://schemas.xmlsoap.org/soap/actor/next">
Destination="xmpp@xmpp.example.com"> <samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType>
<saml:Issuer>https://saml.example.org</saml:Issuer> <samlec:SessionKey>
<samlp:Status> </S:Header>
<samlp:StatusCode <S:Body>
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> <samlp:Response ID="d43h94r389309r" Version="2.0"
</samlp:Status> IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
<saml:EncryptedAssertion> Destination="xmpp@xmpp.example.com">
<!-- contents elided, copy of samlec:SessionKey in Advice --> <saml:Issuer>https://saml.example.org</saml:Issuer>
</saml:EncryptedAssertion> <samlp:Status>
</samlp:Response> <samlp:StatusCode
</S:Body> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
</S:Envelope> <saml:EncryptedAssertion>
<!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</saml:EncryptedAssertion>
</samlp:Response>
</S:Body>
</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 31, line 13 skipping to change at page 31, line 13
[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", Programming Interface (GSS-API) Naming Extensions",
RFC 6680, August 2012. RFC 6680, August 2012.
[XMLENC11]
Hirsch, F. and T. Roessler, "XML Encryption Syntax and
Processing Version 1.1", W3C Editor's Draft W3C.xmlenc-
core-11-ed, September 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, (SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
March 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
skipping to change at page 32, line 5 skipping to change at page 32, line 5
[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, "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>. May 2001, <http://www.w3.org/TR/xmlschema-1/>.
Appendix A. 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
conformance with [W3C.REC-xmlschema-1] While XML validation is conformance with [W3C.REC-xmlschema-1] While XML validation is
optional, the schema that follows is the normative definition of the optional, the schema that follows is the normative definition of the
constructs it defines. Where the schema differs from any prose in constructs it defines. Where the schema differs from any prose in
this specification, the schema takes precedence. this specification, the schema takes precedence.
<schema <schema
targetNamespace="urn:ietf:params:xml:ns:samlec" targetNamespace="urn:ietf:params:xml:ns:samlec"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:samlec="urn:ietf:params:xml:ns:samlec" xmlns:samlec="urn:ietf:params:xml:ns:samlec"
elementFormDefault="unqualified" elementFormDefault="unqualified"
attributeFormDefault="unqualified" attributeFormDefault="unqualified"
blockDefault="substitution" blockDefault="substitution"
version="1.0"> version="1.0">
<import namespace="http://www.w3.org/2000/09/xmldsig#"/> <import namespace="http://www.w3.org/2000/09/xmldsig#"/>
<import namespace="http://schemas.xmlsoap.org/soap/envelope/"/> <import namespace="http://schemas.xmlsoap.org/soap/envelope/"/>
<element name="SessionKey" type="samlec:SessionKeyType"/> <element name="SessionKey" type="samlec:SessionKeyType"/>
<complexType name="SessionKeyType"> <complexType name="SessionKeyType">
<choice> <sequence>
<element ref="samlec:GeneratedKey"/> <element ref="samlec:EncType" maxOccurs="unbounded"/>
<element ref="ds:KeyInfo"/> <element ref="ds:KeyInfo" minOccurs="0"/>
</choice> </sequence>
<attribute name="EncType" type="string" use="required"/> <attribute ref="S:mustUnderstand" use="required"/>
<attribute ref="S:mustUnderstand"/> <attribute ref="S:actor" use="required"/>
<attribute ref="S:actor"/> <attribute name="Algorithm"/>
</complexType> </complexType>
<element name="GeneratedKey" type="base64Binary"/> <element name="EncType" type="string"/>
<element name="SessionKeyMethod" type="samlec:SessionKeyMethodType"/> <element name="GeneratedKey" type="samlec:GeneratedKeyType"/>
<complexType name="SessionKeyMethodType"> <complexType name="GeneratedKeyType">
<sequence> <simpleContent>
<element ref="samlec:EncType" <extension base="base64Binary">
minOccurs="0" maxOccurs="unbounded"/> <attribute ref="S:mustUnderstand"/>
<any namespace="##other" processContents="lax" <attribute ref="S:actor"/>
minOccurs="0" maxOccurs="unbounded"/> </extension>
</sequence> </simpleContent>
<attribute name="Algorithm" type="anyURI"/> </complexType>
</complexType>
<element name="EncType" type="string"/> </schema>
</schema>
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, and Jim Basney for their contributions. Williams, and Jim Basney 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 06, simplified session key schema, moved responsibility for
random-to-key to the endpoints, and defined advertisement of
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
naming reference naming reference
o 04, stripped down the session key material to simplify it, and o 04, stripped down the session key material to simplify it, and
define an IdP-brokered keying approach, moved session key XML define an IdP-brokered keying approach, moved session key XML
constructs from OASIS draft into this one constructs from OASIS draft into this one
o 03, added TLS key export as a session key option, revised GSS o 03, added TLS key export as a session key option, revised GSS
naming material based on list discussion naming material based on list discussion
 End of changes. 31 change blocks. 
215 lines changed or deleted 251 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/