idnits 2.17.1
draft-ietf-kitten-sasl-saml-02.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 25, 2011) is 4807 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 informational reference (is this intentional?): RFC 3501
(Obsoleted by RFC 9051)
-- Obsolete informational reference (is this intentional?): RFC 3920
(Obsoleted by RFC 6120)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: August 29, 2011 Cisco Systems GmbH
6 S. Josefsson
7 SJD AB
8 February 25, 2011
10 A SASL and GSS-API Mechanism for SAML
11 draft-ietf-kitten-sasl-saml-02.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 August 29, 2011.
40 Copyright Notice
42 Copyright (c) 2011 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 3. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 6
60 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9
61 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9
62 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
63 4.3. Server Redirect . . . . . . . . . . . . . . . . . . . . . 9
64 4.4. Client Empty Response and other . . . . . . . . . . . . . 10
65 4.5. Outcome and parameters . . . . . . . . . . . . . . . . . . 10
66 5. SAML GSS-API Mechanism Specification . . . . . . . . . . . . . 11
67 5.1. GSS-API Principal Name Types for SAML . . . . . . . . . . 11
68 6. Channel Binding . . . . . . . . . . . . . . . . . . . . . . . 12
69 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
70 7.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
71 7.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
73 8.1. Man in the middle and Tunneling Attacks . . . . . . . . . 20
74 8.2. Binding SAML subject identifiers to Authorization
75 Identities . . . . . . . . . . . . . . . . . . . . . . . . 20
76 8.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 20
77 8.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 20
78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
81 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24
83 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
86 1. Introduction
88 Security Assertion Markup Language (SAML) 2.0
89 [OASIS.saml-core-2.0-os] is a modular specification that provides
90 various means for a user to be identified to a relying party (RP)
91 through the exchange of (typically signed) assertions issued by an
92 identity provider (IdP). It includes a number of protocols, protocol
93 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
94 [OASIS.saml-profiles-2.0-os] designed for different use cases.
96 Simple Authentication and Security Layer (SASL) [RFC4422] is a
97 generalized mechanism for identifying and authenticating a user and
98 for optionally negotiating a security layer for subsequent protocol
99 interactions. SASL is used by application protocols like IMAP
100 [RFC3501] and XMPP [RFC3920]. The effect is to make modular
101 authentication, so that newer authentication mechanisms can be added
102 as needed. This memo specifies just such a mechanism.
104 The Generic Security Service Application Program Interface (GSS-API)
105 [RFC2743] provides a framework for applications to support multiple
106 authentication mechanisms through a unified programming interface.
107 This document defines a pure SASL mechanism for SAML, but it conforms
108 to the new bridge between SASL and the GSS-API called GS2 [RFC5801].
109 This means that this document defines both a SASL mechanism and a
110 GSS-API mechanism. We want to point out that the GSS-API interface
111 is optional for SASL implementers, and the GSS-API considerations can
112 be avoided in environments that uses SASL directly without GSS-API.
114 As currently envisioned, this mechanism is to allow the interworking
115 between SASL and SAML in order to assert identity and other
116 attributes to relying parties. As such, while servers (as relying
117 parties) will advertise SASL mechanisms (including SAML), clients
118 will select the SAML SASL mechanism as their SASL mechanism of
119 choice.
121 The SAML mechanism described in this memo aims to re-use the
122 available SAML deployment to a maximum extent and therefore does not
123 establish a separate authentication, integrity and confidentiality
124 mechanism. The mechanisms assumes a security layer, such as
125 Transport Layer Security (TLS), to protect against some attacks.
127 Figure 1 describes the interworking between SAML and SASL: this
128 document requires enhancements to the Relying Party and to the Client
129 (as the two SASL communication end points) but no changes to the SAML
130 Identity Provider are necessary. To accomplish this goal some
131 indirect messaging is tunneled within SASL, and some use of external
132 methods is made.
134 +-----------+
135 | |
136 >| Relying |
137 / | Party |
138 // | |
139 // +-----------+
140 SAML/ // ^
141 HTTPs // +--|--+
142 // | S| |
143 / S | A| |
144 // A | M| |
145 // S | L| |
146 // L | | |
147 // | | |
148 +--|--+
149 +------------+ v
150 | | +----------+
151 | SAML | HTTPs | |
152 | Identity |<--------------->| Client |
153 | Provider | | |
154 +------------+ +----------+
156 Figure 1: Interworking Architecture
158 2. Terminology
160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
162 document are to be interpreted as described in RFC 2119 [RFC2119].
164 The reader is assumed to be familiar with the terms used in the SAML
165 2.0 specification.
167 3. Applicability for non-HTTP Use Cases
169 While SAML itself is merely a markup language, its common use case
170 these days is with HTTP. What follows is a typical flow:
172 1. The browser requests a resource of a Relying Party (RP) (via an
173 HTTP request).
175 2. The RP sends an HTTP redirect as described in Section 10.3 of
176 [RFC2616] to the browser to the Identity Provider (IdP) or an IdP
177 discovery service with an authentication request that contains
178 the name of resource being requested, some sort of a cookie and a
179 return URL,
181 3. The user authenticates to the IdP and perhaps authorizes the
182 authentication to the service provider.
184 4. In its authentication response, the IdP redirects the browser
185 back to the RP with an authentication assertion (stating that the
186 IdP vouches that the subject has successfully authenticated),
187 optionally along with some additional attributes.
189 5. RP now has sufficient identity information to approve access to
190 the resource or not, and acts accordingly. The authentication is
191 concluded.
193 When considering this flow in the context of SASL, we note that while
194 the RP and the client both must change their code to implement this
195 SASL mechanism, the IdP must remain untouched. The RP already has
196 some sort of session (probably a TCP connection) established with the
197 client. However, it may be necessary to redirect a SASL client to
198 another application or handler. This will be discussed below. The
199 steps are shown from below:
201 1. The Relying Party or SASL server advertises support for the SASL
202 SAML20 mechanism to the client
204 2. The client initiates a SASL authentication with SAML20 and sends
205 a domain
207 3. The Relying Party transmits an authentication request encoded
208 using a Universal Resource Identifier (URI) as described in RFC
209 3986 [RFC3986] and a redirect to the IdP corresponding to the
210 domain
212 4. The SASL client now sends an empty response, as authentication
213 continues via the normal SAML flow.
215 5. At this point the SASL client MUST construct a URL containing the
216 content received in the previous message from the RP. This URL
217 is transmitted to the IdP either by the SASL client application
218 or an appropriate handler, such as a browser.
220 6. Next the client authenticates to the IdP. The manner in which
221 the end user is authenticated to the IdP and any policies
222 surrounding such authentication is out of scope for SAML and
223 hence for this draft. This step happens out of band from SASL.
225 7. The IdP will convey information about the success or failure of
226 the authentication back to the the RP in the form of an
227 Authentication Statement or failure, using a indirect response
228 via the client browser or the handler. This step happens out of
229 band from SASL.
231 8. The SASL Server sends an appropriate SASL response to the client,
232 along with an optional list of attributes
234 Please note: What is described here is the case in which the client
235 has not previously authenticated. If the client can handle SAML
236 internally it is possible that the client already holds a valid SAML
237 authentication token so that the user does not need to be involved in
238 the process anymore, but that would still be external to SASL.
240 With all of this in mind, the flow appears as follows:
242 SASL Serv. Client IdP
243 |>-----(1)----->| | Advertisement
244 | | |
245 |<-----(2)-----<| | Initiation
246 | | |
247 |>-----(3)----->| | Authentication Request
248 | | |
249 |<-----(4)-----<| | Empty Response
250 | | |
251 | |< - - - - - ->| Client<>IDP
252 | | | Authentication
253 | | |
254 |<- - - - - - - - - - - - - - -| Authentication Statement
255 | | |
256 |>-----(6)----->| | SASL completion with
257 | | | status
258 | | |
260 ----- = SASL
261 - - - = HTTP or HTTPs (external to SASL)
263 Figure 2: Authentication flow
265 4. SAML SASL Mechanism Specification
267 Based on the previous figure, the following operations are performed
268 with the SAML SASL mechanism.
270 The mechanism is "client first" as discussed in section 3 of
271 [RFC4422] which means that the initial server challenge will be empty
272 if the protocol does not support an initial client response.
274 4.1. Advertisement
276 To advertise that a server supports SAML 2.0, during application
277 session initiation, it displays the name "SAML20" in the list of
278 supported SASL mechanisms.
280 4.2. Initiation
282 A client initiates a "SAML20" authentication with SASL by sending the
283 GS2 header followed by the authentication identifier. The GS2 header
284 carries the optional authorization identity.
286 initial-response = gs2-header Idp-Identifier
287 IdP-Identifier = domain ; domain name with corresponding IdP
289 The "gs2-header" is specified in [RFC5801], and it is used as
290 follows. The "gs2-nonstd-flag" MUST NOT be present. Regarding the
291 channel binding "gs2-cb-flag" field, see Section 5. The "gs2-
292 authzid" carries the optional authorization identity. Domain name is
293 specified in [RFC1035].
295 4.3. Server Redirect
297 The SASL Server transmits a URI to the IdP that corresponds to the
298 domain the user provided, with a SAML authentication request in the
299 form of a SAML assertion as one of the parameters. Note: The SASL
300 server may have a static mapping of domain to corresponding IdP or
301 alternatively a DNS-lookup mechanism could be envisioned, but that is
302 out-of-scope for this document
304 redirect-url = URI
306 As before, URI is specified in [RFC3986].
308 4.4. Client Empty Response and other
310 The SASL client hands the URI it received from the server in the
311 previous step to either a browser or other appropriate handler to
312 continue authentication externally while sending an empty response to
313 the SASL server. The URI is encoded according to Section 3.4 of the
314 SAML bindings 2.0 specification [OASIS.saml-bindings-2.0-os].
316 empty-response = ""
318 4.5. Outcome and parameters
320 The SAML authentication having completed externally, the SASL server
321 will transmit the outcome of the authentication exchange as success
322 or failure.
324 5. SAML GSS-API Mechanism Specification
326 This section and its sub-sections and all normative references of it
327 not referenced elsewhere in this document are INFORMATIONAL for SASL
328 implementors, but they are NORMATIVE for GSS-API implementors.
330 The SAML SASL mechanism is actually also a GSS-API mechanism. The
331 messages are the same, but
333 a) the GS2 header on the client's first message and channel binding
334 data is excluded when SAML is used as a GSS-API mechanism, and
336 b) the RFC2743 section 3.1 initial context token header is prefixed
337 to the client's first authentication message (context token).
339 The GSS-API mechanism OID for SAML is 1.3.6.1.4.1.11591.4.8.
341 SAML20 security contexts always have the mutual_state flag
342 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
343 delegation, therefore SAML security contexts alway have the
344 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
346 The SAML mechanism does not support per-message tokens or
347 GSS_Pseudo_random.
349 Note that the GSS-API mechanism MUST only be used by the client when
350 a secure channel with server authentication (e.g., TLS) is available.
352 5.1. GSS-API Principal Name Types for SAML
354 SAML supports standard generic name syntaxes for acceptors such as
355 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML
356 supports only a single name type for initiators: GSS_C_NT_USER_NAME.
357 GSS_C_NT_USER_NAME is the default name type for SAML. The query,
358 display, and exported name syntaxes for SAML principal names are all
359 the same. There are no SAML-specific name syntaxes -- applications
360 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
361 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported
362 name token does, of course, conform to [RFC2743], Section 3.2.
364 6. Channel Binding
366 The "gs2-cb-flag" MUST use "n" because channel binding data cannot be
367 integrity protected by the SAML negotiation. FIXME: Transfer channel
368 binding in SAML assertion?
370 7. Examples
372 7.1. XMPP
374 Suppose the user has an identity at the SAML IdP saml.example.org and
375 a Jabber Identifier (JID) "somenode@example.com", and wishes to
376 authenticate his XMPP connection to xmpp.example.com. The
377 authentication on the wire would then look something like the
378 following:
380 Step 1: Client initiates stream to server:
382
386 Step 2: Server responds with a stream tag sent to client:
388
392 Step 3: Server informs client of available authentication mechanisms:
394
395
396 DIGEST-MD5
397 PLAIN
398 SAML20
399
400
402 Step 4: Client selects an authentication mechanism and provides the
403 initial client response containing the BASE64 [RFC4648] encoded gs2-
404 header and domain:
406
407 biwsZXhhbXBsZS5vcmc
409 The decoded string is: n,,example.org
410 Step 5: Server sends a BASE64 encoded challenge to client in the form
411 of an HTTP Redirect to the SAML IdP corresponding to example.org
412 (https://saml.example.org) with the SAML Authentication Request as
413 specified in the redirection url:
415 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
416 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
417 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
418 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
419 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
420 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
421 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
422 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
423 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
424 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
425 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
426 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
427 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
428 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
429 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
430 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
431 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
432 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
433 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
434 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
435 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
436 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
437 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
438 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
439 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
440 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
441 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
442 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
443 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
444 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
445 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
446 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
447 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
448 bGMzUSs=
450 The decoded challenge is:
452 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
453 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
454 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
455 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
456 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
457 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
458 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
459 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
460 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
461 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
462 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
463 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
464 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
465 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
466 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
467 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
468 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
469 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
470 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
471 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
472 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
473 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
474 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
475 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
476 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
478 Where the decoded SAMLRequest looks like:
480
487
488 https://xmpp.example.com
489
490
493
496
498 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
499
500
501
503 Step 5 (alt): Server returns error to client:
505
506
507
508
510 Step 6: Client sends a BASE64 encoded empty response to the
511 challenge:
513
514 =
515
517 [ The client now sends the URL to a browser for processing. The
518 browser engages in a normal SAML authentication flow (external to
519 SASL), like redirection to the Identity Provider
520 (https://saml.example.org), the user logs into
521 https://saml.example.org, and agrees to authenticate to
522 xmpp.example.com. A redirect is passed back to the client browser
523 who sends the AuthN response to the server, containing the subject-
524 identifier as an attribute. If the AuthN response doesn't contain
525 the JID, the server maps the subject-identifier received from the IdP
526 to a JID]
528 Step 7: Server informs client of successful authentication:
530
532 Step 7 (alt): Server informs client of failed authentication:
534
535
536
537
539 Step 8: Client initiates a new stream to server:
541
545 Step 9: Server responds by sending a stream header to client along
546 with any additional features (or an empty features element):
548
551
552
553
554
556 Step 10: Client binds a resource:
558
559
560 someresource
561
563
565 Step 11: Server informs client of successful resource binding:
567
568
569 somenode@example.com/someresource
570
571
573 Please note: line breaks were added to the base64 for clarity.
575 7.2. IMAP
577 The following describes an IMAP exchange. Lines beginning with 'S:'
578 indicate data sent by the server, and lines starting with 'C:'
579 indicate data sent by the client. Long lines are wrapped for
580 readability.
582 S: * OK IMAP4rev1
583 C: . CAPABILITY
584 S: * CAPABILITY IMAP4rev1 STARTTLS
585 S: . OK CAPABILITY Completed
586 C: . STARTTLS
587 S: . OK Begin TLS negotiation now
588 C: . CAPABILITY
589 S: * CAPABILITY IMAP4rev1 AUTH=SAML20
590 S: . OK CAPABILITY Completed
591 C: . AUTHENTICATE SAML20
592 S: +
593 C: biwsZXhhbXBsZS5vcmc
594 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
595 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
596 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
597 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
598 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
599 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
600 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
601 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
602 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
603 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
604 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
605 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
606 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
607 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
608 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
609 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
610 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
611 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
612 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
613 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
614 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
615 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
616 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
617 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
618 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
619 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
620 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
621 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
622 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
623 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
624 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
625 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
626 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
627 bGMzUSs=
628 C:
629 S: . OK Success (tls protection)
631 8. Security Considerations
633 This section will address only security considerations associated
634 with the use of SAML with SASL applications. For considerations
635 relating to SAML in general, the reader is referred to the SAML
636 specification and to other literature. Similarly, for general SASL
637 Security Considerations, the reader is referred to that
638 specification.
640 8.1. Man in the middle and Tunneling Attacks
642 This mechanism is vulnerable to man in the middle and tunneling
643 attacks unless a client always verify the server identity before
644 proceeding with authentication. Typically TLS is used to provide a
645 secure channel with server authentication.
647 8.2. Binding SAML subject identifiers to Authorization Identities
649 As specified in [RFC4422], the server is responsible for binding
650 credentials to a specific authorization identity. It is therefore
651 necessary that only specific trusted IdPs be allowed. This is
652 typical part of SAML trust establishment between RP's and IdP.
654 8.3. User Privacy
656 The IdP is aware of each RP that a user logs into. There is nothing
657 in the protocol to hide this information from the IdP. It is not a
658 requirement to track the visits, but there is nothing that prohibits
659 the collection of information. SASL servers should be aware that
660 SAML IdPs will track - to some extent - user access to their
661 services.
663 8.4. Collusion between RPs
665 It is possible for RPs to link data that they have collected on you.
666 By using the same identifier to log into every RP, collusion between
667 RPs is possible. In SAML, targeted identity was introduced.
668 Targeted identity allows the IdP to transform the identifier the user
669 typed in to an opaque identifier. This way the RP would never see
670 the actual user identifier, but a randomly generated identifier.
671 This is an option the user has to understand and decide to use if the
672 IdP is supporting it.
674 9. IANA Considerations
676 The IANA is requested to register the following SASL profile:
678 SASL mechanism profile: SAML20
680 Security Considerations: See this document
682 Published Specification: See this document
684 For further information: Contact the authors of this document.
686 Owner/Change controller: the IETF
688 Note: None
690 10. References
692 10.1. Normative References
694 [OASIS.saml-bindings-2.0-os]
695 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
696 Maler, "Bindings for the OASIS Security Assertion Markup
697 Language (SAML) V2.0", OASIS
698 Standard saml-bindings-2.0-os, March 2005.
700 [OASIS.saml-core-2.0-os]
701 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
702 "Assertions and Protocol for the OASIS Security Assertion
703 Markup Language (SAML) V2.0", OASIS Standard saml-core-
704 2.0-os, March 2005.
706 [OASIS.saml-profiles-2.0-os]
707 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
708 P., Philpott, R., and E. Maler, "Profiles for the OASIS
709 Security Assertion Markup Language (SAML) V2.0", OASIS
710 Standard OASIS.saml-profiles-2.0-os, March 2005.
712 [RFC1035] Mockapetris, P., "Domain names - implementation and
713 specification", STD 13, RFC 1035, November 1987.
715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
716 Requirement Levels", BCP 14, RFC 2119, March 1997.
718 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
719 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
720 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
722 [RFC2743] Linn, J., "Generic Security Service Application Program
723 Interface Version 2, Update 1", RFC 2743, January 2000.
725 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
726 Resource Identifier (URI): Generic Syntax", STD 66,
727 RFC 3986, January 2005.
729 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
730 Security Layer (SASL)", RFC 4422, June 2006.
732 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
733 Encodings", RFC 4648, October 2006.
735 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
736 Service Application Program Interface (GSS-API) Mechanisms
737 in Simple Authentication and Security Layer (SASL): The
738 GS2 Mechanism Family", RFC 5801, July 2010.
740 10.2. Informative References
742 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
743 4rev1", RFC 3501, March 2003.
745 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
746 Protocol (XMPP): Core", RFC 3920, October 2004.
748 Appendix A. Acknowledgments
750 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
751 Howlett, Leif Johansson, Diego Lopez, Hank Mauldin, RL 'Bob' Morgan,
752 Stefan Plug and Hannes Tschofenig for their review and contributions.
754 Appendix B. Changes
756 This section to be removed prior to publication.
758 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos
760 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott
761 Cantor
763 o 01 Added authorization identity, added GSS-API specifics, added
764 client supplied IdP
766 o 00 Initial Revision.
768 Authors' Addresses
770 Klaas Wierenga
771 Cisco Systems, Inc.
772 Haarlerbergweg 13-19
773 Amsterdam, Noord-Holland 1101 CH
774 Netherlands
776 Phone: +31 20 357 1752
777 Email: klaas@cisco.com
779 Eliot Lear
780 Cisco Systems GmbH
781 Richtistrasse 7
782 Wallisellen, ZH CH-8304
783 Switzerland
785 Phone: +41 44 878 9200
786 Email: lear@cisco.com
788 Simon Josefsson
789 SJD AB
790 Hagagatan 24
791 Stockholm 113 47
792 SE
794 Email: simon@josefsson.org
795 URI: http://josefsson.org/