draft-ietf-kitten-sasl-saml-ec-04.txt   draft-ietf-kitten-sasl-saml-ec-05.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: April 20, 2013 SJD AB Expires: June 6, 2013 SJD AB
October 17, 2012 December 3, 2012
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-04.txt draft-ietf-kitten-sasl-saml-ec-05.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 April 20, 2013. This Internet-Draft will expire on June 6, 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 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . 13
5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14 5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14
5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . 16 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
skipping to change at page 12, line 46 skipping to change at page 12, line 46
The lifetime of a security context established with this mechanism The lifetime of a security context established with this mechanism
SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if
any, in the <AuthnStatement> of the SAML assertion received by the any, in the <AuthnStatement> of the SAML assertion received by the
RP. RP.
SAML EC supports credential delegation through the issuance of SAML SAML EC supports credential delegation through the issuance of SAML
assertions that the issuing identity provider will accept as proof of assertions that the issuing identity provider will accept as proof of
authentication by a service on behalf of a user. Such assertions authentication by a service on behalf of a user. Such assertions
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 may 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. GSS-API Channel Binding 5.1. GSS-API Channel Binding
GSS-API channel binding [RFC5554] is a protected facility for GSS-API channel binding [RFC5554] is a protected facility for
exchanging a cryptographic name for an enclosing channel between the exchanging a cryptographic name for an enclosing channel between the
initiator and acceptor. The initiator sends channel binding data and initiator and acceptor. The initiator sends channel binding data and
the acceptor confirms that channel binding data has been checked. the acceptor confirms that channel binding data has been checked.
The acceptor SHOULD accept any channel binding provided by the The acceptor SHOULD accept any channel binding provided by the
skipping to change at page 13, line 19 skipping to change at page 13, line 19
gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559]
depend on this behavior of some Kerberos implementations. depend on this behavior of some Kerberos implementations.
The exchange and verification of channel binding information is The exchange and verification of channel binding information is
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, establishment. In the common case of a "bearer" assertion in SAML, a
there are a pair of approaches defined: exporting key material from mechanism is defined to communicate a key to both parties via the
TLS and communicating a key to both parties via the identity identity provider. In other cases such as assertions based on
provider. Both are discussed below. In other cases such as "holder of key" confirmation bound to a client-controlled key, there
assertions based on "holder of key" confirmation bound to a client- may be additional methods supported.
controlled key, 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 using a <samlec:SessionKey> element, deriving one, is communicated using a <samlec:SessionKey> element,
defined in the schema in Appendix A. This element can be used as a defined by the XML schema in Appendix A. This element can be used as
SOAP header block or as an extension within a SAML assertion, a SOAP header block or as an extension within a SAML assertion,
depending on the context of communication. The content of the depending on the context of communication. The content of the
element further depends on the specific use in the mechanism and is element further depends on the specific use in the mechanism and is
discussed below. discussed below.
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. The element's Algorithm XML attribute is set to the element.
encryption type name from the registry established by [RFC3961].
The <samlec:GeneratedKey> element is placed within a <samlec: Regardless of the encryption type chosen, the identity provider MUST
SessionKey> element, and this element is placed within the <saml: produce a key by generating sufficient pseudorandom bits and
Advice> element of the assertion issued. A copy of the element is executing the chosen encryption type's random-to-key function over
also added as a SOAP header block in the response from the identity the input. The result of that function is the key to be encoded and
provider to the client. placed inside the element.
The resulting <samlec:GeneratedKey> element is placed within a
<samlec:SessionKey> element whose EncType XML attribute is set to the
appropriate encryption type name used. The <samlec:SessionKey>
element is placed within the <saml:Advice> element of the assertion
issued. A copy of the element is also added as a SOAP header block
in the response from the identity provider to the client.
The identity provider is left to determine which encryption type the The identity provider is left to determine which encryption type the
parties should use. It is unspecified how the initiator's parties should use. It is unspecified how the initiator's
capabilities are determined in this respect, but the acceptor MAY capabilities are determined in this respect, but the acceptor MAY
indicate the algorithms it supports in its SAML metadata by means of indicate the encryption types it supports in its SAML metadata by
one or more <SessionKeyMethod> elements in an <samlmd:Extensions> means of a <samlec:SessionKeyMethod> element in a <samlmd:Extensions>
element, and an identity provider can leverage this information. element, and an identity provider may leverage this information. The
Multiple such extension elements may appear, in order of preference omission of the element's Algorithm XML attribute represents support
by the acceptor. 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 All parties MUST support the "aes128-cts-hmac-sha1-96" encryption
type, defined by [RFC3962]. type, defined by [RFC3962].
5.2.2. Derived Session Keys 5.2.2. Derived 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, a formal key agreement algorithm may be supported. For private key, a formal key agreement algorithm may be supported. For
example, if the server has an elliptic curve public key, the ECDH-ES example, if the server has an elliptic curve public key, the ECDH-ES
key agreement algorithm, as defined in [XMLENC11] may be used. key agreement algorithm, as defined in [XMLENC11] may be used.
In such a case, the initiator communicates to the acceptor what In such a case, the initiator communicates to the acceptor what
algorithm to use and any inputs to the process using a <SessionKey> algorithm to use and any inputs to the process using a <samlec:
SOAP header block containing a <ds:KeyInfo> element, added to the SessionKey> SOAP header block containing a <ds:KeyInfo> element,
client response to the acceptor. The <ds:KeyInfo> element will added to the client response to the acceptor. The <ds:KeyInfo>
typically contain an <xenc11:DerivedKey> element conforming to element will typically contain an <xenc11:DerivedKey> or <xenc:
[XMLENC11]. The <ds:KeyInfo> element may also contain other AgreementMethod> element conforming to [XMLENC11]. The <ds:KeyInfo>
extensible content related to key establishment mechanisms defined element may also contain other extensible content related to key
elsewhere. 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
execute the chosen encryption type's random-to-key function over the
result 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_CONF_FLAG) security context flags are always set to TRUE.
The "protocol key" SHALL be a session key established in a manner The "protocol key" SHALL be a key established in a manner described
described in the previous section. "Specific keys" are then derived in the previous section. "Specific keys" are then derived as usual
as usual as described in Section 2 of [RFC4121], [RFC3961], and as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962].
[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.
5.4. Pseudo-Random Function (PRF) 5.4. Pseudo-Random Function (PRF)
The GSS-API has been extended with a Pseudo-Random Function (PRF) The GSS-API has been extended with a Pseudo-Random Function (PRF)
skipping to change at page 15, line 49 skipping to change at page 16, line 13
name types used for acceptors and initiators, name types used for acceptors and initiators,
GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism
provides for validation of the host-based service name in conjunction provides for validation of the host-based service name in conjunction
with the SAML exchange. It does not attempt to solve the problem of with the SAML exchange. It does not attempt to solve the problem of
mapping between an initiator "username", the user's identity while mapping between an initiator "username", the user's identity while
authenticating to the identity provider, and the information supplied authenticating to the identity provider, and the information supplied
by the identity provider to the acceptor. These relationships must by the identity provider to the acceptor. These relationships must
be managed through local policy at the initiator and acceptor. be managed through local policy at the initiator and acceptor.
SAML-based information associated with the initiator SHOULD be SAML-based information associated with the initiator SHOULD be
expressed to the acceptor using GSS-API naming extensions expressed to the acceptor using GSS-API naming extensions [RFC6680],
[I-D.ietf-kitten-gssapi-naming-exts], in accordance with in accordance with [I-D.ietf-abfab-gss-eap-naming].
[I-D.ietf-abfab-gss-eap-naming].
5.5.1. User Naming Considerations 5.5.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. 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>
skipping to change at page 16, line 50 skipping to change at page 17, line 13
GSS_C_NT_USER_NAME form is intended for compatibility with GSS_C_NT_USER_NAME form is intended for compatibility with
applications that cannot make use of additional information. applications that cannot make use of additional information.
5.5.2. Service Naming Considerations 5.5.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 "location" associated with the service.
This value is used in the construction of the responseConsumerURL and This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison AssertionConsumerServiceURL attributes, and for eventual comparison
and validation by the client before completing the exchange. The and validation by the client before completing the exchange. The
value MUST be securely associated with the SAML entityID claimed by value MUST be securely associated with the SAML entityID claimed by
the server by the identity provider, such as through the use of SAML the server by the identity provider, such as through the use of SAML
metadata [OASIS.saml-metadata-2.0-os]. metadata [OASIS.saml-metadata-2.0-os].
6. Example 6. Example
skipping to change at page 22, line 13 skipping to change at page 22, line 13
assertion and in a header for the client. 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:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
<samlec:GeneratedKey Algorithm="aes128-cts-hmac-sha1-96"> EncType="aes128-cts-hmac-sha1-96">
<samlec:GeneratedKey>
3w1wSBKUosRLsU69xGK7dg== 3w1wSBKUosRLsU69xGK7dg==
</samlec:GeneratedKey> </samlec:GeneratedKey>
</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, has copy of session key in Advice --> <!-- contents elided, copy of samlec:SessionKey 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'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy
skipping to change at page 23, line 47 skipping to change at page 23, line 47
<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, has copy of session key in Advice --> <!-- contents elided, copy of samlec:SessionKey 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'/>
skipping to change at page 26, line 51 skipping to change at page 26, line 51
encrypting assertions with authenticated keys. encrypting assertions with authenticated keys.
7.2. User Privacy 7.2. User Privacy
The IdP is aware of each RP that a user logs into. There is nothing The IdP is aware of each RP that a user logs into. There is nothing
in the protocol to hide this information from the IdP. It is not a in the protocol to hide this information from the IdP. It is not a
requirement to track the activity, but there is nothing technically requirement to track the activity, but there is nothing technically
that prohibits the collection of this information. Servers should be that prohibits the collection of this information. Servers should be
aware that SAML IdPs will track - to some extent - user access to aware that SAML IdPs will track - to some extent - user access to
their services. This exposure extends to the use of session keys their services. This exposure extends to the use of session keys
generated by the IdP to secure messages between the parties. generated by the IdP to secure messages between the parties, but note
that when bearer assertions are involved, the IdP can freely
impersonate the user to any relying party in any case.
It is also out of scope of the mechanism to determine under what It is also out of scope of the mechanism to determine under what
conditions an IdP will release particular information to a relying conditions an IdP will release particular information to a relying
party, and it is generally unclear in what fashion user consent could party, and it is generally unclear in what fashion user consent could
be established in real time for the release of particular be established in real time for the release of particular
information. The SOAP exchange with the IdP does not preclude such information. The SOAP exchange with the IdP does not preclude such
interaction, but neither does it define that interoperably. interaction, but neither does it define that interoperably.
7.3. Collusion between RPs 7.3. Collusion between RPs
skipping to change at page 30, line 21 skipping to change at page 30, line 21
[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/>.
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-06 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-07
(work in progress), October 2012. (work in progress), November 2012.
[I-D.ietf-kitten-gssapi-naming-exts]
Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "GSS-API Naming Extensions",
draft-ietf-kitten-gssapi-naming-exts-15 (work in
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.
[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.
skipping to change at page 31, line 15 skipping to change at page 31, line 8
[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, (GSS-API) for the Use of Channel Bindings", RFC 5554,
May 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.
Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions",
RFC 6680, August 2012.
[XMLENC11] [XMLENC11]
Hirsch, F. and T. Roessler, "XML Encryption Syntax and Hirsch, F. and T. Roessler, "XML Encryption Syntax and
Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- Processing Version 1.1", W3C Editor's Draft W3C.xmlenc-
core-11-ed, September 2012. 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
skipping to change at page 33, line 25 skipping to change at page 32, line 34
<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> <choice>
<element ref="samlec:GeneratedKey"/> <element ref="samlec:GeneratedKey"/>
<element ref="ds:KeyInfo"/> <element ref="ds:KeyInfo"/>
</choice> </choice>
<attribute name="EncType" type="string" use="required"/>
<attribute ref="S:mustUnderstand"/> <attribute ref="S:mustUnderstand"/>
<attribute ref="S:actor"/> <attribute ref="S:actor"/>
</complexType> </complexType>
<element name="GeneratedKey" type="samlec:GeneratedKeyType"/> <element name="GeneratedKey" type="base64Binary"/>
<complexType name="GeneratedKeyType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Algorithm" type="string" use="required"/>
</extension>
</simpleContent>
</complexType>
<element name="SessionKeyMethod" type="samlec:SessionKeyMethodType"/> <element name="SessionKeyMethod" type="samlec:SessionKeyMethodType"/>
<complexType name="SessionKeyMethodType"> <complexType name="SessionKeyMethodType">
<sequence> <sequence>
<any namespace="##any" processContents="lax" <element ref="samlec:EncType"
minOccurs="0" maxOccurs="unbounded"/>
<any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
<attribute name="Algorithm" type="anyURI" use="required"/> <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 05, revised session key material, added requirement for random-to-
key, revised XML schema to capture enctype name, updated GSS
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
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
 End of changes. 26 change blocks. 
64 lines changed or deleted 81 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/