idnits 2.17.1
draft-ietf-kitten-sasl-saml-07.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 5, 2012) is 4489 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 8, 2012 Cisco Systems GmbH
6 S. Josefsson
7 SJD AB
8 January 5, 2012
10 A SASL and GSS-API Mechanism for SAML
11 draft-ietf-kitten-sasl-saml-07.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 8, 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 . . . . . . . . . . . . . . . . . . 9
64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 22
72 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 22
73 7.2. Binding SAML subject identifiers to Authorization
74 Identities . . . . . . . . . . . . . . . . . . . . . . . . 22
75 7.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
76 7.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 22
77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
80 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
82 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 27
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
85 1. Introduction
87 Security Assertion Markup Language (SAML) 2.0
88 [OASIS.saml-core-2.0-os] is a modular specification that provides
89 various means for a user to be identified to a relying party (RP)
90 through the exchange of (typically signed) assertions issued by an
91 identity provider (IdP). It includes a number of protocols, protocol
92 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
93 [OASIS.saml-profiles-2.0-os] designed for different use cases.
95 Simple Authentication and Security Layer (SASL) [RFC4422] is a
96 generalized mechanism for identifying and authenticating a user and
97 for optionally negotiating a security layer for subsequent protocol
98 interactions. SASL is used by application protocols like IMAP
99 [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make
100 modular authentication, so that newer authentication mechanisms can
101 be added as needed. This memo specifies just such a mechanism.
103 The Generic Security Service Application Program Interface (GSS-API)
104 [RFC2743] provides a framework for applications to support multiple
105 authentication mechanisms through a unified programming interface.
106 This document defines a pure SASL mechanism for SAML, but it conforms
107 to the new bridge between SASL and the GSS-API called GS2 [RFC5801].
108 This means that this document defines both a SASL mechanism and a
109 GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL
110 implementers, and the GSS-API considerations can be avoided in
111 environments that use SASL directly without GSS-API.
113 As currently envisioned, this mechanism is to allow the interworking
114 between SASL and SAML in order to assert identity and other
115 attributes to relying parties. As such, while servers (as relying
116 parties) will advertise SASL mechanisms (including SAML), clients
117 will select the SAML SASL mechanism as their SASL mechanism of
118 choice.
120 The SAML mechanism described in this memo aims to re-use the Web
121 Browser SSO profile defined in section 3.1 of the SAML profiles 2.0
122 specification [OASIS.saml-profiles-2.0-os] to the maximum extent and
123 therefore does not establish a separate authentication, integrity and
124 confidentiality mechanism. The mechanism assumes a security layer,
125 such as Transport Layer Security (TLS [RFC5246]), will continue to be
126 used. This specification is appropriate for use when a browser is
127 available.
129 Figure 1 describes the interworking between SAML and SASL: this
130 document requires enhancements to the Relying Party (the SASL server)
131 and to the Client, as the two SASL communication end points, but no
132 changes to the SAML Identity Provider are necessary. To accomplish
133 this goal some indirect messaging is tunneled within SASL, and some
134 use of external methods is made.
136 +-----------+
137 | |
138 >| Relying |
139 / | Party |
140 // | |
141 // +-----------+
142 SAML/ // ^
143 HTTPs // +--|--+
144 // | S| |
145 / S | A| |
146 // A | M| |
147 // S | L| |
148 // L | | |
149 // | | |
150 +--|--+
151 +------------+ v
152 | | +----------+
153 | SAML | HTTPs | |
154 | Identity |<--------------->| Client |
155 | Provider | | |
156 +------------+ +----------+
158 Figure 1: Interworking Architecture
160 1.1. Terminology
162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
164 document are to be interpreted as described in RFC 2119 [RFC2119].
166 The reader is assumed to be familiar with the terms used in the SAML
167 2.0 specification.
169 1.2. Applicability
171 Because this mechanism transports information that should not be
172 controlled by an attacker, the SAML mechanism MUST only be used over
173 channels protected by TLS, and the client MUST successfully validate
174 the server certificate, or similar integrity protected and
175 authenticated channels. [RFC5280][RFC6125]
176 Note: An Intranet does not constitute such an integrity protected and
177 authenticated channel!
179 2. Authentication flow
181 While SAML itself is merely a markup language, its common use case
182 these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML
183 [W3C.REC-html401-19991224]. What follows is a typical flow:
185 1. The browser requests a resource of a Relying Party (RP) (via an
186 HTTP request).
188 2. The Relying Party redirects the browser via an HTTP redirect (as
189 described in Section 10.3 of [RFC2616]) to the Identity Provider
190 (IdP) or an IdP discovery service with as parameters an
191 authentication request that contains the name of resource being
192 requested, a browser cookie and a return URL as specified in
193 Section 3.1 of the SAML profiles 2.0 specification
194 [OASIS.saml-profiles-2.0-os].
196 3. The user authenticates to the IdP and perhaps authorizes the
197 authentication to the service provider.
199 4. In its authentication response, the IdP redirects (via an HTTP
200 redirect) the browser back to the RP with an authentication
201 assertion (stating that the IdP vouches that the subject has
202 successfully authenticated), optionally along with some
203 additional attributes.
205 5. The Relying Party now has sufficient identity information to
206 approve access to the resource or not, and acts accordingly. The
207 authentication is concluded.
209 When considering this flow in the context of SASL, we note that while
210 the Relying Party and the client both must change their code to
211 implement this SASL mechanism, the IdP can remain untouched. The
212 Relying Party already has some sort of session (probably a TCP
213 connection) established with the client. However, it may be
214 necessary to redirect a SASL client to another application or
215 handler. This will be discussed below. The steps are shown from
216 below:
218 1. The SASL server (Relying Party) advertises support for the SASL
219 SAML20 mechanism to the client
221 2. The client initiates a SASL authentication with SAML20 and sends
222 a domain name that allows the SASL server to determine the
223 appropriate IdP
225 3. The SASL server transmits an authentication request encoded using
226 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:
264 SASL Serv. Client IdP
265 |>-----(1)----->| | Advertisement
266 | | |
267 |<-----(2)-----<| | Initiation
268 | | |
269 |>-----(3)----->| | Authentication Request
270 | | |
271 |<-----(4)-----<| | Empty Response
272 | | |
273 | |< - - - - - ->| Client<>IDP
274 | | | Authentication
275 | | |
276 |<- - - - - - - - - - - - - - -| Authentication Statement
277 | | |
278 |>-----(5)----->| | 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.
290 Recall section 5 of [RFC4422] for what needs to be described here.
292 The name of this mechanism "SAML20". The mechanism is capable of
293 transferring an authorization identity (via "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" described below. As
298 described in [RFC4422], if the application protocol does not support
299 sending a client-response together with the authentication request,
300 the server will send an empty server-challenge to let the client
301 begin.
303 The second mechanism message is from the server to the client, the
304 "authentication-request" described below.
306 The third mechanism message is from client to the server, and is the
307 fixed message consisting of "=".
309 The fourth mechanism message is from the server to the client,
310 indicating the SASL mechanism outcome described below.
312 3.1. Initial Response
314 A client initiates a "SAML20" authentication with SASL by sending the
315 GS2 header followed by the authentication identifier (message 2 in
316 Figure 2). The GS2 header carries the optional authorization
317 identity.
319 initial-response = gs2-header Idp-Identifier
320 IdP-Identifier = domain ; domain name with corresponding IdP
322 The "gs2-header" is specified in [RFC5801], and it is used as
323 follows. The "gs2-nonstd-flag" MUST NOT be present. Regarding the
324 channel binding "gs2-cb-flag" field, see Section 5. The "gs2-
325 authzid" carries the optional authorization identity. Domain name is
326 specified in [RFC1035].
328 3.2. Authentication Request
330 The SASL Server transmits to the SASL client a URI that (re)directs
331 to the IdP (corresponding to the domain the user provided), with a
332 SAML authentication request as one of the parameters (message 3 in
333 Figure 2).
335 Note: The SASL server may have a static mapping of domain to
336 corresponding IdP or alternatively a DNS-lookup mechanism could be
337 envisioned, but that is out-of-scope for this document.
339 Note: While the SASL client MAY sanity check the URI it received,
340 ultimately it is the SAML IdP that will be validated by the SAML
341 client which is out-of-scope for this document.
343 authentication-request = URI
345 URI is specified in [RFC3986] and is encoded according to Section 3.4
346 (HTTP Redirect) of the SAML bindings 2.0 specification
347 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is
348 encoded according to Section 3.4 (Authentication Request) of the SAML
349 core 2.0 specification [OASIS.saml-core-2.0-os].
351 The client now sends the authentication request via an HTTP GET (sent
352 over a server-authenticated TLS channel) to the IdP, as if redirected
353 to do so from an HTTP server and in accordance with the Web Browser
354 SSO profile, as described in section 3.1 of SAML profiles 2.0
355 specification [OASIS.saml-profiles-2.0-os]
357 The client handles both user authentication to the IdP and
358 confirmation or rejection of the authentiation of the RP (out-of-
359 scope for this document).
361 After all authentication has been completed by the IdP, the IdP will
362 send a redirect message to the client in the form of a URI
363 corresponding to the Relying Party as specified in the authentication
364 request ("AssertionConsumerServiceURL") and with the SAML response as
365 one of the parameters.
367 Please note: this means that the SASL server needs to implement a
368 SAML Relying Party. Also, the SASL server needs to correlate the TCP
369 session from the SASL client with the SAML authentication.
371 3.3. Outcome and parameters
373 The SASL server now validates the response it received from the
374 client via HTTP or HTTPS, as specified in the SAML specification
376 The response by the SASL server constitutes a SASL mechanism outcome,
377 and SHALL be used to set state in the server accordingly, and it
378 shall be used by the server to report that state to the SASL client
379 as described in [RFC4422] Section 3.6 (message 5 in Figure 2).
381 4. SAML GSS-API Mechanism Specification
383 This section and its sub-sections and appropriate references of it
384 not referenced elsewhere in this document are not required for SASL
385 implementors, but this section MUST be observed to implement the GSS-
386 API mechanism discussed below.
388 The SAML SASL mechanism is actually also a GSS-API mechanism. The
389 SAML user takes the role of the GSS-API Initiator and the SAML
390 Relying Party takes the role of the GSS-API Acceptor. The SAML
391 Identity Provider does not have a role in GSS-API, and is considered
392 an internal matter for the SAML mechanism.The messages are the same,
393 but
395 a) the GS2 header on the client's first message and channel binding
396 data is excluded when SAML is used as a GSS-API mechanism, and
398 b) the RFC2743 section 3.1 initial context token header is prefixed
399 to the client's first authentication message (context token).
401 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see
402 IANA considerations).
404 SAML20 security contexts MUST have the mutual_state flag
405 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
406 delegation, therefore SAML security contexts MUST have the
407 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
409 The mutual authentication property of this mechanism relies on
410 successfully comparing the TLS server identity with the negotiated
411 target name. Since the TLS channel is managed by the application
412 outside of the GSS-API mechanism, the mechanism itself is unable to
413 confirm the name while the application is able to perform this
414 comparison for the mechanism. For this reason, applications MUST
415 match the TLS server identity with the target name, as discussed in
416 [RFC6125].
418 The SAML mechanism does not support per-message tokens or
419 GSS_Pseudo_random.
421 4.1. GSS-API Principal Name Types for SAML
423 SAML supports standard generic name syntaxes for acceptors such as
424 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML
425 supports only a single name type for initiators: GSS_C_NT_USER_NAME.
426 GSS_C_NT_USER_NAME is the default name type for SAML. The query,
427 display, and exported name syntaxes for SAML principal names are all
428 the same. There are no SAML-specific name syntaxes -- applications
429 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
430 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported
431 name token does, of course, conform to [RFC2743], Section 3.2.
433 5. Channel Binding
435 The "gs2-cb-flag" MUST use "n" because channel binding data cannot be
436 integrity protected by the SAML negotiation.
438 Note: In theory channel binding data could be inserted in the SAML
439 flow by the client and verified by the server, but that is currently
440 not supported in SAML.
442 6. Examples
444 6.1. XMPP
446 Suppose the user has an identity at the SAML IdP saml.example.org and
447 a Jabber Identifier (JID) "somenode@example.com", and wishes to
448 authenticate his XMPP connection to xmpp.example.com. The
449 authentication on the wire would then look something like the
450 following:
452 Step 1: Client initiates stream to server:
454
458 Step 2: Server responds with a stream tag sent to client:
460
464 Step 3: Server informs client of available authentication mechanisms:
466
467
468 DIGEST-MD5
469 PLAIN
470 SAML20
471
472
474 Step 4: Client selects an authentication mechanism and provides the
475 initial client response containing the BASE64 [RFC4648] encoded gs2-
476 header and domain:
478
479 biwsZXhhbXBsZS5vcmc
481 The decoded string is: n,,example.org
482 Step 5: Server sends a BASE64 encoded challenge to client in the form
483 of an HTTP Redirect to the SAML IdP corresponding to example.org
484 (https://saml.example.org) with the SAML Authentication Request as
485 specified in the redirection url:
487 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
488 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
489 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
490 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
491 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
492 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
493 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
494 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
495 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
496 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
497 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
498 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
499 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
500 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
501 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
502 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
503 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
504 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
505 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
506 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
507 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
508 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
509 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
510 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
511 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
512 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
513 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
514 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
515 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
516 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
517 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
518 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
519 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
520 bGMzUSs=
522 The decoded challenge is:
524 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
525 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
526 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
527 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
528 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
529 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
530 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
531 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
532 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
533 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
534 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
535 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
536 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
537 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
538 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
539 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
540 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
541 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
542 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
543 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
544 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
545 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
546 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
547 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
548 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
550 Where the decoded SAMLRequest looks like:
552
559
560 https://xmpp.example.com
561
562
565
568
570 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
571
572
573
575 Note: the server can use the request ID
576 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL
577 session with the SAML authentication.
579 Step 5 (alt): Server returns error to client:
581
582
583
584
586 Step 6: Client sends the empty response to the challenge encoded as a
587 single =:
589
590 =
591
593 [ The client now sends the URL to a browser for processing. The
594 browser engages in a normal SAML authentication flow (external to
595 SASL), like redirection to the Identity Provider
596 (https://saml.example.org), the user logs into
597 https://saml.example.org, and agrees to authenticate to
598 xmpp.example.com. A redirect is passed back to the client browser
599 who sends the AuthN response to the server, containing the subject-
600 identifier as an attribute. If the AuthN response doesn't contain
601 the JID, the server maps the subject-identifier received from the IdP
602 to a JID]
604 Step 7: Server informs client of successful authentication:
606
608 Step 7 (alt): Server informs client of failed authentication:
610
611
612
613
615 Step 8: Client initiates a new stream to server:
617
621 Step 9: Server responds by sending a stream header to client along
622 with any additional features (or an empty features element):
624
627
628
629
630
632 Step 10: Client binds a resource:
634
635
636 someresource
637
638
640 Step 11: Server informs client of successful resource binding:
642
643
644 somenode@example.com/someresource
645
646
648 Please note: line breaks were added to the base64 for clarity.
650 6.2. IMAP
652 The following describes an IMAP exchange. Lines beginning with 'S:'
653 indicate data sent by the server, and lines starting with 'C:'
654 indicate data sent by the client. Long lines are wrapped for
655 readability.
657 S: * OK IMAP4rev1
658 C: . CAPABILITY
659 S: * CAPABILITY IMAP4rev1 STARTTLS
660 S: . OK CAPABILITY Completed
661 C: . STARTTLS
662 S: . OK Begin TLS negotiation now
663 C: . CAPABILITY
664 S: * CAPABILITY IMAP4rev1 AUTH=SAML20
665 S: . OK CAPABILITY Completed
666 C: . AUTHENTICATE SAML20
667 S: +
668 C: biwsZXhhbXBsZS5vcmc
669 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
670 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
671 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
672 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
673 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
674 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
675 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
676 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
677 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
678 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
679 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
680 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
681 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
682 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
683 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
684 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
685 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
686 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
687 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
688 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
689 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
690 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
691 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
692 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
693 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
694 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
695 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
696 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
697 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
698 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
699 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
700 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
701 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
702 bGMzUSs=
703 C:
704 S: . OK Success (tls protection)
706 7. Security Considerations
708 This section will address only security considerations associated
709 with the use of SAML with SASL applications. For considerations
710 relating to SAML in general, the reader is referred to the SAML
711 specification and to other literature. Similarly, for general SASL
712 Security Considerations, the reader is referred to that
713 specification.
715 7.1. Man in the middle and Tunneling Attacks
717 This mechanism is vulnerable to man-in-the-middle and tunneling
718 attacks unless a client always verify the server identity before
719 proceeding with authentication (see [RFC6125]). Typically TLS is
720 used to provide a secure channel with server authentication.
722 7.2. Binding SAML subject identifiers to Authorization Identities
724 As specified in [RFC4422], the server is responsible for binding
725 credentials to a specific authorization identity. It is therefore
726 necessary that only specific trusted IdPs be allowed. This is
727 typical part of SAML trust establishment between Relying Parties and
728 IdP.
730 7.3. User Privacy
732 The IdP is aware of each Relying Party that a user logs into. There
733 is nothing in the protocol to hide this information from the IdP. It
734 is not a requirement to track the visits, but there is nothing that
735 prohibits the collection of information. SASL servers should be
736 aware that SAML IdPs will track - to some extent - user access to
737 their services.
739 7.4. Collusion between RPs
741 It is possible for Relying Parties to link data that they have
742 collected on you. By using the same identifier to log into every
743 Relying Party, collusion between Relying Parties is possible. In
744 SAML, targeted identity was introduced. Targeted identity allows the
745 IdP to transform the identifier the user typed in to an opaque
746 identifier. This way the Relying Party would never see the actual
747 user identifier, but a randomly generated identifier. This is an
748 option the user has to understand and decide to use if the IdP is
749 supporting it.
751 8. IANA Considerations
753 The IANA is requested to register the following SASL profile:
755 SASL mechanism profile: SAML20
757 Security Considerations: See this document
759 Published Specification: See this document
761 For further information: Contact the authors of this document.
763 Owner/Change controller: the IETF
765 Note: None
767 The IANA is further requested to assign an OID for this GSS mechanism
768 in the SMI numbers registry, with the prefix of
769 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
770 reference this specification in the registry.
772 9. References
774 9.1. Normative References
776 [OASIS.saml-bindings-2.0-os]
777 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
778 Maler, "Bindings for the OASIS Security Assertion Markup
779 Language (SAML) V2.0", OASIS
780 Standard saml-bindings-2.0-os, March 2005.
782 [OASIS.saml-core-2.0-os]
783 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
784 "Assertions and Protocol for the OASIS Security Assertion
785 Markup Language (SAML) V2.0", OASIS Standard saml-core-
786 2.0-os, March 2005.
788 [OASIS.saml-profiles-2.0-os]
789 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
790 P., Philpott, R., and E. Maler, "Profiles for the OASIS
791 Security Assertion Markup Language (SAML) V2.0", OASIS
792 Standard OASIS.saml-profiles-2.0-os, March 2005.
794 [RFC1035] Mockapetris, P., "Domain names - implementation and
795 specification", STD 13, RFC 1035, November 1987.
797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
798 Requirement Levels", BCP 14, RFC 2119, March 1997.
800 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
801 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
802 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
804 [RFC2743] Linn, J., "Generic Security Service Application Program
805 Interface Version 2, Update 1", RFC 2743, January 2000.
807 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
809 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
810 Resource Identifier (URI): Generic Syntax", STD 66,
811 RFC 3986, January 2005.
813 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
814 Security Layer (SASL)", RFC 4422, June 2006.
816 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
817 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
819 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
820 Housley, R., and W. Polk, "Internet X.509 Public Key
821 Infrastructure Certificate and Certificate Revocation List
822 (CRL) Profile", RFC 5280, May 2008.
824 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
825 Service Application Program Interface (GSS-API) Mechanisms
826 in Simple Authentication and Security Layer (SASL): The
827 GS2 Mechanism Family", RFC 5801, July 2010.
829 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
830 Verification of Domain-Based Application Service Identity
831 within Internet Public Key Infrastructure Using X.509
832 (PKIX) Certificates in the Context of Transport Layer
833 Security (TLS)", RFC 6125, March 2011.
835 [W3C.REC-html401-19991224]
836 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01
837 Specification", World Wide Web Consortium
838 Recommendation REC-html401-19991224, December 1999,
839 .
841 9.2. Informative References
843 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
844 STD 53, RFC 1939, May 1996.
846 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
847 4rev1", RFC 3501, March 2003.
849 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
850 Encodings", RFC 4648, October 2006.
852 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
853 Protocol (XMPP): Core", RFC 6120, March 2011.
855 Appendix A. Acknowledgments
857 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
858 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank
859 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their
860 review and contributions.
862 Appendix B. Changes
864 This section to be removed prior to publication.
866 o 07 Fixed text per comments Alexey Melnikov
868 o 06 Fixed text per AD comments
870 o 05 Fixed references per ID-nits
872 o 04 Added request for IANA assignment, few text clarifications
874 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov
876 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos
878 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott
879 Cantor
881 o 01 Added authorization identity, added GSS-API specifics, added
882 client supplied IdP
884 o 00 Initial Revision.
886 Authors' Addresses
888 Klaas Wierenga
889 Cisco Systems, Inc.
890 Haarlerbergweg 13-19
891 Amsterdam, Noord-Holland 1101 CH
892 Netherlands
894 Phone: +31 20 357 1752
895 Email: klaas@cisco.com
897 Eliot Lear
898 Cisco Systems GmbH
899 Richtistrasse 7
900 Wallisellen, ZH CH-8304
901 Switzerland
903 Phone: +41 44 878 9200
904 Email: lear@cisco.com
906 Simon Josefsson
907 SJD AB
908 Hagagatan 24
909 Stockholm 113 47
910 SE
912 Email: simon@josefsson.org
913 URI: http://josefsson.org/