draft-ietf-kitten-sasl-saml-ec-02.txt   draft-ietf-kitten-sasl-saml-ec-03.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: February 14, 2013 SJD AB Expires: March 21, 2013 SJD AB
August 13, 2012 September 17, 2012
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-02.txt draft-ietf-kitten-sasl-saml-ec-03.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 February 14, 2013. This Internet-Draft will expire on March 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9
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. Session Key Derivation . . . . . . . . . . . . . . . . . . 12 5.1. Session Key Derivation . . . . . . . . . . . . . . . . . . 12
5.1.1. Bearer Assertion Session Keys . . . . . . . . . . . . 13 5.1.1. TLS-Exported Session Keys . . . . . . . . . . . . . . 13
5.1.2. Holder of Key Session Keys . . . . . . . . . . . . . . 14 5.1.2. Bearer Assertion Session Keys . . . . . . . . . . . . 14
5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 5.1.3. Holder of Key Session Keys . . . . . . . . . . . . . . 14
5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 14 5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15
5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15
5.4.1. Support for User Name Form . . . . . . . . . . . . . . 15 5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 16
5.4.2. Support for Host-Based Service Name Form . . . . . . . 16 5.4.1. User Naming Considerations . . . . . . . . . . . . . . 16
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4.2. Service Naming Considerations . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 25
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 25 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Normative References for GSS-API Implementers . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.3. Informative References . . . . . . . . . . . . . . . . . . 29 9.2. Normative References for GSS-API Implementers . . . . . . 29
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 9.3. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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 5 skipping to change at page 13, line 5
MUST contain an <AudienceRestriction> condition element identifying MUST contain an <AudienceRestriction> condition element identifying
the identity provider, and a <SubjectConfirmation> element that the the identity provider, and a <SubjectConfirmation> element that the
acceptor can satisy. In such a case, the security context will have acceptor can satisy. In such a case, the security context will have
its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE.
5.1. Session Key Derivation 5.1. 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 security context session key be established as a result security context
establishment. In the common case of a "bearer" assertion in SAML, establishment. In the common case of a "bearer" assertion in SAML,
there is no secure mechanism by which such a key can be established. there is no secure mechanism by which such a key can be established
In other cases such as assertions based on "holder of key" other than by exporting key material from TLS (discussed below). In
confirmation, there may be. other cases such as assertions based on "holder of key" confirmation,
there may be additional methods available.
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 by the client to the server using an deriving one, is communicated by the client to the server using an
<ecp:SessionKey> SOAP header block, as defined in [SAMLECP20]. This <ecp:SessionKey> SOAP header block, as defined in [SAMLECP20]. This
header contains a <ds:KeyInfo> element as a generic container, and is header contains a <ds:KeyInfo> element as a generic container, and is
designed to support reuse of mechanisms defined by [XMLENC11] or designed to support reuse of mechanisms defined by [XMLENC11] or
other specifications. other specifications.
5.1.1. Bearer Assertion Session Keys 5.1.1. TLS-Exported Session Keys
If a TLS session is established between the initiator and acceptor,
it may be used to produce a session key using the mechanism defined
by [RFC5705]. The disambiguating label string MUST be set to
"EXPORTER_SAML20EC". [Remove upon publication, IANA to assign at the
following location: http://www.iana.org/assignments/tls-parameters/
tls-parameters.xml#exporter-labels] The per-association context value
MUST be set to a 128-bit pseudorandom value generated by the client.
The pseudorandom octets are then base64- encoded and placed in a
<CipherData> element inside a <ecp:SessionKey> SOAP header block in
the following manner:
<ecp:SessionKey S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc11:DerivedKey xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
<xenc11:KeyDerivationMethod Algorithm="TBD">
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:CipherValue>h1dqhs+aHxYjYNKiEwzjVg==</xenc:CipherValue>
</xenc:CipherData>
</xenc11:KeyDerivationMethod>
</xenc11:DerivedKey>
</ds:KeyInfo>
</ecp:SessionKey>
The derivation algorithm of TBD (IANA to assign: see IANA
considerations) signifies the TLS-Exported approach described above.
5.1.2. Bearer Assertion Session Keys
In the event that a client is not capable of supporting the "holder In the event that a client is not capable of supporting the "holder
of key" option (or if other infrastructure components do not do so), of key" option (or if other infrastructure components do not do so)
but still wishes to make use of a session key, the client MAY and cannot use a TLS-exported key, but still wishes to make use of a
generate a random value of 128 bits. The octets are then base64- session key, the client MAY generate a pseudorandom value of 128 bits
encoded and placed in a <CipherData> element inside a <ecp: to use as a key. The octets are then base64-encoded and placed in a
SessionKey> SOAP header block in the following manner: <CipherData> element inside a <ecp:SessionKey> SOAP header block in
the following manner:
<ecp:SessionKey S:mustUnderstand="1" <ecp:SessionKey S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc11:DerivedKey xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"> <xenc11:DerivedKey xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
<xenc11:KeyDerivationMethod Algorithm="TBD"> <xenc11:KeyDerivationMethod Algorithm="TBD">
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:CipherValue>h1dqhs+aHxYjYNKiEwzjVg==</xenc:CipherValue> <xenc:CipherValue>h1dqhs+aHxYjYNKiEwzjVg==</xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</xenc11:KeyDerivationMethod> </xenc11:KeyDerivationMethod>
</xenc11:DerivedKey> </xenc11:DerivedKey>
</ds:KeyInfo> </ds:KeyInfo>
</ecp:SessionKey> </ecp:SessionKey>
The derivation algorithm of TBD (IANA to assign: see IANA The derivation algorithm of TBD (IANA to assign: see IANA
considerations)\ signifies the client-generated approach described considerations) signifies the client-generated approach described
above. above.
Applications that rely on this mechanism do so with the understanding Applications that rely on this mechanism do so with the understanding
that it is not a secure approach, but merely for compatibility when that it is not a secure approach, but merely for compatibility if the
the risk is accepted. risk is acceptable.
5.1.2. Holder of Key Session Keys 5.1.3. Holder of Key Session Keys
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, the session key can be communicated in a manner that private key, the session key can be communicated in a manner that
proves its authenticity, or a formal key agreement algorithm may be proves its authenticity, or a formal key agreement algorithm may be
supported. For example, if the server has an elliptic curve public supported. For example, if the server has an elliptic curve public
key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11] key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11]
may be used. may be used.
If a key agreement or derivation process is not possible, then the If a key agreement or derivation process is not possible, then the
mechanism defined in the previous section can be used, with the added mechanism defined in the previous section can be used, with the added
benefit that the client's request will be strongly authenticated by a benefit that the client's request will be strongly authenticated by a
key. However, if channel binding is not used, the generated key key. However, if channel binding is not used, the generated key
SHOULD be wrapped or transported under the protection of a key SHOULD be wrapped or transported under the protection of a key
belonging to the server, such as an RSA public key. The <xenc: belonging to the server, such as an RSA public key. The <xenc:
EncryptedKey> element and associated key wrap and transport EncryptedKey> element and associated key wrap and transport
algorithms (see [XMLENC11]) can be used for this purpose. algorithms (see [XMLENC11]) can be used for this purpose.
Note that this server no purpose in the bearer case, since if channel Note that this serves no purpose in the bearer case, since if channel
binding is not used, an attacker can generate its own key, and if it binding is not used, an attacker can generate its own key, and if it
is used, there is no MITM to see the key. is used, there is no MITM to see the key.
5.2. Per-Message Tokens 5.2. Per-Message Tokens
The per-message tokens SHALL be the same as those for the Kerberos V The per-message tokens SHALL be the same as those for the Kerberos V
GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections), using GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections), using
the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962]. the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state
skipping to change at page 15, line 23 skipping to change at page 16, line 14
5.4. GSS-API Principal Name Types for SAML EC 5.4. GSS-API Principal Name Types for SAML EC
Services that act as SAML relying parties are typically identified by Services that act as SAML relying parties are typically identified by
means of a URI called an "entityID". Clients that are named in the means of a URI called an "entityID". Clients that are named in the
<Subject> element of a SAML assertion are typically identified by <Subject> element of a SAML assertion are typically identified by
means of a <NameID> element, which is an extensible XML structure means of a <NameID> element, which is an extensible XML structure
containing, at minimum, an element value that names the subject and a containing, at minimum, an element value that names the subject and a
Format attribute. Format attribute.
In practice, a GSS-API client and server are unlikely to know the In practice, a GSS-API client and server are unlikely to know in
name of the initiator as it will be expressed by the SAML identity advance the name of the initiator as it will be expressed by the SAML
provider upon completion of authentication. It is also generally identity provider upon completion of authentication. It is also
incorrect to assume that a particular acceptor name will directly map generally incorrect to assume that a particular acceptor name will
into a particular RP entityID, because there is often a layer of directly map into a particular RP entityID, because there is often a
naming indirection between particular services on hosts and the layer of naming indirection between particular services on hosts and
identity of a relying party in SAML terms. the identity of a relying party in SAML terms.
The SAML EC mechanism is compatible with the common/expected name To avoid complexity, and avoid unnecessary use of XML within the
types used for acceptors and initiators, GSS_C_NT_HOSTBASED_SERVICE naming layer, the SAML EC mechanism relies on the common/expected
and GSS_C_NT_USER_NAME. The mechanism provides for validation of the name types used for acceptors and initiators,
host-based service name in conjunction with the SAML exchange. It GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism
does not attempt to solve the problem of mapping between an initiator provides for validation of the host-based service name in conjunction
"username", the user's identity while authenticating to the identity with the SAML exchange. It does not attempt to solve the problem of
provider, and the information supplied by the identity provider to mapping between an initiator "username", the user's identity while
the acceptor. These relationships must be managed through local authenticating to the identity provider, and the information supplied
policy at the initiator and acceptor. by the identity provider to the acceptor. These relationships must
be managed through local policy at the initiator and acceptor.
5.4.1. Support for User Name Form SAML-based information associated with the initiator SHOULD be
expressed to the acceptor using GSS-API naming extensions
[I-D.ietf-kitten-gssapi-naming-exts], in accordance with
[I-D.ietf-abfab-gss-eap-naming].
5.4.1. User Naming Considerations
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. The client relies 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
supplies it to the server for use by the acceptor. supply it to the server for use by the acceptor.
No SAML-specific mechanism name type is defined. SAML-based Upon successful completion of this mechanism, the server MUST
information associated with the initiator SHOULD be expressed to the construct the authenticated initiator name based on the <saml:NameID>
acceptor using GSS-API naming extensions element in the assertion it successfully validated. The name is
[I-D.ietf-kitten-gssapi-naming-exts], in accordance with constructed as a UTF-8 string in the following form:
[I-D.ietf-abfab-gss-eap-naming]. This information MUST be evaluated name = element-value "!" Format "!" NameQualifier
by the mechanism at the server to determine whether to accept the "!" SPNameQualifier "!" SPProvidedID
initiator name as a valid, authenticated name for the client.
Failure to establish this MUST result in failure of the mechanism.
5.4.2. Support for Host-Based Service Name Form The "element-value" token refers to the content of the <saml:NameID>
element. The other tokens refer to the identically named XML
attributes defined for use with the element. If an attribute is not
present, which is common, it is omitted (i.e., replaced with the
empty string). The Format value is never omitted; if not present,
the SAML-equivalent value of
"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used.
Not all SAML assertions contain a <saml:NameID> element. In the
event that no such element is present, including the exceptional
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
for the initiator name.
As noted in the previous section, it is expected that most
applications able to rely on SAML authentication would make use of
naming extensions to obtain additional information about the user
based on the assertion. This is particularly true in the anonymous
case, or in cases in which the SAML name is pseudonymous or transient
in nature. The ability to express the SAML name in
GSS_C_NT_USER_NAME form is intended for compatibility with
applications that cannot make use of additional information.
5.4.2. Service Naming Considerations
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
on a host; it is textually represented as "service@host". This name on a host; it is textually represented as "service@host". This name
form is required by most SASL profiles and is used by many existing form is required by most SASL profiles and is used by many existing
applications that use the Kerberos GSS-API mechanism. Such a name is applications that use the Kerberos GSS-API mechanism. Such a name is
used directly by this mechanism as the effective used directly by this mechanism as the effective
AssertionConsumerService of the server. AssertionConsumerService of the server.
This value is used in the construction of the responseConsumerURL and This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison AssertionConsumerServiceURL attributes, and for eventual comparison
skipping to change at page 17, line 41 skipping to change at page 18, line 41
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
<mechanism>SAML20EC</mechanism> <mechanism>SAML20EC</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 4: Client selects an authentication mechanism and sends the Step 4: Client selects an authentication mechanism and sends the
initial client response (it is base64 encoded as specified by the initial client response (it is base64 encoded as specified by the
XMPP SASL protocol profile): XMPP SASL protocol profile):
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'>
biws 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. 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 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy
LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v
cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4
bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9
skipping to change at page 26, line 26 skipping to change at page 27, line 26
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
For further information: Contact the authors of this document. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Owner/Change controller: the IETF
Note: None Note: None
The IANA is requested to assign a URI to identify the key derivation The IANA is requested to assign a new entry of "EXPORTER_SAML20EC" in
algorithm described in this document for client-generated session the TLS Parameters Exporter Label Registry.
keys.
The IANA is requested to assign two URIs to identify the key
derivation algorithms described in this document for TLS-exported,
and client-generated session keys.
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 Language (SAML) V2.0", OASIS
Standard saml-bindings-2.0-os, March 2005. Standard saml-bindings-2.0-os, March 2005.
skipping to change at page 28, line 17 skipping to change at page 29, line 17
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-ecp- Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp-
v2.0-wd05, July 2012. v2.0-wd05, July 2012.
[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 "Simple Object Access Protocol (SOAP) 1.1", W3C
Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>. Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>.
[XMLENC11]
Hirsch, F. and T. Roessler, "XML Encryption Syntax and
Processing Version 1.1", W3C Editor's Draft W3C.xmlenc-
core-11-ed, July 2012.
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-03 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-04
(work in progress), July 2012. (work in progress), August 2012.
[I-D.ietf-kitten-gssapi-naming-exts] [I-D.ietf-kitten-gssapi-naming-exts]
Williams, N., Johansson, L., Hartman, S., and S. Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "GSS-API Naming Extensions", Josefsson, "GSS-API Naming Extensions",
draft-ietf-kitten-gssapi-naming-exts-15 (work in draft-ietf-kitten-gssapi-naming-exts-15 (work in
progress), May 2012. progress), May 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.
skipping to change at page 29, line 9 skipping to change at page 30, line 5
July 2005. July 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006. Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
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.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[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.
[XMLENC11]
Hirsch, F. and T. Roessler, "XML Encryption Syntax and
Processing Version 1.1", W3C Editor's Draft W3C.xmlenc-
core-11-ed, 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, (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 31, line 9 skipping to change at page 32, line 9
Appendix A. Acknowledgments Appendix A. 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 B. Changes Appendix B. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 03, added TLS key export as a session key option, revised GSS
naming material based on list discussion
o 02, major revision of GSS-API material and updated references o 02, major revision of GSS-API material and updated references
o 01, SSH language added, noted non-assumption of HTTP error o 01, SSH language added, noted non-assumption of HTTP error
handling, added guidance on life of security context. handling, added guidance on life of security context.
o 00, Initial Revision, first WG-adopted draft. Removed support for o 00, Initial Revision, first WG-adopted draft. Removed support for
unsolicited SAML responses. unsolicited SAML responses.
Authors' Addresses Authors' Addresses
 End of changes. 27 change blocks. 
78 lines changed or deleted 148 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/