draft-ietf-kitten-sasl-saml-ec-01.txt   draft-ietf-kitten-sasl-saml-ec-02.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: August 31, 2012 SJD AB Expires: February 14, 2013 SJD AB
February 28, 2012 August 13, 2012
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-01.txt draft-ietf-kitten-sasl-saml-ec-02.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 August 31, 2012. This Internet-Draft will expire on February 14, 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 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . 11 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12
5.1. GSS-API Principal Name Types for SAML EC . . . . . . . . . 11 5.1. Session Key Derivation . . . . . . . . . . . . . . . . . . 12
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Bearer Assertion Session Keys . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1.2. Holder of Key Session Keys . . . . . . . . . . . . . . 14
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 20 5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 14
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 21 5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.4.1. Support for User Name Form . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.2. Support for Host-Based Service Name Form . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Normative References for GSS-API Implementers . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.3. Informative References . . . . . . . . . . . . . . . . . . 24 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 26 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27
9.2. Normative References for GSS-API Implementers . . . . . . 28
9.3. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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 9, line 26 skipping to change at page 9, line 26
4.2. Initiation 4.2. Initiation
A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If
supported by the application protocol, the client MAY include an supported by the application protocol, the client MAY include an
initial response, otherwise it waits until the server has issued an initial response, otherwise it waits until the server has issued an
empty challenge (because the mechanism is client-first). empty challenge (because the mechanism is client-first).
The format of the initial client response is as follows: The format of the initial client response is as follows:
holder-of-key = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"
initial-response = gs2-cb-flag "," [gs2-authzid] "," [holder-of-key] mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \
"WantAuthnRequestsSigned"
initial-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mutual]
The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate
whether the client supports channel binding. This takes the place of whether the client supports channel binding. This takes the place of
the PAOS HTTP header extension used in [SAMLECP20] to indicate the PAOS HTTP header extension used in [SAMLECP20] to indicate
channel binding support. channel binding support.
The optional "gs2-authzid" field holds the authorization identity, as The optional "gs2-authzid" field holds the authorization identity, as
requested by the client. requested by the client.
The optional "holder-of-key" field is a constant that signals the The optional "hok" field is a constant that signals the client's
client's support for stronger security by means of a locally held support for stronger security by means of a locally held key. This
key. This takes the place of the PAOS HTTP header extension used in takes the place of the PAOS HTTP header extension used in [SAMLECP20]
[SAMLECP20] to indicate "holder of key" support. to indicate "holder of key" support.
The optional "mutual" field is a constant that signals the client's
desire for mutual authentication. If set, the SASL server MUST
digitally sign its SAML <AuthnRequest> message. The URN constant
above is a single string; the linefeed is shown for RFC formatting
reasons.
4.3. Server Response 4.3. Server Response
The SASL server responds with a SOAP envelope constructed in The SASL server responds with a SOAP envelope constructed in
accordance with section 2.3.2 of [SAMLECP20]. This includes adhering accordance with section 2.3.2 of [SAMLECP20]. This includes adhering
to the SOAP header requirements of the SAML PAOS Binding to the SOAP header requirements of the SAML PAOS Binding
[OASIS.saml-bindings-2.0-os], for compatibility with the existing [OASIS.saml-bindings-2.0-os], for compatibility with the existing
profile. Various SOAP headers are also consumed by the client in profile. Various SOAP headers are also consumed by the client in
exactly the same manner prescribed by that section. exactly the same manner prescribed by that section.
skipping to change at page 10, line 45 skipping to change at page 11, line 6
4.7. Additional Notes 4.7. Additional Notes
Because this mechanism is an adaptation of an HTTP-based profile, Because this mechanism is an adaptation of an HTTP-based profile,
there are a few requirements outlined in [SAMLECP20] that make there are a few requirements outlined in [SAMLECP20] that make
reference to a response URL that is normally used to regulate where reference to a response URL that is normally used to regulate where
the client returns information to the RP. There are also security- the client returns information to the RP. There are also security-
related checks built into the profile that involve this location. related checks built into the profile that involve this location.
For compatibility with existing IdP and profile behavior, and to For compatibility with existing IdP and profile behavior, and to
provide for secure identification of the RP to the client, the SASL provide for mutual authentication, the SASL server MUST populate the
server MUST populate the responseConsumerURL and responseConsumerURL and AssertionConsumerServiceURL attributes with
AssertionConsumerServiceURL attributes with its service name, its service name. The parties then perform the steps described in
expressed as an absolute URI. The parties then perform the steps [SAMLECP20] as usual.
described in [SAMLECP20] as usual.
Similarly, the use of HTTP status signaling between the RP and client Similarly, the use of HTTP status signaling between the RP and client
mandated by [SAMLECP20] may not be applicable. mandated by [SAMLECP20] may not be applicable.
5. SAML EC GSS-API Mechanism Specification 5. SAML EC GSS-API Mechanism Specification
This section and its sub-sections and all normative references of it This section and its sub-sections and all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism.
The messages are the same, but a) the GS2 header on the client's The messages are the same, but a) the GS2 header on the client's
first message is excluded when SAML EC is used as a GSS-API first message is excluded when SAML EC is used as a GSS-API
mechanism, and b) the RFC2743 section 3.1 initial context token mechanism, and b) the RFC2743 section 3.1 initial context token
header is prefixed to the client's first authentication message header is prefixed to the client's first authentication message
(context token). (context token).
The GSS-API mechanism OID for SAML EC is 1.3.6.1.4.1.11591.4.6. The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see
IANA considerations). The DER encoding of the OID is TBD.
SAML EC security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. SAML EC does not support credential
delegation, therefore SAML EC security contexts alway have the
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
The mutual authentication property of this mechanism relies on The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE,
successfully comparing the server identity from the existing security resulting in the "mutual-auth" option set in the initial client
layer (TLS, SSH, etc.) with the negotiated target name. Since the response. The security context mutual_state flag is set to TRUE only
existing security layer is managed by the application outside of the if the server digitally signs its SAML <AuthnRequest> message, and
GSS-API mechanism, the mechanism itself is unable to confirm the the identity provider signals this to the client in an <ecp:
name. For this reason, applications MUST match the server identity RequestAuthenticated> SOAP header block.
from the existing security layer with the target name. For TLS, this
matching MUST be perfored as discussed in [RFC6125]. For SSH, this
matching MUST be performed as discussed in [RFC4462]. Applications
may rely on the GSS-API mechanism to perform this matching by passing
the server identity as the targ_name parameter to
GSS_Init_sec_context().
The SAML EC mechanism does not support per-message tokens or If the mutual_state flag is not requested, or is not set, then the
GSS_Pseudo_random. security layer managed by the application outside of the GSS-API
mechanism is responsible for authenticating the acceptor. In this
case, applications MUST match the server identity from the existing
security layer with the target name. For TLS, this matching MUST be
performed as discussed in [RFC6125]. For SSH, this matching MUST be
performed as discussed in [RFC4462].
The lifetime of a security context established with this mechanism The lifetime of a security context established with this mechanism
SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if
any, in the <AuthnStatement> of the SAML assertion received by the any, in the <AuthnStatement> of the SAML assertion received by the
RP. RP.
5.1. GSS-API Principal Name Types for SAML EC SAML EC supports credential delegation through the issuance of SAML
assertions that the issuing identity provider will accept as proof of
authentication by a service on behalf of a user. Such assertions
MUST contain an <AudienceRestriction> condition element identifying
the identity provider, and a <SubjectConfirmation> element that the
acceptor can satisy. In such a case, the security context will have
its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE.
SAML EC supports standard generic name syntaxes for acceptors such as 5.1. Session Key Derivation
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). These
service names MUST be associated with the SAML "entityID" claimed by
the RP, such as through the use of SAML metadata
[OASIS.saml-metadata-2.0-os].
SAML EC supports only a single name type for initiators: Some GSS-API features (discussed in the following sections) require a
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for session key be established as a result security context
SAML EC. establishment. In the common case of a "bearer" assertion in SAML,
there is no secure mechanism by which such a key can be established.
In other cases such as assertions based on "holder of key"
confirmation, there may be.
The query, display, and exported name syntaxes for SAML EC principal Information defining or describing the session key, or a process for
names are all the same. There are no SAML EC-specific name syntaxes deriving one, is communicated by the client to the server using an
-- applications should use generic GSS-API name types such as <ecp:SessionKey> SOAP header block, as defined in [SAMLECP20]. This
GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], header contains a <ds:KeyInfo> element as a generic container, and is
Section 4). The exported name token does, of course, conform to designed to support reuse of mechanisms defined by [XMLENC11] or
[RFC2743], Section 3.2, but the "NAME" part of the token should be other specifications.
treated as a potential input string to the SAML EC name normalization
rules.
GSS-API name attributes may be defined in the future to hold the 5.1.1. Bearer Assertion Session Keys
normalized SAML EC Identifier.
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),
but still wishes to make use of a session key, the client MAY
generate a random value of 128 bits. The 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 client-generated approach described
above.
Applications that rely on this mechanism do so with the understanding
that it is not a secure approach, but merely for compatibility when
the risk is accepted.
5.1.2. Holder of Key Session Keys
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
proves its authenticity, or a formal key agreement algorithm may be
supported. For example, if the server has an elliptic curve public
key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11]
may be used.
If a key agreement or derivation process is not possible, then the
mechanism defined in the previous section can be used, with the added
benefit that the client's request will be strongly authenticated by a
key. However, if channel binding is not used, the generated key
SHOULD be wrapped or transported under the protection of a key
belonging to the server, such as an RSA public key. The <xenc:
EncryptedKey> element and associated key wrap and transport
algorithms (see [XMLENC11]) can be used for this purpose.
Note that this server no purpose in the bearer case, since if channel
binding is not used, an attacker can generate its own key, and if it
is used, there is no MITM to see the key.
5.2. Per-Message Tokens
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
the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
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_CONF_FLAG) security context flags are always set to TRUE.
The 128-bit session "protocol key" SHALL be a session key established
in a manner described in the previous section. "Specific keys" are
then derived as usual as described in Section 2 of [RFC4121],
[RFC3961], and [RFC3962].
The terms "protocol key" and "specific key" are Kerberos V5 terms
[RFC3961].
SAML20EC is PROT_READY as soon as the SAML response message has been
seen.
5.3. Pseudo-Random Function (PRF)
The GSS-API has been extended with a Pseudo-Random Function (PRF)
interface in [RFC4401]. The purpose is to enable applications to
derive a cryptographic key from an established GSS-API security
context. This section defines a GSS_Pseudo_random that is applicable
for the SAML20EC GSS-API mechanism.
The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the
Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor-
asserted sub-session key, thus GSS_C_PRF_KEY_FULL and
GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used
for the GSS_Pseudo_random() SHALL be the same as the key defined in
the previous section.
5.4. GSS-API Principal Name Types for SAML EC
Services that act as SAML relying parties are typically identified by
means of a URI called an "entityID". Clients that are named in the
<Subject> element of a SAML assertion are typically identified by
means of a <NameID> element, which is an extensible XML structure
containing, at minimum, an element value that names the subject and a
Format attribute.
In practice, a GSS-API client and server are unlikely to know the
name of the initiator as it will be expressed by the SAML identity
provider upon completion of authentication. It is also generally
incorrect to assume that a particular acceptor name will directly map
into a particular RP entityID, because there is often a layer of
naming indirection between particular services on hosts and the
identity of a relying party in SAML terms.
The SAML EC mechanism is compatible with the common/expected name
types used for acceptors and initiators, GSS_C_NT_HOSTBASED_SERVICE
and GSS_C_NT_USER_NAME. The mechanism provides for validation of the
host-based service name in conjunction with the SAML exchange. It
does not attempt to solve the problem of mapping between an initiator
"username", the user's identity while authenticating to the identity
provider, and the information supplied 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
The GSS_C_NT_USER_NAME form represents the name of an individual
user. The client relies on this value to determine the appropriate
credentials to use in authenticating to the identity provider, and
supplies it to the server for use by the acceptor.
No SAML-specific mechanism name type is defined. 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]. This information MUST be evaluated
by the mechanism at the server to determine whether to accept the
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 GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
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
applications that use the Kerberos GSS-API mechanism. Such a name is
used directly by this mechanism as the effective
AssertionConsumerService of the server.
This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison
and validation by the client before completing the exchange. The
value MUST be securely associated with the SAML entityID claimed by
the server by the identity provider, such as through the use of SAML
metadata [OASIS.saml-metadata-2.0-os].
6. Example 6. Example
Suppose the user has an identity at the SAML IdP saml.example.org and Suppose the user has an identity at the SAML IdP saml.example.org and
a Jabber Identifier (jid) "somenode@example.com", and wishes to a Jabber Identifier (jid) "somenode@example.com", and wishes to
authenticate his XMPP connection to xmpp.example.com (and example.com authenticate his XMPP connection to xmpp.example.com (and example.com
and example.org have established a SAML-capable trust relationship). and example.org have established a SAML-capable trust relationship).
The authentication on the wire would then look something like the The authentication on the wire would then look something like the
following: following:
skipping to change at page 15, line 13 skipping to change at page 19, line 13
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>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:AuthnRequest <samlp:AuthnRequest
ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z" ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
AssertionConsumerServiceURL="xmpp:xmpp.example.com"> AssertionConsumerServiceURL="xmpp@xmpp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com https://xmpp.example.com
</saml:Issuer> </saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" <samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<samlp:RequestedAuthnContext Comparison="exact"> <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef> <saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef> </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext> </samlp:RequestedAuthnContext>
skipping to change at page 16, line 29 skipping to change at page 20, line 29
<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). encrypted variant in the example).
<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"/>
</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 --> <!-- contents elided -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
skipping to change at page 18, line 17 skipping to change at page 22, line 17
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header> <S:Header>
<paos:Response xmlns:paos="urn:liberty:paos:2003-08" <paos:Response xmlns:paos="urn:liberty:paos:2003-08"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/> S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/>
</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 --> <!-- contents elided -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
skipping to change at page 22, line 7 skipping to change at page 26, line 7
directed, identity. This allows the IdP to manage opaque, pairwise directed, identity. This allows the IdP to manage opaque, pairwise
identifiers for each user that are specific to each RP. However, identifiers for each user that are specific to each RP. However,
correlation is often possible based on other attributes supplied, and correlation is often possible based on other attributes supplied, and
is generally a topic that is beyond the scope of this mechanism. It is generally a topic that is beyond the scope of this mechanism. It
is sufficient to say that this mechanism does not introduce new is sufficient to say that this mechanism does not introduce new
correlation opportunities over and above the use of SAML in web-based correlation opportunities over and above the use of SAML in web-based
use cases. use cases.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to assign a new entry for this GSS mechanism in
the sub-registry for SMI Security for Mechanism Codes, whose prefix
is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
reference this specification in the registry.
The IANA is requested to register the following SASL profile: The IANA is requested to register the following SASL profile:
SASL mechanism profiles: SAML20EC and SAML20EC-PLUS SASL mechanism profiles: SAML20EC and SAML20EC-PLUS
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
algorithm described in this document for 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 24, line 9 skipping to change at page 28, line 9
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[SAMLECP20] [SAMLECP20]
Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile
Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp- Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp-
v2.0-wd04, August 2011. 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]
Hartman, S. and J. Howlett, "Name Attributes for the GSS-
API EAP mechanism", draft-ietf-abfab-gss-eap-naming-03
(work in progress), July 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
Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[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.
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 25, line 7 skipping to change at page 30, line 7
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, and Nico The authors would like to thank Klaas Wierenga, Sam Hartman, Nico
Williams 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 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
Scott Cantor Scott Cantor
Shibboleth Consortium Shibboleth Consortium
 End of changes. 30 change blocks. 
78 lines changed or deleted 284 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/