One document matched: draft-ietf-kitten-sasl-saml-ec-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[ <!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4422 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY RFC4648 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC2616 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2617 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY RFC2234 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2743 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC3920 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY RFC5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5705 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5705.xml">
<!ENTITY RFC5801 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5801.xml">
<!ENTITY RFC6125 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC4462 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4462.xml">
<!ENTITY SAML20 SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml">
<!ENTITY SAML20BIND SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-bindings-2.0-os.xml">
<!ENTITY SAML20META SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-metadata-2.0-os.xml">
<!ENTITY SAML20PROF SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-profiles-2.0-os.xml">
<!ENTITY SOAP SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.W3C.soap11.xml">
<!ENTITY RFC4121 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml">
<!ENTITY RFC3961 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC3962 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3962.xml">
<!ENTITY RFC4401 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4401.xml">
<!ENTITY RFC4402 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4402.xml">
<!ENTITY gss-naming SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-kitten-gssapi-naming-exts.xml">
<!ENTITY eap-naming SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-gss-eap-naming.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc compact="no" ?> <?rfc
sortrefs="yes" ?> <?rfc strict="yes" ?> <?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-ietf-kitten-sasl-saml-ec-03.txt"
category="std">
<front>
<title abbrev="SAML ECP SASL & GSS-API Mechanisms">
SAML Enhanced Client SASL and GSS-API Mechanisms
</title>
<author fullname="Scott Cantor" initials="S." surname="Cantor">
<organization>Shibboleth Consortium</organization>
<address>
<postal>
<street>2740 Airport Drive</street>
<city>Columbus</city>
<code>43219</code>
<region>Ohio</region>
<country>United States</country>
</postal>
<phone>+1 614 247 6147</phone>
<email>cantor.2@osu.edu</email>
</address>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<postal>
<street>Hagagatan 24</street>
<city>Stockholm</city>
<code>113 47</code>
<country>SE</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<date year="2012"/>
<abstract>
<t>
Security Assertion Markup Language (SAML) 2.0 is a generalized
framework for the exchange of security-related information between
asserting and relying parties. Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks to facilitate an
extensible authentication model. This document specifies a SASL and
GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
SAML-aware "enhanced client" to address significant barriers to
federated authentication in a manner that encourages reuse of
existing SAML bindings and profiles designed for non-browser
scenarios.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="OASIS.saml-core-2.0-os">Security Assertion Markup
Language (SAML) 2.0</xref> is a modular specification that provides
various means for a user to be identified to a relying party (RP)
through the exchange of (typically signed) assertions issued by an
identity provider (IdP). It includes a number of protocols,
protocol <xref target="OASIS.saml-bindings-2.0-os">bindings</xref>,
and <xref target="OASIS.saml-profiles-2.0-os">interoperability profiles</xref>
designed for different use cases. Additional profiles and extensions
are also routinely developed and published.
</t>
<t>
<xref target="RFC4422">Simple Authentication and Security Layer
(SASL)</xref> is a generalized mechanism for identifying and
authenticating a user and for optionally negotiating a security layer
for subsequent protocol interactions. SASL is used by application
protocols like IMAP, POP and <xref target="RFC3920">XMPP</xref>. The
effect is to make authentication modular, so that newer authentication
mechanisms can be added as needed.
</t>
<t>
The <xref target="RFC2743">Generic Security Service Application
Program Interface (GSS-API)</xref> provides a framework for
applications to support multiple authentication mechanisms through a
unified programming interface. This document defines a pure SASL
mechanism for SAML, but it conforms to the bridge between SASL and
the GSS-API called <xref target="RFC5801">GS2</xref>. This means that
this document defines both a SASL mechanism and a GSS-API mechanism.
The GSS-API interface is optional for SASL implementers, and the
GSS-API considerations can be avoided in environments that uses
SASL directly without GSS-API.
</t>
<t>The mechanisms specified in this document allow a SASL- or
GSS-API-enabled server to act as a SAML relying party, or service
provider (SP), by advertising this mechanism as an option for SASL
or GSS-API clients that support the use of SAML to communicate
identity and attribute information. Clients supporting this mechanism
are termed "enhanced clients" in SAML terminology because they understand
the federated authentication model and have specific knowledge of the IdP(s)
associated with the user. This knowledge, and the ability to act on
it, addresses a significant problem with browser-based SAML profiles
known as the "discovery", or "where are you from?" (WAYF)
problem. Obviating the need for the RP to interact with the client to
determine the right IdP (and its network location) is both a user
interface and security improvement.
</t>
<t>The SAML mechanism described in this document is an adaptation of an
existing SAML profile, the <xref target="SAMLECP20">Enhanced Client or
Proxy (ECP) Profile (V2.0)</xref>, and therefore does not establish
a separate authentication, integrity and confidentiality mechanism.
It is anticipated that existing security layers, such as Transport Layer
Security (TLS) or Secure Shell (SSH), will continued to be used.</t>
<t><xref target="overview"/> describes the interworking between SAML and
SASL: this document requires enhancements to the RP and to the client (as
the two SASL communication endpoints) but no changes to the SAML IdP are
assumed apart from its support for the applicable SAML profile. To accomplish
this, a SAML protocol exchange between the RP and the IdP, brokered by the
client, is tunneled within SASL. There is no assumed communication between
the RP and the IdP, but such communication may occur in conjunction with
additional SAML-related profiles not in scope for this document.</t>
<t> <figure anchor="overview" title="Interworking
Architecture"> <artwork><![CDATA[
+-----------+
| SAML |
| Relying |
| Party |
| |
+-----------+
^
+--|--+
| S| |
S | A| |
A | M| |
S | L| |
L | | |
| | |
+--|--+
+------------+ v
| | +----------+
| SAML | SAML SOAP | |
| Identity |<--------------->| Client |
| Provider | Binding | |
+------------+ +----------+
]]></artwork> </figure> </t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 <xref target="RFC2119"/>.</t>
<t>The reader is also assumed to be familiar with the terms used in the SAML
2.0 specification, and an understanding of the
<xref target="SAMLECP20">Enhanced Client or Proxy (ECP) Profile (V2.0)</xref>
is necessary, as part of this mechanism explicitly reuses and references it.</t>
<t>This document can be implemented without knowledge of GSS-API since
the normative aspects of the GS2 protocol syntax have been duplicated
in this document. The document may also be implemented to provide a
GSS-API mechanism, and then knowledge of GSS-API is essential. To
faciliate these two variants, the references has been split into two
parts, one part that provides normative references for all readers,
and one part that adds additional normative references required for
implementers that wish to implement the GSS-API portion.</t>
</section>
<section title="Applicability for Non-HTTP Use Cases">
<t>While SAML is designed to support a variety of application scenarios,
the profiles for authentication defined in the original standard are
designed around <xref target="RFC2616">HTTP</xref> applications.
They are not, however, limited to browsers, because it was recognized
that browsers suffer from a variety of functional and security deficiencies
that would be useful to avoid where possible. Specifically, the notion of an
"Enhanced Client" (or a proxy acting as one on behalf of a browser, thus the
term "ECP") was specified for a software component that acts somewhat like a
browser from an application perspective, but includes limited, but sufficient,
awareness of SAML to play a more conscious role in the authentication exchange
between the RP and the IdP. What follows is an outline of the
<xref target="SAMLECP20">Enhanced Client or Proxy (ECP) Profile (V2.0)</xref>,
as applied to the web/HTTP service use case:</t>
<t>
<list style="numbers">
<t>The Enhanced Client requests a resource of a Relying Party (RP) (via an HTTP request).
In doing so, it advertises its "enhanced" capability using HTTP headers.</t>
<t>The RP, desiring SAML authentication and noting the client's capabilities,
responds not with an HTTP redirect or form, but with a
<xref target="W3C.soap11">SOAP</xref> envelope containing a SAML <AuthnRequest>
along with some supporting headers. This request identifies the RP (and may be signed),
and may provide hints to the client as to what IdPs the RP finds acceptable, but the
choice of IdP is generally left to the client.</t>
<t>The client is then responsible for delivering the body of the SOAP message
to the IdP it is instructed to use (often via configuration ahead of time).
The user authenticates to the IdP ahead of, during, or after the delivery of this
message, and perhaps explicitly authorizes the response to the RP.</t>
<t>Whether authentication succeeds or fails, the IdP responds with its own
SOAP envelope, generally containing a SAML <Response> message for delivery
to the RP. In a successful case, the message will include a SAML <Assertion>
containing authentication, and possibly attribute, information about the user.
Either the response or assertion alone is signed, and the assertion may be encrypted to
a key negotiated with or known to belong to the RP.</t>
<t>The client then delivers the SOAP envelope containing the <Response> to the
RP at a location the IdP directs (which acts as an additional, though limited, defense
against MITM attacks). This completes the SAML exchange.</t>
<t>The RP now has sufficient identity information to approve the original HTTP request
or not, and acts accordingly. Everything between the original request and this
response can be thought of as an "interruption" of the original HTTP exchange.</t>
</list>
</t>
<t>When considering this flow in the context of an arbitrary
application protocol and SASL, the RP and the client both must change
their code to implement this SASL mechanism, but the IdP can remain
untouched. The existing RP/client exchange that is tunneled through
HTTP maps well to the tunneling of that same exchange in SASL. In
the parlance of <xref target="RFC4422">SASL</xref>, this mechanism is
"client-first" for consistency with GS2. The steps are shown below:</t>
<t>
<list style="numbers">
<t>The server MAY advertise the SAML20EC and/or SAML20EC-PLUS mechanisms.</t>
<t>The client initiates a SASL authentication with SAML20EC or SAML20EC-PLUS.</t>
<t>The server sends the client a challenge consisting of a SOAP envelope containing
its SAML <AuthnRequest>.</t>
<t>The SASL client unpacks the SOAP message and communicates with its chosen IdP
to relay the SAML <AuthnRequest> to it. This communication, and the
authentication with the IdP, proceeds separately from the SASL process.</t>
<t>Upon completion of the exchange with the IdP, the client responds
to the SASL server with a SOAP envelope containing the SAML
<Response> it obtained, or a SOAP fault, as warranted.</t>
<t> The SASL Server indicates success or failure.</t>
</list>
</t>
<t>Note: The details of the SAML processing, which are consistent with the
<xref target="SAMLECP20">Enhanced Client or Proxy (ECP) Profile (V2.0)</xref>,
are such that the client MUST interact with the IdP in order to complete any
SASL exchange with the RP. The assertions issued by the IdP for the purposes of
the profile, and by extension this SASL mechanism, are short lived, and therefore
cannot be cached by the client for later use.</t>
<t>
Encompassed in step four is the client-driven selection of the IdP,
authentication to it, and the acquisition of a response to provide
to the SASL server. These processes are all external to SASL.</t>
<t> With all of this in mind, the typical flow appears as follows:</t>
<t>
<figure anchor="flow" title="Authentication flow">
<artwork><![CDATA[
SASL Serv. Client IdP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|>-----(3)----->| | SASL Server Response
| | |
| |<- - -(4)- - >| SOAP AuthnRequest + user authn
| | |
|<-----(5)-----<| | SASL Client Response
| | |
|>-----(6)----->| | Server sends Outcome
| | |
----- = SASL
- - - = SOAP over HTTPS (external to SASL)
]]>
</artwork>
</figure></t>
</section>
<section title="SAML SASL Mechanism Specification"> <t>Based on the
previous figures, the following operations are defined by the SAML
SASL mechanism:</t>
<section title="Advertisement" anchor="advertisement"> <t>To advertise
that a server supports this mechanism, during application session initiation,
it displays the name "SAML20EC" and/or "SAML20EC-PLUS"
in the list of supported SASL mechanisms (depending on its support for
channel binding).</t>
</section>
<section title="Initiation" anchor="initiation">
<t>A client initiates "SAML20EC" or "SAML20EC-PLUS"
authentication. If supported by the application protocol, the client
MAY include an initial response, otherwise it waits until the server
has issued an empty challenge (because the mechanism is client-first).</t>
<t>The format of the initial client response is as follows:</t>
<figure>
<artwork>
hok = "urn:oasis:names:tc:SAML:2.0:cm: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]
</artwork>
</figure>
<t>The gs2-cb-flag MUST be set as defined in <xref target="RFC5801"/>
to indicate whether the client supports channel binding. This takes
the place of the PAOS HTTP header extension used in <xref target="SAMLECP20"/>
to indicate channel binding support.</t>
<t>The optional "gs2-authzid" field holds the authorization identity,
as requested by the client.</t>
<t>The optional "hok" field is a constant that signals the
client's support for stronger security by means of a locally held
key. This takes the place of the PAOS HTTP header extension used in
<xref target="SAMLECP20"/> to indicate "holder of key" support.</t>
<t>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.</t>
</section>
<section title="Server Response" anchor="serverresponse">
<t>The SASL server responds with a SOAP envelope constructed in
accordance with section 2.3.2 of <xref target="SAMLECP20"/>. This
includes adhering to the SOAP header requirements of the
<xref target="OASIS.saml-bindings-2.0-os">SAML PAOS Binding</xref>,
for compatibility with the existing profile. Various SOAP headers
are also consumed by the client in exactly the same manner prescribed
by that section.</t>
</section>
<section title="User Authentication with Identity Provider" anchor="userauthn">
<t>Upon receipt of the <xref target="serverresponse">Server
Response</xref>, the steps described in sections 2.3.3 through
2.3.6 of <xref target="SAMLECP20"/> are performed between the client
and the chosen IdP. The means by which the client determines the IdP
to use, and where it is located, are out of scope of this mechanism.</t>
<t>The exact means of authentication to the IdP are
also out of scope, but clients supporting this mechanism MUST support
HTTP Basic Authentication as defined in <xref target="RFC2617"/> and
TLS client authentication as defined in <xref target="RFC5246"/>.</t>
</section>
<section title="Client Response" anchor="clientresponse">
<t>Assuming a response is obtained from the IdP, the client responds
to the SASL server with a SOAP envelope constructed in accordance with
section 2.3.7 of <xref target="SAMLECP20"/>. This includes adhering to
the SOAP header requirements of the <xref target="OASIS.saml-bindings-2.0-os">SAML
PAOS Binding</xref>, for compatibility with the existing profile. If the
client is unable to obtain a response from the IdP, it responds to the
SASL server with a SOAP envelope containing a SOAP fault.</t>
</section>
<section title="Outcome" anchor="outcome">
<t>The SAML protocol exchange having completed, the SASL server will
transmit the outcome to the client depending on local validation of
the client responses. This outcome is transmitted in accordance with
the application protocol in use.</t>
</section>
<section title="Additional Notes" anchor="notes">
<t>Because this mechanism is an adaptation of an HTTP-based profile,
there are a few requirements outlined in <xref target="SAMLECP20"/>
that make reference to a response URL that is normally used to regulate
where the client returns information to the RP. There are also
security-related checks built into the profile that involve this location.</t>
<t>For compatibility with existing IdP and profile behavior, and to provide
for mutual authentication, the SASL server MUST populate the
responseConsumerURL and AssertionConsumerServiceURL attributes
with its service name. The parties then perform the steps described in
<xref target="SAMLECP20"/> as usual.</t>
<t>Similarly, the use of HTTP status signaling between the RP and client
mandated by <xref target="SAMLECP20"/> may not be applicable.</t>
</section>
</section>
<section title="SAML EC GSS-API Mechanism Specification">
<t>This section and its sub-sections and all normative references of
it not referenced elsewhere in this document are INFORMATIONAL for
SASL implementors, but they are NORMATIVE for GSS-API
implementors.</t>
<t>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 first message is excluded when SAML EC is used as a
GSS-API mechanism, and b) the RFC2743 section 3.1 initial
context token header is prefixed to the client's first
authentication message (context token).</t>
<t>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.</t>
<t>The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to
TRUE, resulting in the "mutual-auth" option set in the initial
client response. The security context mutual_state flag is set
to TRUE only if the server digitally signs its SAML <AuthnRequest>
message, and the identity provider signals this to the client
in an <ecp:RequestAuthenticated> SOAP header block.</t>
<t>If the mutual_state flag is not requested, or is not set, then the
security layer managed by the application outside of the GSS-API
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 <xref target="RFC6125"/>. For SSH, this matching MUST be
performed as discussed in <xref target="RFC4462"/>.</t>
<t>The lifetime of a security context established with this
mechanism SHOULD be limited by the value of a SessionNotOnOrAfter
attribute, if any, in the <AuthnStatement> of the SAML assertion
received by the RP.</t>
<t>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.</t>
<section title="Session Key Derivation">
<t>Some GSS-API features (discussed in the following sections) require
a session key be established as a result security context establishment.
In the common case of a "bearer" assertion in SAML, there is no secure
mechanism by which such a key can be established other than by exporting
key material from TLS (discussed below). In other cases such as assertions
based on "holder of key" confirmation, there may be additional methods
available.</t>
<t>Information defining or describing the session key, or a process for
deriving one, is communicated by the client to the server using an
<ecp:SessionKey> SOAP header block, as defined in <xref target="SAMLECP20"/>.
This header contains a <ds:KeyInfo> element as a generic container,
and is designed to support reuse of mechanisms defined by <xref target="XMLENC11"/>
or other specifications.</t>
<section title="TLS-Exported Session Keys">
<t>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
<xref target="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:</t>
<figure><artwork>
<![CDATA[
<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>
]]>
</artwork></figure>
<t>The derivation algorithm of TBD (IANA to assign: see IANA considerations)
signifies the TLS-Exported approach described above.</t>
</section>
<section title="Bearer Assertion Session Keys">
<t>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) and cannot use a TLS-exported key, but still wishes to make
use of a session key, the client MAY generate a pseudorandom value
of 128 bits to use as a key. The octets are then base64-encoded and
placed in a <CipherData> element inside a <ecp:SessionKey>
SOAP header block in the following manner:</t>
<figure><artwork>
<![CDATA[
<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>
]]>
</artwork></figure>
<t>The derivation algorithm of TBD (IANA to assign: see IANA considerations)
signifies the client-generated approach described above.</t>
<t>Applications that rely on this mechanism do so with the understanding
that it is not a secure approach, but merely for compatibility if the risk
is acceptable.</t>
</section>
<section title="Holder of Key Session Keys">
<t>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
<xref target="XMLENC11"/> may be used.</t>
<t>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 <xref target="XMLENC11"/>)
can be used for this purpose.</t>
<t>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 is used, there is no MITM to see the key.</t>
</section>
</section>
<section title="Per-Message Tokens">
<t>The per-message tokens SHALL be the same as those for the Kerberos
V GSS-API mechanism <xref target="RFC4121"/> (see Section 4.2 and
sub-sections), using the Kerberos V "aes128-cts-hmac-sha1-96" enctype
<xref target="RFC3962"/>.</t>
<t>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.</t>
<t>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 <xref target="RFC4121"/>, <xref target="RFC3961"/>, and
<xref target="RFC3962"/>.</t>
<t>The terms "protocol key" and "specific key" are Kerberos V5 terms
<xref target="RFC3961"/>.</t>
<t>SAML20EC is PROT_READY as soon as the SAML response message has
been seen.</t>
</section>
<section title="Pseudo-Random Function (PRF)">
<t>The GSS-API has been extended with a Pseudo-Random Function (PRF)
interface in <xref target="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.</t>
<t>The GSS_Pseudo_random() <xref target="RFC4401"/> SHALL be the same
as for the Kerberos V GSS-API mechanism <xref target="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.</t>
</section>
<section title="GSS-API Principal Name Types for SAML EC">
<t>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.</t>
<t>In practice, a GSS-API client and server are unlikely to know in
advance 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.</t>
<t>To avoid complexity, and avoid unnecessary use of XML within the
naming layer, the SAML EC mechanism relies on 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.</t>
<t>SAML-based information associated with the initiator SHOULD be
expressed to the acceptor using <xref target="I-D.ietf-kitten-gssapi-naming-exts">GSS-API
naming extensions</xref>, in accordance with
<xref target="I-D.ietf-abfab-gss-eap-naming"/>.</t>
<section title="User Naming Considerations">
<t>The GSS_C_NT_USER_NAME form represents the name of an individual
user. Clients often rely on this value to determine the appropriate
credentials to use in authenticating to the identity provider, and
supply it to the server for use by the acceptor.</t>
<t>Upon successful completion of this mechanism, the server MUST
construct the authenticated initiator name based on the
<saml:NameID> element in the assertion it successfully
validated. The name is constructed as a UTF-8 string in the
following form:</t>
<figure>
<artwork>
name = element-value "!" Format "!" NameQualifier
"!" SPNameQualifier "!" SPProvidedID
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Service Naming Considerations">
<t>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.</t>
<t>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
<xref target="OASIS.saml-metadata-2.0-os">SAML metadata</xref>.</t>
</section>
</section>
</section>
<section title="Example">
<t>Suppose the user has an identity at the SAML IdP saml.example.org
and a Jabber Identifier (jid) "somenode@example.com", and wishes to
authenticate his XMPP connection to xmpp.example.com (and example.com
and example.org have established a SAML-capable trust relationship).
The authentication on the wire would then look something like the
following:</t>
<t>Step 1: Client initiates stream to server:</t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 2: Server responds with a stream tag sent to client:</t>
<figure><artwork>
<![CDATA[
<stream:stream
xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
id='some_id' from='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 3: Server informs client of available authentication
mechanisms:</t>
<figure><artwork>
<![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>SAML20EC</mechanism>
</mechanisms>
</stream:features>
]]>
</artwork></figure>
<t>Step 4: Client selects an authentication mechanism and sends the
initial client response (it is base64 encoded as specified by the XMPP
SASL protocol profile):</t>
<figure><artwork>
<![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'>
biwsLA==
</auth>
]]>
</artwork></figure>
<t>The initial response is "n,," which signals that channel binding
is not used, there is no authorization identity, and the client does
not support key-based confirmation or want mutual authentication.</t>
<t>Step 5: Server sends a challenge to client in the form of a SOAP
envelope containing its SAML <AuthnRequest>:</t>
<figure><artwork>
<![CDATA[
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy
LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v
cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4
bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9
ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0
cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u
c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj
ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg
ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB
TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h
cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k
PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft
bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8
L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB
dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1
ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n
PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz
c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N
CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg
ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl
YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu
MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB
dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u
dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj
bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu
Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+
IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w
ZT4NCg==
</challenge>
]]>
</artwork></figure>
<t>The <xref target="RFC4648">Base64</xref> decoded envelope:</t>
<figure><artwork>
<![CDATA[
<S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<paos:Request xmlns:paos="urn:liberty:paos:2003-08"
messageID="c3a4f8b9c2d" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"
responseConsumerURL="xmpp@xmpp.example.com"
service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"/>
<ecp:Request
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"
S:mustUnderstand="1" ProviderName="Jabber at example.com">
<saml:Issuer>https://xmpp.example.com</saml:Issuer>
</ecp:Request>
</S:Header>
<S:Body>
<samlp:AuthnRequest
ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
AssertionConsumerServiceURL="xmpp@xmpp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com
</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
</S:Body>
</S:Envelope>
]]>
</artwork></figure>
<t>Step 5 (alt): Server returns error to client:</t>
<figure> <artwork>
<![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
]]>
</artwork></figure>
<t>Step 6: Client relays the request to IdP in a SOAP message
transmitted over HTTP (over TLS). HTTP portion not shown, use of
Basic Authentication is assumed. The body of the SOAP envelope is
exactly the same as received in the previous step.</t>
<figure><artwork>
<![CDATA[
<S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<samlp:AuthnRequest>
<!-- same as above -->
</samlp:AuthnRequest>
</S:Body>
</S:Envelope>
]]>
</artwork></figure>
<t>Step 7: IdP responds to client with a SOAP response
containing a SAML <Response> containing a short-lived SSO
assertion (shown as an encrypted variant in the example).</t>
<figure><artwork>
<![CDATA[
<S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<ecp:Response S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"/>
</S:Header>
<S:Body>
<samlp:Response ID="d43h94r389309r" Version="2.0"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
Destination="xmpp@xmpp.example.com">
<saml:Issuer>https://saml.example.org</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:EncryptedAssertion>
<!-- contents elided -->
</saml:EncryptedAssertion>
</samlp:Response>
</S:Body>
</S:Envelope>
]]>
</artwork></figure>
<t>Step 8: Client sends SOAP envelope containing the SAML
<Response> as a response to the SASL server's challenge:</t>
<figure><artwork>
<![CDATA[
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy
LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN
TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v
cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug
eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i
aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt
dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8
L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0
cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy
LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz
dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1
ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s
cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1
ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg
ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg
ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk
QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu
dmVsb3BlPg0K
</response>
]]>
</artwork></figure>
<t>The <xref target="RFC4648">Base64</xref> decoded envelope:</t>
<figure><artwork>
<![CDATA[
<S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<paos:Response xmlns:paos="urn:liberty:paos:2003-08"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"
S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/>
</S:Header>
<S:Body>
<samlp:Response ID="d43h94r389309r" Version="2.0"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
Destination="xmpp@xmpp.example.com">
<saml:Issuer>https://saml.example.org</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:EncryptedAssertion>
<!-- contents elided -->
</saml:EncryptedAssertion>
</samlp:Response>
</S:Body>
</S:Envelope>
]]>
</artwork></figure>
<t>Step 9: Server informs client of successful authentication:</t>
<figure><artwork>
<![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]>
</artwork></figure>
<t>Step 9 (alt): Server informs client of failed authentication:</t>
<figure><artwork>
<![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
]]>
</artwork></figure>
<t>Step 10: Client initiates a new stream to server:</t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 11: Server responds by sending a stream header to client along
with any additional features (or an empty features element):</t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345' from='example.com' version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
]]>
</artwork></figure>
<t>Step 12: Client binds a resource:</t>
<figure><artwork>
<![CDATA[
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
]]>
</artwork></figure>
<t>Step 13: Server informs client of successful resource binding:</t>
<figure><artwork>
<![CDATA[
<iq type='result' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
]]>
</artwork></figure>
<t>Please note: line breaks were added to the base64 for clarity.</t>
</section>
<section title="Security Considerations">
<t>
This section will address only security considerations associated
with the use of SAML with SASL applications. For considerations
relating to SAML in general, the reader is referred to the SAML
specification and to other literature. Similarly, for general SASL
Security Considerations, the reader is referred to that specification.
</t>
<t>
Version 2.0 of the <xref target="SAMLECP20">Enhanced Client or Proxy
Profile</xref> adds optional support for channel binding and use of
"Holder of Key" subject confirmation. The former is strongly recommended
for use with this mechanism to detect "Man in the Middle" attacks
between the client and the RP without relying on flawed commercial
TLS infrastructure. The latter may be impractical in many cases,
but is a valuable way of strengthening client authentication,
protecting against phishing, and improving the overall mechanism.
</t>
<section title="Risks Left Unaddressed">
<t>
The adaptation of a web-based profile that is largely designed
around security-oblivious clients and a bearer model for security
token validation results in a number of basic security exposures
that should be weighed against the compatibility and client
simplification benefits of this mechanism.
</t>
<t>
When channel binding is not used, protection against "Man in the
Middle" attacks is left to lower layer protocols such as TLS, and
the development of user interfaces able to implement that has not
been effectively demonstrated. Failure to detect a MITM can result
in phishing of the user's credentials if the attacker is between
the client and IdP, or the theft and misuse of a short-lived credential
(the SAML assertion) if the attacker is able to impersonate a RP.
SAML allows for source address checking as a minor mitigation to the
latter threat, but this is often impractical. IdPs can mitigate to
some extent the exposure of personal information to RP attackers
by encrypting assertions with authenticated keys.
</t>
</section>
<section title="User Privacy">
<t>
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
requirement to track the activity, but there is nothing technically
that prohibits the collection of this information. SASL servers should
be aware that SAML IdPs will track - to some extent - user access to
their services.
</t>
<t>
It is also out of scope of the mechanism to determine under what
conditions an IdP will release particular information to a relying
party, and it is generally unclear in what fashion user consent
could be established in real time for the release of particular
information. The SOAP exchange with the IdP does not preclude such
interaction, but neither does it define that interoperably.
</t>
</section>
<section title="Collusion between RPs">
<t>
Depending on the information supplied by the IdP, it may be possible
for RPs to correlate data that they have collected. By using the same
identifier to log into every RP, collusion between RPs is possible.
SAML supports the notion of pairwise, or targeted/directed, identity.
This allows the IdP to manage opaque, pairwise identifiers for each user
that are specific to each RP. However, correlation is often possible
based on other attributes supplied, and is generally a topic that is
beyond the scope of this mechanism. It is sufficient to say that this
mechanism does not introduce new correlation opportunities over and
above the use of SAML in web-based use cases.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>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.</t>
<t>The IANA is requested to register the following SASL profile:</t>
<t/>
<t>SASL mechanism profiles: SAML20EC and SAML20EC-PLUS</t>
<t>Security Considerations: See this document</t>
<t>Published Specification: See this document</t>
<t>For further information: Contact the authors of this document.</t>
<t>Owner/Change controller: the IETF</t>
<t>Note: None</t>
<t>The IANA is requested to assign a new entry of "EXPORTER_SAML20EC"
in the TLS Parameters Exporter Label Registry.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2617;
&RFC4422;
&RFC4462;
&RFC4648;
&RFC5246;
&RFC6125;
&SAML20;
&SAML20BIND;
&SAML20PROF;
&SOAP;
<reference anchor="SAMLECP20">
<front>
<title>SAML V2.0 Enhanced Client or Proxy Profile Version 2.0</title>
<author initials="S." surname="Cantor" fullname="Scott Cantor">
<organization>Internet2</organization>
</author>
<date month="July" year="2012" />
</front>
<seriesInfo name="OASIS Working Draft" value="OASIS.sstc-saml-ecp-v2.0-wd05" />
<format type="PDF" target="http://www.oasis-open.org/committees/download.php/46524/sstc-saml-ecp-v2.0-wd05.pdf"/>
</reference>
</references>
<references title="Normative References for GSS-API Implementers">
&RFC2743;
&RFC3961;
&RFC3962;
&RFC4121;
&RFC4401;
&RFC4402;
&RFC5705;
&RFC5801;
&gss-naming;
&eap-naming;
<reference anchor="XMLENC11">
<front>
<title>XML Encryption Syntax and Processing Version 1.1</title>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization>Nokia</organization>
</author>
<author initials="T." surname="Roessler" fullname="Thomas Roessler">
<organization>W3C</organization>
</author>
<date month="August" year="2012" />
</front>
<seriesInfo name="W3C Editor's Draft" value="W3C.xmlenc-core-11-ed" />
<format type="HTML" target="http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html"/>
</reference>
</references>
<references title="Informative References">
&RFC2616;
&RFC3920;
&SAML20META;
</references>
<section title="Acknowledgments">
<t>
The authors would like to thank Klaas Wierenga, Sam Hartman,
Nico Williams, and Jim Basney for their contributions.
</t>
</section>
<section title="Changes"> <t>This section to be removed
prior to publication.</t> <t> <list style="symbols">
<t>03, added TLS key export as a session key option, revised GSS naming
material based on list discussion</t>
<t>02, major revision of GSS-API material and updated references</t>
<t>01, SSH language added, noted non-assumption of HTTP error handling,
added guidance on life of security context.</t>
<t>00, Initial Revision, first WG-adopted draft.
Removed support for unsolicited SAML responses.</t>
</list> </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:10 |