doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc6595.txt b/doc/rfc/rfc6595.txt
new file mode 100644
index 0000000..f8fedf7
--- /dev/null
+++ b/doc/rfc/rfc6595.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       K. Wierenga
+Request for Comments: 6595                           Cisco Systems, Inc.
+Category: Standards Track                                        E. Lear
+ISSN: 2070-1721                                       Cisco Systems GmbH
+                                                            S. Josefsson
+                                                                  SJD AB
+                                                              April 2012
+
+
+A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism
+           for the Security Assertion Markup Language (SAML)
+
+Abstract
+
+   The Security Assertion Markup Language (SAML) has found its usage on
+   the Internet for Web Single Sign-On.  The Simple Authentication and
+   Security Layer (SASL) and the Generic Security Service Application
+   Program Interface (GSS-API) are application frameworks to generalize
+   authentication.  This memo specifies a SASL mechanism and a GSS-API
+   mechanism for SAML 2.0 that allows the integration of existing SAML
+   Identity Providers with applications using SASL and GSS-API.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6595.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 1]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+      1.2. Applicability ..............................................4
+   2. Authentication Flow .............................................5
+   3. SAML SASL Mechanism Specification ...............................7
+      3.1. Initial Response ...........................................8
+      3.2. Authentication Request .....................................8
+      3.3. Outcome and Parameters .....................................9
+   4. SAML GSS-API Mechanism Specification ...........................10
+      4.1. GSS-API Principal Name Types for SAML .....................11
+   5. Examples .......................................................11
+      5.1. XMPP ......................................................11
+      5.2. IMAP ......................................................15
+   6. Security Considerations ........................................17
+      6.1. Man-in-the-Middle and Tunneling Attacks ...................17
+      6.2. Binding SAML Subject Identifiers to Authorization
+           Identities ................................................17
+      6.3. User Privacy ..............................................18
+      6.4. Collusion between RPs .....................................18
+      6.5. Security Considerations Specific to GSS-API ...............18
+   7. IANA Considerations ............................................18
+      7.1. IANA Mech-Profile .........................................18
+      7.2. IANA OID ..................................................19
+   8. References .....................................................19
+      8.1. Normative References ......................................19
+      8.2. Informative References ....................................21
+   Appendix A. Acknowledgments .......................................22
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 2]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+1.  Introduction
+
+   Security Assertion Markup Language (SAML) 2.0 [OASIS-SAMLv2-CORE] is
+   a set of specifications that provide 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 bindings [OASIS-SAMLv2-BIND], and
+   interoperability profiles [OASIS-SAMLv2-PROF] designed for different
+   use cases.
+
+   The Simple Authentication and Security Layer (SASL) [RFC4422] 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
+   [RFC3501], the Post Office Protocol (POP) [RFC1939], and the
+   Extensible Message and Presence Protocol (XMPP) [RFC6120].  The
+   effect is to make modular authentication, so that newer
+   authentication mechanisms can be added as needed.  This memo
+   specifies just such a mechanism.
+
+   The Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743] 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 new bridge between SASL and the GSS-API called GS2 [RFC5801].
+   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 use SASL directly without GSS-API.
+
+   As currently envisioned, this mechanism enables interworking between
+   SASL and SAML in order to assert the identity of the user and other
+   attributes to RPs.  As such, while servers (as RPs) will advertise
+   SASL mechanisms (including SAML), clients will select the SAML SASL
+   mechanism as their SASL mechanism of choice.
+
+   The SAML mechanism described in this memo aims to reuse the Web
+   Browser Single Sign-On (SSO) profile defined in Section 4.1 of the
+   SAML 2.0 profiles specification [OASIS-SAMLv2-PROF] to the maximum
+   extent and therefore does not establish a separate authentication,
+   integrity, and confidentiality mechanism.  The mechanism assumes that
+   a security layer, such as Transport Layer Security (TLS) [RFC5246],
+   will continue to be used.  This specification is appropriate for use
+   when a browser instance is available.  In the absence of a browser
+   instance, SAML profiles that don't require a browser, such as the
+   Enhanced Client or Proxy profile (as defined in Section 4.2 of
+   [OASIS-SAMLv2-PROF], may be used, but that is outside the scope of
+   this specification.
+
+
+
+Wierenga, et al.             Standards Track                    [Page 3]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Figure 1 describes the interworking between SAML and SASL: this
+   document requires enhancements to the RP (the SASL server) and to the
+   client, as the two SASL communication end points, but no changes to
+   the SAML IdP are necessary.  To accomplish this goal, some indirect
+   messaging is tunneled within SASL, and some use of external methods
+   is made.
+
+                                       +-----------+
+                                       |           |
+                                      >|  Relying  |
+                                     / |  Party    |
+                                   //  |           |
+                                 //    +-----------+
+                      SAML/    //            ^
+                      HTTPS  //           +--|--+
+                           //             | S|  |
+                          /             S | A|  |
+                        //              A | M|  |
+                      //                S | L|  |
+                    //                  L |  |  |
+                  //                      |  |  |
+                </                        +--|--+
+         +------------+                      v
+         |            |                 +----------+
+         |  SAML      |     HTTPS       |          |
+         |  Identity  |<--------------->|  Client  |
+         |  Provider  |                 |          |
+         +------------+                 +----------+
+
+                    Figure 1: Interworking Architecture
+
+1.1.  Terminology
+
+   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 [RFC2119].
+
+   The reader is assumed to be familiar with the terms used in the
+   SAML 2.0 core specification [OASIS-SAMLv2-CORE].
+
+1.2.  Applicability
+
+   Because this mechanism transports information that should not be
+   controlled by an attacker, the SAML mechanism MUST only be used over
+   channels protected by TLS, or over similar integrity-protected and
+   authenticated channels.  In addition, when TLS is used, the client
+   MUST successfully validate the server's certificate ([RFC5280],
+   [RFC6125]).
+
+
+
+Wierenga, et al.             Standards Track                    [Page 4]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Note: An Intranet does not constitute such an integrity-protected and
+   authenticated channel!
+
+2.  Authentication Flow
+
+   While SAML itself is merely a markup language, its common use case
+   these days is with HTTP [RFC2616] or HTTPS [RFC2818] and HTML
+   [W3C-REC-HTML401].  What follows is a typical flow:
+
+   1.  The browser requests a resource of an RP (via an HTTP request).
+
+   2.  The RP redirects the browser via an HTTP redirect (as described
+       in Section 10.3 of [RFC2616]) to the IdP or an IdP discovery
+       service.  When it does so, it includes the following parameters:
+       (1) an authentication request that contains the name of the
+       resource being requested, (2) a browser cookie, and (3) a return
+       URL as specified in Section 3.1 of [OASIS-SAMLv2-PROF].
+
+   3.  The user authenticates to the IdP and perhaps authorizes the
+       release of user attributes to the RP.
+
+   4.  In its authentication response, the IdP redirects (via an HTTP
+       redirect) the browser back to the RP with an authentication
+       assertion (stating that the IdP vouches that the subject has
+       successfully authenticated), optionally along with some
+       additional attributes.
+
+   5.  The RP now has sufficient identity information to approve access
+       to the resource or not, and acts accordingly.  The authentication
+       is concluded.
+
+   When considering this flow in the context of SASL, we note that while
+   the RP and the client both must change their code to implement this
+   SASL mechanism, the IdP can remain untouched.  The RP already has
+   some sort of session (probably a TCP connection) established with the
+   client.  However, it may be necessary to redirect a SASL client to
+   another application or handler.  The steps are as follows:
+
+   1.  The SASL server (RP) advertises support for the SASL SAML20
+       mechanism to the client.
+
+   2.  The client initiates a SASL authentication with SAML20 and sends
+       a domain name that allows the SASL server to determine the
+       appropriate IdP.
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 5]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   3.  The SASL server transmits an authentication request encoded using
+       a Uniform Resource Identifier (URI) as described in RFC 3986
+       [RFC3986] and an HTTP redirect to the IdP corresponding to the
+       domain.
+
+   4.  The SASL client now sends a response consisting of "=".
+       Authentication continues via the normal SAML flow, and the SASL
+       server will receive the answer to the challenge out of band from
+       the SASL conversation.
+
+   5.  At this point, the SASL client MUST construct a URL containing
+       the content received in the previous message from the SASL
+       server.  This URL is transmitted to the IdP either by the SASL
+       client application or an appropriate handler, such as a browser.
+
+   6.  Next, the user authenticates to the IdP.  The manner in which the
+       end user is authenticated to the IdP, and any policies
+       surrounding such authentication, are out of scope for SAML and
+       hence for this document.  This step happens out of band from
+       SASL.
+
+   7.  The IdP will convey information about the success or failure of
+       the authentication back to the SASL server (RP) in the form of an
+       authentication statement or failure, using an indirect response
+       via the client browser or the handler (and with an external
+       browser, client control should be passed back to the SASL
+       client).  This step happens out of band from SASL.
+
+   8.  The SASL server sends an appropriate SASL response to the client.
+
+   Please note: What is described here is the case in which the client
+   has not previously authenticated.  It is possible that the client
+   already holds a valid SAML authentication token so that the user does
+   not need to be involved in the process anymore, but that would still
+   be external to SASL.  This is classic Web Single Sign-On, in which
+   the Web Browser client presents the authentication token (cookie) to
+   the RP without renewed user authentication at the IdP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 6]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   With all of this in mind, the flow appears as follows in Figure 2:
+
+            SASL Serv.       Client          IdP
+               |>-----(1)----->|              | Advertisement
+               |               |              |
+               |<-----(2)-----<|              | Initiation
+               |               |              |
+               |>-----(3)----->|              | Authentication Request
+               |               |              |
+               |<-----(4)-----<|              | Response of "="
+               |               |              |
+               |               |<- -(5,6) - ->| Client<>IdP
+               |               |              | Authentication
+               |               |              |
+               |<- - - - - - - - - - -(7)- - -| Authentication Statement
+               |               |              |
+               |>-----(8)----->|              | SASL Completion with
+               |               |              | Status
+               |               |              |
+
+          ----- = SASL
+          - - - = HTTP or HTTPS (external to SASL)
+
+                       Figure 2: Authentication Flow
+
+3.  SAML SASL Mechanism Specification
+
+   This section specifies the details of the SAML SASL mechanism.  See
+   Section 5 of [RFC4422] for additional details.
+
+   The name of this mechanism is "SAML20".  The mechanism is capable of
+   transferring an authorization identity (via the "gs2-header").  The
+   mechanism does not offer a security layer.
+
+   The mechanism is client-first.  The first mechanism message from the
+   client to the server is the "initial-response".  As described in
+   [RFC4422], if the application protocol does not support sending a
+   client response together with the authentication request, the server
+   will send an empty server challenge to let the client begin.  The
+   second mechanism message is from the server to the client, containing
+   the SAML "authentication-request".  The third mechanism message is
+   from the client to the server and is the fixed message consisting of
+   "=".  The fourth mechanism message is from the server to the client,
+   indicating the SASL mechanism outcome.
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 7]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+3.1.  Initial Response
+
+   A client initiates a SAML20 authentication with SASL by sending the
+   GS2 header followed by the Identity Provider identifier (message 2 in
+   Figure 2) and is defined using ABNF [RFC5234] as follows:
+
+        initial-response = gs2-header IdP-Identifier
+        IdP-Identifier = domain ; domain name with corresponding IdP
+
+   The gs2-header is used as follows:
+
+   -  The "gs2-nonstd-flag" MUST NOT be present.
+
+   -  The "gs2-cb-flag" MUST be set to "n" because channel-binding
+      [RFC5056] data cannot be integrity protected by the SAML
+      negotiation.  (Note: In theory, channel-binding data could be
+      inserted in the SAML flow by the client and verified by the
+      server, but that is currently not supported in SAML.)
+
+   -  The "gs2-authzid" carries the optional authorization identity as
+      specified in [RFC5801] (not to be confused with the
+      IdP-Identifier).
+
+   A domain name is either a "traditional domain name" as described in
+   [RFC1035] or an "internationalized domain name" as described in
+   [RFC5890].  Clients and servers MUST treat the IdP-Identifier as a
+   domain name slot [RFC5890].  They also SHOULD support
+   internationalized domain names (IDNs) in the IdP-Identifier field; if
+   they do so, all of the domain name's labels MUST be A-labels or
+   NR-LDH labels [RFC5890].  If necessary, internationalized labels MUST
+   be converted from U-labels to A-labels by using the Punycode encoding
+   [RFC3492] for A-labels prior to sending them to the SASL server, as
+   described in the protocol specification for Internationalized Domain
+   Names in Applications [RFC5891].
+
+3.2.  Authentication Request
+
+   The SASL server transmits to the SASL client a URI that redirects the
+   SAML client to the IdP (corresponding to the domain that the user
+   provided), with a SAML authentication request as one of the
+   parameters (message 3 in Figure 2) using the following ABNF:
+
+        authentication-request = URI
+
+   The URI is specified in [RFC3986] and is encoded according to
+   Section 3.4 ("HTTP Redirect Binding") of the SAML 2.0 bindings
+   specification [OASIS-SAMLv2-BIND].  The SAML authentication request
+   is encoded according to Section 3.4 ("Authentication Request
+
+
+
+Wierenga, et al.             Standards Track                    [Page 8]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Protocol") of [OASIS-SAMLv2-CORE].  Should the client support
+   Internationalized Resource Identifiers (IRIs) [RFC3987], it MUST
+   first map the IRI to a URI before transmitting it to the server, as
+   defined in Section 3.1 of [RFC3987].
+
+   Note: The SASL server may have a static mapping of domain to
+   corresponding IdP or, alternatively, a DNS-lookup mechanism could be
+   envisioned, but that is out of scope for this document.
+
+   Note: While the SASL client MAY sanity-check the URI it received,
+   ultimately it is the SAML IdP that will be validated by the SAML
+   client; this topic is out of scope for this document.
+
+   The client then sends the authentication request via an HTTP GET
+   (sent over a server-authenticated TLS channel) to the IdP, as if
+   redirected to do so from an HTTP server and in accordance with the
+   Web Browser SSO profile, as described in Section 4.1 of
+   [OASIS-SAMLv2-PROF] (messages 5 and 6 in Figure 2).
+
+   The client handles both user authentication to the IdP and
+   confirmation or rejection of the authentication of the RP (out of
+   scope for this document).
+
+   After all authentication has been completed by the IdP, the IdP will
+   send a redirect message to the client in the form of a URI
+   corresponding to the RP as specified in the authentication request
+   ("AssertionConsumerServiceURL") and with the SAML response as one of
+   the parameters (message 7 in Figure 2).
+
+   Please note: This means that the SASL server needs to implement a
+   SAML RP.  Also, the SASL server needs to correlate the session it has
+   with the SASL client with the appropriate SAML authentication result.
+   It can do so by comparing the ID of the SAML authentication request
+   it has issued with the one it receives in the SAML authentication
+   statement.
+
+3.3.  Outcome and Parameters
+
+   The SASL server (in its capacity as a SAML RP) now validates the SAML
+   authentication response it received from the SAML client via HTTP or
+   HTTPS.
+
+   The outcome of that validation by the SASL server constitutes a SASL
+   mechanism outcome and therefore (as stated in [RFC4422]) SHALL be
+   used to set state in the server accordingly, and it SHALL be used by
+   the server to report that state to the SASL client, as described in
+   [RFC4422], Section 3.6 (message 8 in Figure 2).
+
+
+
+
+Wierenga, et al.             Standards Track                    [Page 9]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+4.  SAML GSS-API Mechanism Specification
+
+   This section and its sub-sections are not required for SASL
+   implementors, but this section MUST be observed to implement the
+   GSS-API mechanism discussed below.
+
+   This section specifies a GSS-API mechanism that, when used via the
+   GS2 bridge to SASL, behaves like the SASL mechanism defined in this
+   document.  Thus, it can loosely be said that the SAML SASL mechanism
+   is also a GSS-API mechanism.  The SAML user takes the role of the
+   GSS-API Initiator, and the SAML RP takes the role of the GSS-API
+   Acceptor.  The SAML IdP does not have a role in GSS-API and is
+   considered an internal matter for the SAML mechanism.  The messages
+   are the same, but
+
+   a)  the GS2 header on the client's first message and channel-binding
+       data are excluded when SAML is used as a GSS-API mechanism, and
+
+   b)  the initial context token header (Section 3.1 of [RFC2743]) is
+       prefixed to the client's first authentication message (context
+       token).
+
+   The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2
+   for more information).  The DER encoding of the OID is
+   0x2b 0x06 0x01 0x05 0x05 0x11.
+
+   SAML20 security contexts MUST have the mutual_state flag
+   (GSS_C_MUTUAL_FLAG) set to TRUE.  SAML does not support credential
+   delegation; therefore, SAML security contexts MUST have the
+   deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
+
+   The mutual authentication property of this mechanism relies on
+   successfully comparing the TLS server's identity with the negotiated
+   target name.  Since the TLS channel is managed by the application
+   outside of the GSS-API mechanism, the mechanism itself is unable to
+   confirm the name, while the application is able to perform this
+   comparison for the mechanism.  For this reason, applications MUST
+   match the TLS server's identity with the target name, as discussed in
+   [RFC6125].  More precisely, to pass identity validation, the client
+   uses the securely negotiated targ_name as the reference identifier
+   and matches it to the DNS-ID of the server's certificate, and it MUST
+   reject the connection if there is a mismatch.  For compatibility with
+   deployed certificate hierarchies, the client MAY also perform a
+   comparison with the Common Name ID (CN-ID) when there is no DNS-ID
+   present.  Wildcard matching is permitted.  The targ_name reference
+   identifier is a "traditional domain names"; thus, the comparison is
+   made using case-insensitive ASCII comparison.
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 10]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   The SAML mechanism does not support per-message tokens or the
+   GSS_Pseudo_random() function [RFC4401].
+
+4.1.  GSS-API Principal Name Types for SAML
+
+   SAML supports standard generic name syntaxes for acceptors such as
+   GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).  SAML
+   supports only a single name type for initiators: GSS_C_NT_USER_NAME.
+   GSS_C_NT_USER_NAME is the default name type for SAML.  The query,
+   display, and exported name syntaxes for SAML principal names are all
+   the same.  There are no SAML-specific name syntaxes -- applications
+   should use generic GSS-API name types, such as GSS_C_NT_USER_NAME and
+   GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743] Section 4).  The exported
+   name token, of course, conforms to [RFC2743], Section 3.2.
+
+5.  Examples
+
+5.1.  XMPP
+
+   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 [RFC6120] connection to xmpp.example.com.  The
+   authentication on the wire would then look something like the
+   following:
+
+   Step 1: Client initiates stream to server:
+
+   <stream:stream xmlns='jabber:client'
+   xmlns:stream='http://etherx.jabber.org/streams'
+   to='example.com' version='1.0'>
+
+
+   Step 2: Server responds with a stream tag sent to client:
+
+   <stream:stream
+   xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
+   id='some_id' from='example.com' version='1.0'>
+
+
+   Step 3: Server informs client of available authentication mechanisms:
+
+   <stream:features>
+    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
+     <mechanism>DIGEST-MD5</mechanism>
+     <mechanism>PLAIN</mechanism>
+     <mechanism>SAML20</mechanism>
+    </mechanisms>
+   </stream:features>
+
+
+
+Wierenga, et al.             Standards Track                   [Page 11]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Step 4: Client selects an authentication mechanism and provides the
+   initial client response -- containing the gs2-header and domain --
+   that has been encoded in base64 according to Section 4 of [RFC4648]:
+
+    <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20'>
+    biwsZXhhbXBsZS5vcmc=</auth>
+
+   The decoded string is
+
+      n,,example.org
+
+
+   Step 5: Server sends a base64-encoded challenge to client in the form
+   of an HTTP redirect to the SAML IdP corresponding to example.org
+   (https://saml.example.org) with the SAML authentication request as
+   specified in the redirection URL:
+
+    aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
+    dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
+    Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
+    M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
+    QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
+    dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
+    TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
+    UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
+    TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
+    TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
+    WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
+    Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
+    TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
+    SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
+    T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
+    SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
+    TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
+    ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
+    T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
+    enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
+    Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
+    aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
+    ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
+    R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
+    NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
+    Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
+    ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
+    MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
+    RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
+    NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
+    YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
+
+
+
+Wierenga, et al.             Standards Track                   [Page 12]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+    MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
+    UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
+    bGMzUSs=
+
+   The decoded challenge is as follows:
+
+    https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
+    F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
+    NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
+    A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
+    AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
+    Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
+    NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
+    5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
+    JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
+    NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
+    M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
+    I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
+    N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
+    9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
+    Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
+    BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
+    xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
+    RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
+    5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
+    Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
+    AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
+    Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
+    1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
+    ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
+    Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
+
+   Where the decoded SAMLRequest looks like the following:
+
+ <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+     ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
+     IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
+     IsPassive="false"
+     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
+     AssertionConsumerServiceURL=
+         "https://xmpp.example.com/SAML/AssertionConsumerService">
+  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+      https://xmpp.example.com
+  </saml:Issuer>
+  <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
+      SPNameQualifier="xmpp.example.com" AllowCreate="true" />
+  <samlp:RequestedAuthnContext
+
+
+
+Wierenga, et al.             Standards Track                   [Page 13]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+         Comparison="exact">
+   <saml:AuthnContextClassRef
+       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+       urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
+   </saml:AuthnContextClassRef>
+  </samlp:RequestedAuthnContext>
+ </samlp:AuthnRequest>
+
+   Note: The server can use the request ID
+   ("_bec424fa5103428909a30ff1e31168327f79474984") to correlate the SASL
+   session with the SAML authentication.
+
+
+   Step 5 (alternative): Server returns error to client if no SAML
+   authentication request can be constructed:
+
+    <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
+     <temporary-auth-failure/>
+    </failure>
+    </stream:stream>
+
+
+   Step 6: Client sends the "=" response (base64-encoded) to the
+   challenge:
+
+    <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
+     PQ==
+    </response>
+
+   The following steps between brackets are out of scope for this
+   document but are included to better illustrate the entire flow:
+
+   [The client now sends the URL to a browser instance for processing.
+   The browser engages in a normal SAML authentication flow (external to
+   SASL), like redirection to the IdP (https://saml.example.org); the
+   user logs into https://saml.example.org and agrees to authenticate to
+   xmpp.example.com.  A redirect is passed back to the client browser.
+   The client browser in turn sends the AuthN response, which contains
+   the subject-identifier as an attribute, to the server.  If the AuthN
+   response doesn't contain the JID, the server maps the subject-
+   identifier received from the IdP to a JID.]
+
+
+   Step 7: Server informs client of successful authentication:
+
+   <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 14]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Step 7 (alternative): Server informs client of failed authentication:
+
+   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
+    <not-authorized/>
+   </failure>
+   </stream:stream>
+
+
+   Please note: Line breaks were added to the base64 data for clarity.
+
+5.2.  IMAP
+
+   The following sequence describes an IMAP exchange.  Lines beginning
+   with 'S:' indicate data sent by the server, and lines starting with
+   'C:' indicate data sent by the client.  Long lines are wrapped for
+   readability.
+
+   S: * OK IMAP4rev1
+   C: . CAPABILITY
+   S: * CAPABILITY IMAP4rev1 STARTTLS
+   S: . OK CAPABILITY Completed
+   C: . STARTTLS
+   S: . OK Begin TLS negotiation now
+   C: . CAPABILITY
+   S: * CAPABILITY IMAP4rev1 AUTH=SAML20
+   S: . OK CAPABILITY Completed
+   C: . AUTHENTICATE SAML20
+   S: +
+   C: biwsZXhhbXBsZS5vcmc=
+   S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1M
+   UmVxdWVzdD1QSE5oYld4d09rRg0KMWRHaHVVbVZ4ZFdWemRDQjRiV3h1Y3pwe
+   llXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQg0KVFV3Nk1pNH
+   dPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lFbEVQU0pmWW1Wak5ESTBabUUxTVRBek5
+   ESTRPVEE1WQ0KVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQlda
+   WEp6YVc5dVBTSXlMakFpRFFvZ0lDQWdTWA0KTnpkV1ZKYm5OMFlXNTBQU0l5T
+   URBM0xURXlMVEV3VkRFeE9qTTVPak0wV2lJZ1JtOXlZMlZCZFhSb2JqMA0KaV
+   ptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpTSU5DaUFnSUN
+   CUWNtOTBiMk52YkVKcA0KYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6
+   cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVg0KRlJRTFZCUFUxUWlEU
+   W9nSUNBZ1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRME
+   tJQw0KQWdJQ0FnSUNBaWFIUjBjSE02THk5dFlXbHNMbVY0WVcxd2JHVXVZMjl
+   0TDFOQlRVd3ZRWE56WlhKMGFXOQ0KdVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0
+   TkNpQThjMkZ0YkRwSmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaQ0KZFhKdU9tO
+   WhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3T21GemMyVnlkR2x2YmlJK0
+   RRb2dJQ0FnSQ0KR2gwZEhCek9pOHZlRzF3Y0M1bGVHRnRjR3hsTG1OdmJRMEt
+   JRHd2YzJGdGJEcEpjM04xWlhJK0RRb2dQSA0KTmhiV3h3T2s1aGJXVkpSRkJ2
+   YkdsamVTQjRiV3h1Y3pwellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVg0Ke
+   k9uUmpPbE5CVFV3Nk1pNHdPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lDQkdiM0p0WV
+
+
+
+Wierenga, et al.             Standards Track                   [Page 15]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   hROUluVnlianB2WVhOcA0KY3pwdVlXMWxjenAwWXpwVFFVMU1Pakl1TURwdVl
+   XMWxhV1F0Wm05eWJXRjBPbkJsY25OcGMzUmxiblFpRA0KUW9nSUNBZ0lGTlFU
+   bUZ0WlZGMVlXeHBabWxsY2owaWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXe
+   HNiMw0KZERjbVZoZEdVOUluUnlkV1VpSUM4K0RRb2dQSE5oYld4d09sSmxjWF
+   ZsYzNSbFpFRjFkR2h1UTI5dWRHVg0KNGRBMEtJQ0FnSUNCNGJXeHVjenB6WVc
+   xc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09u
+   QnliM1J2WTI5c0lpQU5DaUFnSUNBZ0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoa
+   FkzUWlQZzBLSQ0KQ0E4YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGemMxSm
+   xaZzBLSUNBZ0lDQWdlRzFzYm5NNmMyRnRiRA0KMGlkWEp1T205aGMybHpPbTV
+   oYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJWeWRHbHZiaUkrRFFvZ0lDQQ0K
+   Z0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVERveUxqQTZZV002W
+   TJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6Y0c5eW
+   RBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUQ0KMnhoYzNOU1pXWSt
+   EUW9nUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lB
+   MEtQQw0KOXpZVzFzY0RwQmRYUm9ibEpsY1hWbGMzUSs=
+   C: PQ==
+   S: . OK Success (TLS protection)
+
+   The decoded challenge is as follows:
+
+   https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF
+   1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB
+   TUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5Y
+   TMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSX
+   NzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdXRobj0
+   iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2NvbEJp
+   bmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIV
+   FRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPQ0KIC
+   AgICAgICAiaHR0cHM6Ly9tYWlsLmV4YW1wbGUuY29tL1NBTUwvQXNzZXJ0aW9
+   uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0i
+   dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICAgI
+   Gh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3N1ZXI+DQogPH
+   NhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWV
+   zOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYXQ9InVybjpvYXNp
+   czpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiD
+   QogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcGxlLmNvbSIgQWxsb3
+   dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV
+   4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6
+   Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvbj0iZXhhY3QiPg0KI
+   CA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KICAgICAgeG1sbnM6c2FtbD
+   0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICA
+   gICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNz
+   d29yZFByb3RlY3RlZFRyYW5zcG9ydA0KICA8L3NhbWw6QXV0aG5Db250ZXh0Q
+   2xhc3NSZWY+DQogPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+IA0KPC
+   9zYW1scDpBdXRoblJlcXVlc3Q+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 16]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   Where the decoded SAMLRequest looks like the following:
+
+ <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+     ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
+     IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
+     IsPassive="false"
+     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
+     AssertionConsumerServiceURL=
+         "https://mail.example.com/SAML/AssertionConsumerService">
+  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+      https://xmpp.example.com
+  </saml:Issuer>
+  <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
+      SPNameQualifier="xmpp.example.com" AllowCreate="true" />
+  <samlp:RequestedAuthnContext
+      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
+         Comparison="exact">
+   <saml:AuthnContextClassRef
+       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+       urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
+   </saml:AuthnContextClassRef>
+  </samlp:RequestedAuthnContext>
+ </samlp:AuthnRequest>
+
+6.  Security Considerations
+
+   This section addresses only security considerations associated with
+   the use of SAML with SASL applications.  For considerations relating
+   to SAML in general, and for general SASL security considerations, the
+   reader is referred to the SAML specifications and to other
+   literature.
+
+6.1.  Man-in-the-Middle and Tunneling Attacks
+
+   This mechanism is vulnerable to man-in-the-middle and tunneling
+   attacks unless a client always verifies the server's identity before
+   proceeding with authentication (see [RFC6125]).  Typically, TLS is
+   used to provide a secure channel with server authentication.
+
+6.2.  Binding SAML Subject Identifiers to Authorization Identities
+
+   As specified in [RFC4422], the server is responsible for binding
+   credentials to a specific authorization identity.  It is therefore
+   necessary that only specific trusted IdPs be allowed.  This is a
+   typical part of SAML trust establishment between RPs and the IdP.
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 17]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+6.3.  User Privacy
+
+   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 visits, but there is nothing that prohibits
+   the collection of information.  SASL server implementers should be
+   aware that SAML IdPs will be able to track -- to some extent -- user
+   access to their services.
+
+6.4.  Collusion between RPs
+
+   It is possible for RPs to link data that they have collected on the
+   users.  By using the same identifier to log into every RP, collusion
+   between RPs is possible.  In SAML, targeted identity was introduced.
+   Targeted identity allows the IdP to transform the identifier the user
+   typed in to an RP-specific opaque identifier.  This way, the RP would
+   never see the actual user identifier but instead would see a randomly
+   generated identifier.
+
+6.5.  Security Considerations Specific to GSS-API
+
+   Security issues inherent in GSS-API [RFC2743] and GS2 [RFC5801] apply
+   to the SAML GSS-API mechanism defined in this document.  Further, and
+   as discussed in Section 4, proper TLS server identity verification is
+   critical to the security of the mechanism.
+
+7.  IANA Considerations
+
+7.1.  IANA Mech-Profile
+
+   The IANA has registered the following SASL profile:
+
+   SASL mechanism profile: SAML20
+
+   Security Considerations: See this document
+
+   Published Specification: See this document
+
+   For further information: Contact the authors of this document.
+
+   Owner/Change controller: the IETF
+
+   Intended usage: COMMON
+
+   Note: None
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 18]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+7.2.  IANA OID
+
+   The IANA has also assigned a new entry for this GSS mechanism in the
+   SMI Security for Mechanism Codes sub-registry, whose prefix is
+   iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5), and
+   referenced this specification in the registry.
+
+8.  References
+
+8.1.  Normative References
+
+   [OASIS-SAMLv2-BIND]
+              Cantor, S., Ed., Hirsch, F., Ed., Kemp, J., Ed., Philpott,
+              R., Ed., and E. Maler, Ed., "Bindings for the OASIS
+              Security Assertion Markup Language (SAML) V2.0", OASIS
+              Standard saml-bindings-2.0-os, March 2005, <http://
+              docs.oasis-open.org/security/saml/v2.0/
+              saml-bindings-2.0-os.pdf>.
+
+   [OASIS-SAMLv2-CORE]
+              Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
+              Maler, Ed., "Assertions and Protocols for the OASIS
+              Security Assertion Markup Language (SAML) V2.0", OASIS
+              Standard saml-core-2.0-os, March 2005, <http://
+              docs.oasis-open.org/security/saml/v2.0/
+              saml-core-2.0-os.pdf>.
+
+   [OASIS-SAMLv2-PROF]
+              Hughes, J., Ed., Cantor, S., Ed., Hodges, J., Ed., Hirsch,
+              F., Ed., Mishra, P., Ed., Philpott, R., Ed., and E. Maler,
+              Ed., "Profiles for the OASIS Security Assertion Markup
+              Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-
+              2.0-os, March 2005, <http://docs.oasis-open.org/security/
+              saml/v2.0/saml-profiles-2.0-os.pdf>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 19]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
+              for Internationalized Domain Names in Applications
+              (IDNA)", RFC 3492, March 2003.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
+              Identifiers (IRIs)", RFC 3987, January 2005.
+
+   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              June 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              January 2008.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5801]  Josefsson, S. and N. Williams, "Using Generic Security
+              Service Application Program Interface (GSS-API) Mechanisms
+              in Simple Authentication and Security Layer (SASL): The
+              GS2 Mechanism Family", RFC 5801, July 2010.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010.
+
+   [RFC5891]  Klensin, J., "Internationalized Domain Names in
+              Applications (IDNA): Protocol", RFC 5891, August 2010.
+
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 20]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [W3C-REC-HTML401]
+              Le Hors, A., Ed., Raggett, D., Ed., and I. Jacobs, Ed.,
+              "HTML 4.01 Specification", World Wide Web Consortium
+              Recommendation REC-html401-19991224, December 1999,
+              <http://www.w3.org/TR/1999/REC-html401-19991224>.
+
+8.2.  Informative References
+
+   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+              STD 53, RFC 1939, May 1996.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+              VERSION 4rev1", RFC 3501, March 2003.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, March 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 21]
+
+RFC 6595          A SASL and GSS-API Mechanism for SAML       April 2012
+
+
+Appendix A.  Acknowledgments
+
+   The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
+   Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank
+   Mauldin, RL "Bob" Morgan, Stefan Plug, and Hannes Tschofenig for
+   their review and contributions.
+
+Authors' Addresses
+
+   Klaas Wierenga
+   Cisco Systems, Inc.
+   Haarlerbergweg 13-19
+   1101 CH Amsterdam
+   The Netherlands
+
+   Phone: +31 20 357 1752
+   EMail: klaas@cisco.com
+
+
+   Eliot Lear
+   Cisco Systems GmbH
+   Richtistrasse 7
+   CH-8304 Wallisellen
+   Switzerland
+
+   Phone: +41 44 878 9200
+   EMail: lear@cisco.com
+
+
+   Simon Josefsson
+   SJD AB
+   Johan Olof Wallins vag 13
+   Solna  171 64
+   Sweden
+
+   EMail: simon@josefsson.org
+   URI:   http://josefsson.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wierenga, et al.             Standards Track                   [Page 22]
+