idnits 2.17.1
draft-ietf-kitten-sasl-saml-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 11, 2012) is 4487 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
-- Obsolete informational reference (is this intentional?): RFC 3501
(Obsoleted by RFC 9051)
Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Wierenga
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Standards Track E. Lear
5 Expires: July 14, 2012 Cisco Systems GmbH
6 S. Josefsson
7 SJD AB
8 January 11, 2012
10 A SASL and GSS-API Mechanism for SAML
11 draft-ietf-kitten-sasl-saml-08.txt
13 Abstract
15 Security Assertion Markup Language (SAML) has found its usage on the
16 Internet for Web Single Sign-On. Simple Authentication and Security
17 Layer (SASL) and the Generic Security Service Application Program
18 Interface (GSS-API) are application frameworks to generalize
19 authentication. This memo specifies a SASL mechanism and a GSS-API
20 mechanism for SAML 2.0 that allows the integration of existing SAML
21 Identity Providers with applications using SASL and GSS-API.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on July 14, 2012.
40 Copyright Notice
42 Copyright (c) 2012 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
60 2. Authentication flow . . . . . . . . . . . . . . . . . . . . . 6
61 3. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9
62 3.1. Initial Response . . . . . . . . . . . . . . . . . . . . . 9
63 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 10
64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 11
65 4. SAML GSS-API Mechanism Specification . . . . . . . . . . . . . 12
66 4.1. GSS-API Principal Name Types for SAML . . . . . . . . . . 12
67 5. Channel Binding . . . . . . . . . . . . . . . . . . . . . . . 14
68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
69 6.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
70 6.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
72 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 24
73 7.2. Binding SAML subject identifiers to Authorization
74 Identities . . . . . . . . . . . . . . . . . . . . . . . . 24
75 7.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
76 7.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 24
77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
78 8.1. IANA mech-profile . . . . . . . . . . . . . . . . . . . . 25
79 8.2. IANA OID . . . . . . . . . . . . . . . . . . . . . . . . . 25
80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
82 9.2. Informative References . . . . . . . . . . . . . . . . . . 27
83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28
84 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 29
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
87 1. Introduction
89 Security Assertion Markup Language (SAML) 2.0
90 [OASIS.saml-core-2.0-os] is a modular specification that provides
91 various means for a user to be identified to a relying party (RP)
92 through the exchange of (typically signed) assertions issued by an
93 identity provider (IdP). It includes a number of protocols, protocol
94 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
95 [OASIS.saml-profiles-2.0-os] designed for different use cases.
97 Simple Authentication and Security Layer (SASL) [RFC4422] is a
98 generalized mechanism for identifying and authenticating a user and
99 for optionally negotiating a security layer for subsequent protocol
100 interactions. SASL is used by application protocols like IMAP
101 [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make
102 modular authentication, so that newer authentication mechanisms can
103 be added as needed. This memo specifies just such a mechanism.
105 The Generic Security Service Application Program Interface (GSS-API)
106 [RFC2743] provides a framework for applications to support multiple
107 authentication mechanisms through a unified programming interface.
108 This document defines a pure SASL mechanism for SAML, but it conforms
109 to the new bridge between SASL and the GSS-API called GS2 [RFC5801].
110 This means that this document defines both a SASL mechanism and a
111 GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL
112 implementers, and the GSS-API considerations can be avoided in
113 environments that use SASL directly without GSS-API.
115 As currently envisioned, this mechanism is to allow the interworking
116 between SASL and SAML in order to assert identity and other
117 attributes to relying parties. As such, while servers (as relying
118 parties) will advertise SASL mechanisms (including SAML), clients
119 will select the SAML SASL mechanism as their SASL mechanism of
120 choice.
122 The SAML mechanism described in this memo aims to re-use the Web
123 Browser SSO profile defined in section 3.1 of the SAML profiles 2.0
124 specification [OASIS.saml-profiles-2.0-os] to the maximum extent and
125 therefore does not establish a separate authentication, integrity and
126 confidentiality mechanism. The mechanism assumes a security layer,
127 such as Transport Layer Security (TLS [RFC5246]), will continue to be
128 used. This specification is appropriate for use when a browser is
129 available.
131 Figure 1 describes the interworking between SAML and SASL: this
132 document requires enhancements to the Relying Party (the SASL server)
133 and to the Client, as the two SASL communication end points, but no
134 changes to the SAML Identity Provider are necessary. To accomplish
135 this goal some indirect messaging is tunneled within SASL, and some
136 use of external methods is made.
138 +-----------+
139 | |
140 >| Relying |
141 / | Party |
142 // | |
143 // +-----------+
144 SAML/ // ^
145 HTTPs // +--|--+
146 // | S| |
147 / S | A| |
148 // A | M| |
149 // S | L| |
150 // L | | |
151 // | | |
152 +--|--+
153 +------------+ v
154 | | +----------+
155 | SAML | HTTPs | |
156 | Identity |<--------------->| Client |
157 | Provider | | |
158 +------------+ +----------+
160 Figure 1: Interworking Architecture
162 1.1. Terminology
164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
166 document are to be interpreted as described in RFC 2119 [RFC2119].
168 The reader is assumed to be familiar with the terms used in the SAML
169 2.0 specification [OASIS.saml-core-2.0-os].
171 1.2. Applicability
173 Because this mechanism transports information that should not be
174 controlled by an attacker, the SAML mechanism MUST only be used over
175 channels protected by TLS, and the client MUST successfully validate
176 the server certificate, or over similar integrity protected and
177 authenticated channels. [RFC5280][RFC6125]
178 Note: An Intranet does not constitute such an integrity protected and
179 authenticated channel!
181 2. Authentication flow
183 While SAML itself is merely a markup language, its common use case
184 these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML
185 [W3C.REC-html401-19991224]. What follows is a typical flow:
187 1. The browser requests a resource of a Relying Party (RP) (via an
188 HTTP request).
190 2. The Relying Party redirects the browser via an HTTP redirect (as
191 described in Section 10.3 of [RFC2616]) to the Identity Provider
192 (IdP) or an IdP discovery service with as parameters an
193 authentication request that contains the name of resource being
194 requested, a browser cookie and a return URL as specified in
195 Section 3.1 of the SAML profiles 2.0 specification
196 [OASIS.saml-profiles-2.0-os].
198 3. The user authenticates to the IdP and perhaps authorizes the
199 authentication to the Relying Party.
201 4. In its authentication response, the IdP redirects (via an HTTP
202 redirect) the browser back to the RP with an authentication
203 assertion (stating that the IdP vouches that the subject has
204 successfully authenticated), optionally along with some
205 additional attributes.
207 5. The Relying Party now has sufficient identity information to
208 approve access to the resource or not, and acts accordingly. The
209 authentication is concluded.
211 When considering this flow in the context of SASL, we note that while
212 the Relying Party and the client both must change their code to
213 implement this SASL mechanism, the IdP can remain untouched. The
214 Relying Party already has some sort of session (probably a TCP
215 connection) established with the client. However, it may be
216 necessary to redirect a SASL client to another application or
217 handler. The steps are as follows:
219 1. The SASL server (Relying Party) advertises support for the SASL
220 SAML20 mechanism to the client
222 2. The client initiates a SASL authentication with SAML20 and sends
223 a domain name that allows the SASL server to determine the
224 appropriate IdP
226 3. The SASL server transmits an authentication request encoded using
227 a Universal Resource Identifier (URI) as described in RFC 3986
228 [RFC3986] and an HTTP redirect to the IdP corresponding to the
229 domain
231 4. The SASL client now sends an empty response, as authentication
232 continues via the normal SAML flow.
234 5. At this point the SASL client MUST construct a URL containing the
235 content received in the previous message from the SASL server.
236 This URL is transmitted to the IdP either by the SASL client
237 application or an appropriate handler, such as a browser.
239 6. Next the client authenticates to the IdP. The manner in which
240 the end user is authenticated to the IdP and any policies
241 surrounding such authentication is out of scope for SAML and
242 hence for this draft. This step happens out of band from SASL.
244 7. The IdP will convey information about the success or failure of
245 the authentication back to the the SASL server (Relying Party) in
246 the form of an Authentication Statement or failure, using a
247 indirect response via the client browser or the handler (and with
248 an external browser client control should be passed back to the
249 SASL client). This step happens out of band from SASL.
251 8. The SASL Server sends an appropriate SASL response to the client,
252 along with an optional list of attributes
254 Please note: What is described here is the case in which the client
255 has not previously authenticated. It is possible that the client
256 already holds a valid SAML authentication token so that the user does
257 not need to be involved in the process anymore, but that would still
258 be external to SASL. This is classic Web Single Sign-On, in which
259 the Web Browser client presents the authentication token (cookie) to
260 the RP without renewed user authentication at the IdP.
262 With all of this in mind, the flow appears as follows in Figure 2:
264 SASL Serv. Client IdP
265 |>-----(1)----->| | Advertisement
266 | | |
267 |<-----(2)-----<| | Initiation
268 | | |
269 |>-----(3)----->| | Authentication Request
270 | | |
271 |<-----(4)-----<| | Empty Response
272 | | |
273 | |< - -(5,6) - ->| Client<>IDP
274 | | | Authentication (5,6)
275 | | |
276 |<- - - - - - - - - - -(7)- - -| Authentication Statement
277 | | |
278 |>-----(8)----->| | SASL completion with
279 | | | status
280 | | |
282 ----- = SASL
283 - - - = HTTP or HTTPs (external to SASL)
285 Figure 2: Authentication flow
287 3. SAML SASL Mechanism Specification
289 This section specifies the details of the SAML SASL mechanism. See
290 section 5 of [RFC4422] for what needs to be described here.
292 The name of this mechanism is "SAML20". The mechanism is capable of
293 transferring an authorization identity (via the "gs2-header"). The
294 mechanism does not offer a security layer.
296 The mechanism is client-first. The first mechanism message from the
297 client to the server is the "initial-response". As described in
298 [RFC4422], if the application protocol does not support sending a
299 client-response together with the authentication request, the server
300 will send an empty server-challenge to let the client begin.
302 The second mechanism message is from the server to the client,
303 containing the SAML "authentication-request".
305 The third mechanism message is from client to the server, and is the
306 fixed message consisting of "=".
308 The fourth mechanism message is from the server to the client,
309 indicating the SASL mechanism outcome.
311 3.1. Initial Response
313 A client initiates a "SAML20" authentication with SASL by sending the
314 GS2 header followed by the authentication identifier (message 2 in
315 Figure 2) and is defined as follows:
317 initial-response = gs2-header Idp-Identifier
318 IdP-Identifier = domain ; domain name with corresponding IdP
320 The "gs2-header" carries the optional authorization identity as
321 specified in [RFC5801], and it is used as follows:
323 - The "gs2-nonstd-flag" MUST NOT be present.
325 - See Section 5 for the channel binding "gs2-cb-flag" field.
327 - The "gs2-authzid" carries the optional authorization identity.
329 Domain name is specified in [RFC1035].
331 3.2. Authentication Request
333 The SASL Server transmits to the SASL client a URI that redirects the
334 SAML client to the IdP (corresponding to the domain the user
335 provided), with a SAML authentication request as one of the
336 parameters (message 3 in Figure 2) in the following way:
338 authentication-request = URI
340 URI is specified in [RFC3986] and is encoded according to Section 3.4
341 (HTTP Redirect) of the SAML bindings 2.0 specification
342 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is
343 encoded according to Section 3.4 (Authentication Request) of the SAML
344 core 2.0 specification [OASIS.saml-core-2.0-os].
346 Note: The SASL server may have a static mapping of domain to
347 corresponding IdP or alternatively a DNS-lookup mechanism could be
348 envisioned, but that is out-of-scope for this document.
350 Note: While the SASL client MAY sanity check the URI it received,
351 ultimately it is the SAML IdP that will be validated by the SAML
352 client which is out-of-scope for this document.
354 The client then sends the authentication request via an HTTP GET
355 (sent over a server-authenticated TLS channel) to the IdP, as if
356 redirected to do so from an HTTP server and in accordance with the
357 Web Browser SSO profile, as described in section 3.1 of SAML profiles
358 2.0 specification [OASIS.saml-profiles-2.0-os] (message 5 and 6 in
359 Figure 2).
361 The client handles both user authentication to the IdP and
362 confirmation or rejection of the authentiation of the RP (out-of-
363 scope for this document).
365 After all authentication has been completed by the IdP, the IdP will
366 send a redirect message to the client in the form of a URI
367 corresponding to the Relying Party as specified in the authentication
368 request ("AssertionConsumerServiceURL") and with the SAML response as
369 one of the parameters (message 7 in Figure 2).
371 Please note: this means that the SASL server needs to implement a
372 SAML Relying Party. Also, the SASL server needs to correlate the TCP
373 session from the SASL client with the SAML authentication by
374 comparing the ID of the SAML request with that in the response.
376 3.3. Outcome and parameters
378 The SASL server now validates the response it received from the
379 client via HTTP or HTTPS, as specified in the SAML specification
381 The response by the SASL server constitutes a SASL mechanism outcome,
382 and MUST be used to set state in the server accordingly, and it MUST
383 be used by the server to report that state to the SASL client as
384 described in [RFC4422] Section 3.6 (message 8 in Figure 2).
386 4. SAML GSS-API Mechanism Specification
388 This section, its sub-sections and appropriate references of it not
389 referenced elsewhere in this document, are not required for SASL
390 implementors, but this section MUST be observed to implement the GSS-
391 API mechanism discussed below.
393 The SAML SASL mechanism is actually also a GSS-API mechanism. The
394 SAML user takes the role of the GSS-API Initiator and the SAML
395 Relying Party takes the role of the GSS-API Acceptor. The SAML
396 Identity Provider does not have a role in GSS-API, and is considered
397 an internal matter for the SAML mechanism. The messages are the
398 same, but
400 a) the GS2 header on the client's first message and channel binding
401 data is excluded when SAML is used as a GSS-API mechanism, and
403 b) the RFC2743 section 3.1 initial context token header is prefixed
404 to the client's first authentication message (context token).
406 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see
407 IANA considerations).
409 SAML20 security contexts MUST have the mutual_state flag
410 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
411 delegation, therefore SAML security contexts MUST have the
412 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
414 The mutual authentication property of this mechanism relies on
415 successfully comparing the TLS server identity with the negotiated
416 target name. Since the TLS channel is managed by the application
417 outside of the GSS-API mechanism, the mechanism itself is unable to
418 confirm the name while the application is able to perform this
419 comparison for the mechanism. For this reason, applications MUST
420 match the TLS server identity with the target name, as discussed in
421 [RFC6125].
423 The SAML mechanism does not support per-message tokens or
424 GSS_Pseudo_random.
426 4.1. GSS-API Principal Name Types for SAML
428 SAML supports standard generic name syntaxes for acceptors such as
429 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML
430 supports only a single name type for initiators: GSS_C_NT_USER_NAME.
431 GSS_C_NT_USER_NAME is the default name type for SAML. The query,
432 display, and exported name syntaxes for SAML principal names are all
433 the same. There are no SAML-specific name syntaxes -- applications
434 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
435 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported
436 name token does, of course, conform to [RFC2743], Section 3.2.
438 5. Channel Binding
440 The "gs2-cb-flag" MUST be set to "n" because channel binding data
441 cannot be integrity protected by the SAML negotiation.
443 Note: In theory channel binding data could be inserted in the SAML
444 flow by the client and verified by the server, but that is currently
445 not supported in SAML.
447 6. Examples
449 6.1. XMPP
451 Suppose the user has an identity at the SAML IdP saml.example.org and
452 a Jabber Identifier (JID) "somenode@example.com", and wishes to
453 authenticate his XMPP connection to xmpp.example.com. The
454 authentication on the wire would then look something like the
455 following:
457 Step 1: Client initiates stream to server:
459
463 Step 2: Server responds with a stream tag sent to client:
465
469 Step 3: Server informs client of available authentication mechanisms:
471
472
473 DIGEST-MD5
474 PLAIN
475 SAML20
476
477
479 Step 4: Client selects an authentication mechanism and provides the
480 initial client response containing the BASE64 [RFC4648] encoded gs2-
481 header and domain:
483
484 biwsZXhhbXBsZS5vcmc
486 The decoded string is: n,,example.org
487 Step 5: Server sends a BASE64 encoded challenge to client in the form
488 of an HTTP Redirect to the SAML IdP corresponding to example.org
489 (https://saml.example.org) with the SAML Authentication Request as
490 specified in the redirection url:
492 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
493 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
494 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
495 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
496 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
497 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
498 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
499 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
500 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
501 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
502 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
503 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
504 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
505 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
506 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
507 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
508 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
509 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
510 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
511 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
512 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
513 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
514 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
515 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
516 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
517 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
518 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
519 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
520 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
521 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
522 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
523 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
524 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
525 bGMzUSs=
527 The decoded challenge is:
529 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
530 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
531 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
532 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
533 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
534 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
535 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
536 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
537 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
538 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
539 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
540 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
541 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
542 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
543 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
544 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
545 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
546 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
547 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
548 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
549 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
550 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
551 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
552 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
553 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
555 Where the decoded SAMLRequest looks like:
557
564
565 https://xmpp.example.com
566
567
570
573
575 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
576
577
578
580 Note: the server can use the request ID
581 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL
582 session with the SAML authentication.
584 Step 5 (alternative): Server returns error to client if no SAML
585 Authentication Request can be constructed:
587
588
589
590
592 Step 6: Client sends the empty response to the challenge encoded as a
593 single =:
595
596 =
597
599 [ The client now sends the URL to a browser instance for processing.
601 The browser engages in a normal SAML authentication flow (external to
602 SASL), like redirection to the Identity Provider
603 (https://saml.example.org), the user logs into
604 https://saml.example.org, and agrees to authenticate to
605 xmpp.example.com. A redirect is passed back to the client browser
606 who sends the AuthN response to the server, containing the subject-
607 identifier as an attribute. If the AuthN response doesn't contain
608 the JID, the server maps the subject-identifier received from the IdP
609 to a JID]
611 Step 7: Server informs client of successful authentication:
613
615 Step 7 (alt): Server informs client of failed authentication:
617
618
619
620
622 Step 8: Client initiates a new stream to server:
624
628 Step 9: Server responds by sending a stream header to client along
629 with any additional features (or an empty features element):
631
634
635
636
637
639 Step 10: Client binds a resource:
641
642
643 someresource
644
645
647 Step 11: Server informs client of successful resource binding:
649
650
651 somenode@example.com/someresource
652
653
655 Please note: line breaks were added to the base64 for clarity.
657 6.2. IMAP
659 The following describes an IMAP exchange. Lines beginning with 'S:'
660 indicate data sent by the server, and lines starting with 'C:'
661 indicate data sent by the client. Long lines are wrapped for
662 readability.
664 S: * OK IMAP4rev1
665 C: . CAPABILITY
666 S: * CAPABILITY IMAP4rev1 STARTTLS
667 S: . OK CAPABILITY Completed
668 C: . STARTTLS
669 S: . OK Begin TLS negotiation now
670 C: . CAPABILITY
671 S: * CAPABILITY IMAP4rev1 AUTH=SAML20
672 S: . OK CAPABILITY Completed
673 C: . AUTHENTICATE SAML20
674 S: +
675 C: biwsZXhhbXBsZS5vcmc
676 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
677 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
678 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
679 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
680 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
681 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
682 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
683 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
684 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
685 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
686 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
687 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
688 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
689 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
690 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
691 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
692 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
693 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
694 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
695 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
696 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
697 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
698 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
699 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
700 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
701 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
702 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
703 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
704 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
705 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
706 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
707 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
708 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
709 bGMzUSs=
710 C:
711 S: . OK Success (tls protection)
712 The decoded challenge is:
714 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
715 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
716 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
717 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
718 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
719 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
720 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
721 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
722 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
723 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
724 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
725 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
726 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
727 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
728 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
729 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
730 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
731 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
732 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
733 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
734 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
735 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
736 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
737 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
738 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
740 Where the decoded SAMLRequest looks like:
742
749
750 https://xmpp.example.com
751
752
755
758
760 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
761
762
763
765 7. Security Considerations
767 This section addresses only security considerations associated with
768 the use of SAML with SASL applications. For considerations relating
769 to SAML in general, the reader is referred to the SAML specification
770 and to other literature. Similarly, for general SASL Security
771 Considerations, the reader is referred to that specification.
773 7.1. Man in the middle and Tunneling Attacks
775 This mechanism is vulnerable to man-in-the-middle and tunneling
776 attacks unless a client always verifies the server identity before
777 proceeding with authentication (see [RFC6125]). Typically TLS is
778 used to provide a secure channel with server authentication.
780 7.2. Binding SAML subject identifiers to Authorization Identities
782 As specified in [RFC4422], the server is responsible for binding
783 credentials to a specific authorization identity. It is therefore
784 necessary that only specific trusted IdPs be allowed. This is
785 typical part of SAML trust establishment between Relying Parties and
786 IdP.
788 7.3. User Privacy
790 The IdP is aware of each Relying Party that a user logs into. There
791 is nothing in the protocol to hide this information from the IdP. It
792 is not a requirement to track the visits, but there is nothing that
793 prohibits the collection of information. SASL server implementers
794 should be aware that SAML IdPs will be able to track - to some extent
795 - user access to their services.
797 7.4. Collusion between RPs
799 It is possible for Relying Parties to link data that they have
800 collected on the users. By using the same identifier to log into
801 every Relying Party, collusion between Relying Parties is possible.
802 In SAML, targeted identity was introduced. Targeted identity allows
803 the IdP to transform the identifier the user typed in to an opaque
804 identifier. This way the Relying Party would never see the actual
805 user identifier, but a randomly generated identifier.
807 8. IANA Considerations
809 8.1. IANA mech-profile
811 The IANA is requested to register the following SASL profile:
813 SASL mechanism profile: SAML20
815 Security Considerations: See this document
817 Published Specification: See this document
819 For further information: Contact the authors of this document.
821 Owner/Change controller: the IETF
823 Note: None
825 8.2. IANA OID
827 The IANA is further requested to assign an OID for this GSS mechanism
828 in the SMI numbers registry, with the prefix of
829 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
830 reference this specification in the registry.
832 9. References
834 9.1. Normative References
836 [OASIS.saml-bindings-2.0-os]
837 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
838 Maler, "Bindings for the OASIS Security Assertion Markup
839 Language (SAML) V2.0", OASIS
840 Standard saml-bindings-2.0-os, March 2005.
842 [OASIS.saml-core-2.0-os]
843 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
844 "Assertions and Protocol for the OASIS Security Assertion
845 Markup Language (SAML) V2.0", OASIS Standard saml-core-
846 2.0-os, March 2005.
848 [OASIS.saml-profiles-2.0-os]
849 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
850 P., Philpott, R., and E. Maler, "Profiles for the OASIS
851 Security Assertion Markup Language (SAML) V2.0", OASIS
852 Standard OASIS.saml-profiles-2.0-os, March 2005.
854 [RFC1035] Mockapetris, P., "Domain names - implementation and
855 specification", STD 13, RFC 1035, November 1987.
857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
858 Requirement Levels", BCP 14, RFC 2119, March 1997.
860 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
861 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
862 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
864 [RFC2743] Linn, J., "Generic Security Service Application Program
865 Interface Version 2, Update 1", RFC 2743, January 2000.
867 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
869 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
870 Resource Identifier (URI): Generic Syntax", STD 66,
871 RFC 3986, January 2005.
873 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
874 Security Layer (SASL)", RFC 4422, June 2006.
876 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
877 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
879 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
880 Housley, R., and W. Polk, "Internet X.509 Public Key
881 Infrastructure Certificate and Certificate Revocation List
882 (CRL) Profile", RFC 5280, May 2008.
884 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
885 Service Application Program Interface (GSS-API) Mechanisms
886 in Simple Authentication and Security Layer (SASL): The
887 GS2 Mechanism Family", RFC 5801, July 2010.
889 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
890 Verification of Domain-Based Application Service Identity
891 within Internet Public Key Infrastructure Using X.509
892 (PKIX) Certificates in the Context of Transport Layer
893 Security (TLS)", RFC 6125, March 2011.
895 [W3C.REC-html401-19991224]
896 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01
897 Specification", World Wide Web Consortium
898 Recommendation REC-html401-19991224, December 1999,
899 .
901 9.2. Informative References
903 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
904 STD 53, RFC 1939, May 1996.
906 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
907 4rev1", RFC 3501, March 2003.
909 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
910 Encodings", RFC 4648, October 2006.
912 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
913 Protocol (XMPP): Core", RFC 6120, March 2011.
915 Appendix A. Acknowledgments
917 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
918 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank
919 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their
920 review and contributions.
922 Appendix B. Changes
924 This section to be removed prior to publication.
926 o 08 Fixed text per Gen-Art review
928 o 07 Fixed text per comments Alexey Melnikov
930 o 06 Fixed text per AD comments
932 o 05 Fixed references per ID-nits
934 o 04 Added request for IANA assignment, few text clarifications
936 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov
938 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos
940 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott
941 Cantor
943 o 01 Added authorization identity, added GSS-API specifics, added
944 client supplied IdP
946 o 00 Initial Revision.
948 Authors' Addresses
950 Klaas Wierenga
951 Cisco Systems, Inc.
952 Haarlerbergweg 13-19
953 Amsterdam, Noord-Holland 1101 CH
954 Netherlands
956 Phone: +31 20 357 1752
957 Email: klaas@cisco.com
959 Eliot Lear
960 Cisco Systems GmbH
961 Richtistrasse 7
962 Wallisellen, ZH CH-8304
963 Switzerland
965 Phone: +41 44 878 9200
966 Email: lear@cisco.com
968 Simon Josefsson
969 SJD AB
970 Hagagatan 24
971 Stockholm 113 47
972 SE
974 Email: simon@josefsson.org
975 URI: http://josefsson.org/