idnits 2.17.1 draft-ietf-kitten-sasl-saml-05.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 (October 31, 2011) is 4560 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: May 3, 2012 Cisco Systems GmbH 6 S. Josefsson 7 SJD AB 8 October 31, 2011 10 A SASL and GSS-API Mechanism for SAML 11 draft-ietf-kitten-sasl-saml-05.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 May 3, 2012. 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 61 3. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 8 62 3.1. Initial Response . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 8 64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 9 65 4. SAML GSS-API Mechanism Specification . . . . . . . . . . . . . 10 66 4.1. GSS-API Principal Name Types for SAML . . . . . . . . . . 10 67 5. Channel Binding . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 19 73 7.2. Binding SAML subject identifiers to Authorization 74 Identities . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 19 76 7.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 19 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 82 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 24 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 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. We want to point out that the GSS-API interface 110 is optional for SASL implementers, and the GSS-API considerations can 111 be avoided in environments that uses 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 122 [OASIS.saml-profiles-2.0-os] to a maximum extent and therefore does 123 not establish a separate authentication, integrity and 124 confidentiality mechanism. The mechanisms assumes a security layer, 125 such as Transport Layer Security (TLS [RFC5246]), will continued to 126 be 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 and to the Client 131 (as the two SASL communication end points) but no changes to the SAML 132 Identity Provider are necessary. To accomplish this goal some 133 indirect messaging is tunneled within SASL, and some use of external 134 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 | 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 Applicability Because this mechanism transports information that 172 should not be controlled by an attacker, the SAML mechanism MUST only 173 be used over channels protected by TLS, and the client MUST 174 successfully validate the server certificate, or similar integrity 175 protected and authenticated channels. [RFC5280][RFC6125] 177 2. Applicability for non-HTTP Use Cases 179 While SAML itself is merely a markup language, its common use case 180 these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML 181 [W3C.REC-html401-19991224]. What follows is a typical flow: 183 1. The browser requests a resource of a Relying Party (RP) (via an 184 HTTP request). 186 2. The RP sends an HTTP redirect as described in Section 10.3 of 187 [RFC2616] to the browser to the Identity Provider (IdP) or an IdP 188 discovery service with an authentication request that contains 189 the name of resource being requested, some sort of a cookie and a 190 return URL [RFC3986], 192 3. The user authenticates to the IdP and perhaps authorizes the 193 authentication to the service provider. 195 4. In its authentication response, the IdP redirects (via an HTTP 196 redirect) the browser back to the RP with an authentication 197 assertion (stating that the IdP vouches that the subject has 198 successfully authenticated), optionally along with some 199 additional attributes. 201 5. RP now has sufficient identity information to approve access to 202 the resource or not, and acts accordingly. The authentication is 203 concluded. 205 When considering this flow in the context of SASL, we note that while 206 the RP and the client both must change their code to implement this 207 SASL mechanism, the IdP must remain untouched. The RP already has 208 some sort of session (probably a TCP connection) established with the 209 client. However, it may be necessary to redirect a SASL client to 210 another application or handler. This will be discussed below. The 211 steps are shown from below: 213 1. The Relying Party or SASL server advertises support for the SASL 214 SAML20 mechanism to the client 216 2. The client initiates a SASL authentication with SAML20 and sends 217 a domain 219 3. The Relying Party transmits an authentication request encoded 220 using a Universal Resource Identifier (URI) as described in RFC 221 3986 [RFC3986] and an HTTP redirect to the IdP corresponding to 222 the domain 224 4. The SASL client now sends an empty response, as authentication 225 continues via the normal SAML flow. 227 5. At this point the SASL client MUST construct a URL containing the 228 content received in the previous message from the RP. This URL 229 is transmitted to the IdP either by the SASL client application 230 or an appropriate handler, such as a browser. 232 6. Next the client authenticates to the IdP. The manner in which 233 the end user is authenticated to the IdP and any policies 234 surrounding such authentication is out of scope for SAML and 235 hence for this draft. This step happens out of band from SASL. 237 7. The IdP will convey information about the success or failure of 238 the authentication back to the the RP in the form of an 239 Authentication Statement or failure, using a indirect response 240 via the client browser or the handler (and with an external 241 browser client control should be passed back to the SASL client). 242 This step happens out of band from SASL. 244 8. The SASL Server sends an appropriate SASL response to the client, 245 along with an optional list of attributes 247 Please note: What is described here is the case in which the client 248 has not previously authenticated. It is possible that the client 249 already holds a valid SAML authentication token so that the user does 250 not need to be involved in the process anymore, but that would still 251 be external to SASL. This is classic Web Single Sign-On, in which 252 the Web Browser client presents the authentication token (cookie) to 253 the RP without renewed user authentication at the IdP. 255 With all of this in mind, the flow appears as follows: 257 SASL Serv. Client IdP 258 |>-----(1)----->| | Advertisement 259 | | | 260 |<-----(2)-----<| | Initiation 261 | | | 262 |>-----(3)----->| | Authentication Request 263 | | | 264 |<-----(4)-----<| | Empty Response 265 | | | 266 | |< - - - - - ->| Client<>IDP 267 | | | Authentication 268 | | | 269 |<- - - - - - - - - - - - - - -| Authentication Statement 270 | | | 271 |>-----(6)----->| | SASL completion with 272 | | | status 273 | | | 275 ----- = SASL 276 - - - = HTTP or HTTPs (external to SASL) 278 Figure 2: Authentication flow 280 3. SAML SASL Mechanism Specification 282 This section specifies the details of the SAML SASL mechanism. 283 Recall section 5 of [RFC4422] for what needs to be described here. 285 The name of this mechanism "SAML20". The mechanism is capable of 286 transferring an authorization identity (via "gs2-header"). The 287 mechanism does not offer a security layer. 289 The mechanism is client-first. The first mechanism message from the 290 client to the server is the "initial-response" described below. As 291 described in [RFC4422], if the application protocol does not support 292 sending a client-response together with the authentication request, 293 the server will send an empty server-challenge to let the client 294 begin. 296 The second mechanism message is from the server to the client, the 297 "authentication-request" described below. 299 The third mechanism message is from client to the server, and is the 300 fixed message consisting of "=". 302 The fourth mechanism message is from the server to the client, 303 indicating the SASL mechanism outcome described below. 305 3.1. Initial Response 307 A client initiates a "SAML20" authentication with SASL by sending the 308 GS2 header followed by the authentication identifier. The GS2 header 309 carries the optional authorization identity. 311 initial-response = gs2-header Idp-Identifier 312 IdP-Identifier = domain ; domain name with corresponding IdP 314 The "gs2-header" is specified in [RFC5801], and it is used as 315 follows. The "gs2-nonstd-flag" MUST NOT be present. Regarding the 316 channel binding "gs2-cb-flag" field, see Section 5. The "gs2- 317 authzid" carries the optional authorization identity. Domain name is 318 specified in [RFC1035]. 320 3.2. Authentication Request 322 The SASL Server transmits a redirect URI to the IdP that corresponds 323 to the domain the user provided, with a SAML authentication request 324 as one of the parameters. Note: The SASL server may have a static 325 mapping of domain to corresponding IdP or alternatively a DNS-lookup 326 mechanism could be envisioned, but that is out-of-scope for this 327 document 329 authentication-request = URI 331 URI is specified in [RFC3986] and is encoded according to Section 3.4 332 (HTTP Redirect) of the SAML bindings 2.0 specification 333 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is 334 encoded according to Section 3.4 (Authentication Request) of the SAML 335 core 2.0 specification [OASIS.saml-core-2.0-os]. 337 The client now sends the authentication request via an HTTP GET to 338 the IdP, as if redirected to do so from an HTTP server and in 339 accordance with the Web Browser SSO profile, described in section 3.1 340 of [OASIS.saml-profiles-2.0-os] 342 The client MUST handle both user authentication to the IdP and 343 confirmation or rejection of the authentiation of the RP. 345 After all authentication has been completed by the IdP, and after the 346 response has been sent to the client, the client will relay the 347 response to the Relying Party via HTTP(S), as specified in the 348 authentication request ("AssertionConsumerServiceURL"). 350 Please note: this means that the SASL server needs to implement a 351 SAML Relying Party. Also, the RP needs to correlate the TCP session 352 from the SASL client with the SAML authentication. 354 3.3. Outcome and parameters 356 The Relying Party now validates the response it received from the 357 client via HTTP or HTTPS, as specified in the SAML specification 359 The response by the Relying Party constitutes a SASL mechanism 360 outcome, and SHALL be used to set state in the server accordingly, 361 and it shall be used by the server to report that state to the SASL 362 client as described in [RFC4422] Section 3.6. 364 4. SAML GSS-API Mechanism Specification 366 This section and its sub-sections and all normative references of it 367 not referenced elsewhere in this document are INFORMATIONAL for SASL 368 implementors, but they are NORMATIVE for GSS-API implementors. 370 The SAML SASL mechanism is actually also a GSS-API mechanism. The 371 messages are the same, but 373 a) the GS2 header on the client's first message and channel binding 374 data is excluded when SAML is used as a GSS-API mechanism, and 376 b) the RFC2743 section 3.1 initial context token header is prefixed 377 to the client's first authentication message (context token). 379 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see 380 IANA considerations). 382 SAML20 security contexts always have the mutual_state flag 383 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential 384 delegation, therefore SAML security contexts alway have the 385 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 387 The mutual authentication property of this mechanism relies on 388 successfully comparing the TLS server identity with the negotiated 389 target name. Since the TLS channel is managed by the application 390 outside of the GSS-API mechanism, the mechanism itself is unable to 391 confirm the name while the application is able to perform this 392 comparison for the mechanism. For this reason, applications MUST 393 match the TLS server identity with the target name, as discussed in 394 [RFC6125]. 396 The SAML mechanism does not support per-message tokens or 397 GSS_Pseudo_random. 399 4.1. GSS-API Principal Name Types for SAML 401 SAML supports standard generic name syntaxes for acceptors such as 402 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML 403 supports only a single name type for initiators: GSS_C_NT_USER_NAME. 404 GSS_C_NT_USER_NAME is the default name type for SAML. The query, 405 display, and exported name syntaxes for SAML principal names are all 406 the same. There are no SAML-specific name syntaxes -- applications 407 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and 408 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported 409 name token does, of course, conform to [RFC2743], Section 3.2. 411 5. Channel Binding 413 The "gs2-cb-flag" MUST use "n" because channel binding data cannot be 414 integrity protected by the SAML negotiation. 416 Note: In theory channel binding data could be inserted in the SAML 417 flow by the client and verified by the server, but that is currently 418 not supported in SAML. 420 6. Examples 422 6.1. XMPP 424 Suppose the user has an identity at the SAML IdP saml.example.org and 425 a Jabber Identifier (JID) "somenode@example.com", and wishes to 426 authenticate his XMPP connection to xmpp.example.com. The 427 authentication on the wire would then look something like the 428 following: 430 Step 1: Client initiates stream to server: 432 436 Step 2: Server responds with a stream tag sent to client: 438 442 Step 3: Server informs client of available authentication mechanisms: 444 445 446 DIGEST-MD5 447 PLAIN 448 SAML20 449 450 452 Step 4: Client selects an authentication mechanism and provides the 453 initial client response containing the BASE64 [RFC4648] encoded gs2- 454 header and domain: 456 457 biwsZXhhbXBsZS5vcmc 459 The decoded string is: n,,example.org 460 Step 5: Server sends a BASE64 encoded challenge to client in the form 461 of an HTTP Redirect to the SAML IdP corresponding to example.org 462 (https://saml.example.org) with the SAML Authentication Request as 463 specified in the redirection url: 465 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 466 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 467 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 468 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 469 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 470 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 471 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 472 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 473 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 474 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 475 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 476 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 477 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 478 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 479 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 480 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 481 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 482 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 483 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 484 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 485 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 486 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 487 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 488 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 489 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 490 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 491 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 492 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 493 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 494 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 495 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 496 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 497 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 498 bGMzUSs= 500 The decoded challenge is: 502 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk 503 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl 504 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT 505 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC 506 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX 507 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 508 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 509 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV 510 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX 511 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn 512 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi 513 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 514 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 515 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX 516 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On 517 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG 518 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 519 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 520 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX 521 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC 522 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm 523 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 524 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ 525 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX 526 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4= 528 Where the decoded SAMLRequest looks like: 530 537 538 https://xmpp.example.com 539 540 543 546 548 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 549 550 551 553 Note: the server can use the request ID 554 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL 555 session with the SAML authentication. 557 Step 5 (alt): Server returns error to client: 559 560 561 562 564 Step 6: Client sends a BASE64 encoded empty response to the 565 challenge: 567 568 = 569 571 [ The client now sends the URL to a browser for processing. The 572 browser engages in a normal SAML authentication flow (external to 573 SASL), like redirection to the Identity Provider 574 (https://saml.example.org), the user logs into 575 https://saml.example.org, and agrees to authenticate to 576 xmpp.example.com. A redirect is passed back to the client browser 577 who sends the AuthN response to the server, containing the subject- 578 identifier as an attribute. If the AuthN response doesn't contain 579 the JID, the server maps the subject-identifier received from the IdP 580 to a JID] 582 Step 7: Server informs client of successful authentication: 584 586 Step 7 (alt): Server informs client of failed authentication: 588 589 590 591 593 Step 8: Client initiates a new stream to server: 595 599 Step 9: Server responds by sending a stream header to client along 600 with any additional features (or an empty features element): 602 605 606 607 608 610 Step 10: Client binds a resource: 612 613 614 someresource 615 616 618 Step 11: Server informs client of successful resource binding: 620 621 622 somenode@example.com/someresource 623 624 626 Please note: line breaks were added to the base64 for clarity. 628 6.2. IMAP 630 The following describes an IMAP exchange. Lines beginning with 'S:' 631 indicate data sent by the server, and lines starting with 'C:' 632 indicate data sent by the client. Long lines are wrapped for 633 readability. 635 S: * OK IMAP4rev1 636 C: . CAPABILITY 637 S: * CAPABILITY IMAP4rev1 STARTTLS 638 S: . OK CAPABILITY Completed 639 C: . STARTTLS 640 S: . OK Begin TLS negotiation now 641 C: . CAPABILITY 642 S: * CAPABILITY IMAP4rev1 AUTH=SAML20 643 S: . OK CAPABILITY Completed 644 C: . AUTHENTICATE SAML20 645 S: + 646 C: biwsZXhhbXBsZS5vcmc 647 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 648 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 649 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 650 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 651 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 652 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 653 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 654 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 655 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 656 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 657 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 658 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 659 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 660 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 661 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 662 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 663 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 664 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 665 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 666 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 667 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 668 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 669 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 670 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 671 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 672 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 673 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 674 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 675 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 676 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 677 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 678 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 679 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 680 bGMzUSs= 681 C: 682 S: . OK Success (tls protection) 684 7. Security Considerations 686 This section will address only security considerations associated 687 with the use of SAML with SASL applications. For considerations 688 relating to SAML in general, the reader is referred to the SAML 689 specification and to other literature. Similarly, for general SASL 690 Security Considerations, the reader is referred to that 691 specification. 693 7.1. Man in the middle and Tunneling Attacks 695 This mechanism is vulnerable to man in the middle and tunneling 696 attacks unless a client always verify the server identity before 697 proceeding with authentication (see [RFC6125]). Typically TLS is 698 used to provide a secure channel with server authentication. 700 7.2. Binding SAML subject identifiers to Authorization Identities 702 As specified in [RFC4422], the server is responsible for binding 703 credentials to a specific authorization identity. It is therefore 704 necessary that only specific trusted IdPs be allowed. This is 705 typical part of SAML trust establishment between RP's and IdP. 707 7.3. User Privacy 709 The IdP is aware of each RP that a user logs into. There is nothing 710 in the protocol to hide this information from the IdP. It is not a 711 requirement to track the visits, but there is nothing that prohibits 712 the collection of information. SASL servers should be aware that 713 SAML IdPs will track - to some extent - user access to their 714 services. 716 7.4. Collusion between RPs 718 It is possible for RPs to link data that they have collected on you. 719 By using the same identifier to log into every RP, collusion between 720 RPs is possible. In SAML, targeted identity was introduced. 721 Targeted identity allows the IdP to transform the identifier the user 722 typed in to an opaque identifier. This way the RP would never see 723 the actual user identifier, but a randomly generated identifier. 724 This is an option the user has to understand and decide to use if the 725 IdP is supporting it. 727 8. IANA Considerations 729 The IANA is requested to register the following SASL profile: 731 SASL mechanism profile: SAML20 733 Security Considerations: See this document 735 Published Specification: See this document 737 For further information: Contact the authors of this document. 739 Owner/Change controller: the IETF 741 Note: None 743 The IANA is further requested to assign an OID for this GSS mechanism 744 in the SMI numbers registry, with the prefix of 745 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 746 reference this specification in the registry. 748 9. References 750 9.1. Normative References 752 [OASIS.saml-bindings-2.0-os] 753 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 754 Maler, "Bindings for the OASIS Security Assertion Markup 755 Language (SAML) V2.0", OASIS 756 Standard saml-bindings-2.0-os, March 2005. 758 [OASIS.saml-core-2.0-os] 759 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 760 "Assertions and Protocol for the OASIS Security Assertion 761 Markup Language (SAML) V2.0", OASIS Standard saml-core- 762 2.0-os, March 2005. 764 [OASIS.saml-profiles-2.0-os] 765 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 766 P., Philpott, R., and E. Maler, "Profiles for the OASIS 767 Security Assertion Markup Language (SAML) V2.0", OASIS 768 Standard OASIS.saml-profiles-2.0-os, March 2005. 770 [RFC1035] Mockapetris, P., "Domain names - implementation and 771 specification", STD 13, RFC 1035, November 1987. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 777 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 778 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 780 [RFC2743] Linn, J., "Generic Security Service Application Program 781 Interface Version 2, Update 1", RFC 2743, January 2000. 783 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 784 Resource Identifier (URI): Generic Syntax", STD 66, 785 RFC 3986, January 2005. 787 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 788 Security Layer (SASL)", RFC 4422, June 2006. 790 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 791 Encodings", RFC 4648, October 2006. 793 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 794 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 796 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 797 Housley, R., and W. Polk, "Internet X.509 Public Key 798 Infrastructure Certificate and Certificate Revocation List 799 (CRL) Profile", RFC 5280, May 2008. 801 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 802 Service Application Program Interface (GSS-API) Mechanisms 803 in Simple Authentication and Security Layer (SASL): The 804 GS2 Mechanism Family", RFC 5801, July 2010. 806 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 807 Verification of Domain-Based Application Service Identity 808 within Internet Public Key Infrastructure Using X.509 809 (PKIX) Certificates in the Context of Transport Layer 810 Security (TLS)", RFC 6125, March 2011. 812 [W3C.REC-html401-19991224] 813 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 814 Specification", World Wide Web Consortium 815 Recommendation REC-html401-19991224, December 1999, 816 . 818 9.2. Informative References 820 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 821 STD 53, RFC 1939, May 1996. 823 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 825 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 826 4rev1", RFC 3501, March 2003. 828 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 829 Protocol (XMPP): Core", RFC 6120, March 2011. 831 Appendix A. Acknowledgments 833 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh 834 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank 835 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their 836 review and contributions. 838 Appendix B. Changes 840 This section to be removed prior to publication. 842 o 05 Fixed references per ID-nits 844 o 04 Added request for IANA assignment, few text clarifications 846 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov 848 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos 850 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott 851 Cantor 853 o 01 Added authorization identity, added GSS-API specifics, added 854 client supplied IdP 856 o 00 Initial Revision. 858 Authors' Addresses 860 Klaas Wierenga 861 Cisco Systems, Inc. 862 Haarlerbergweg 13-19 863 Amsterdam, Noord-Holland 1101 CH 864 Netherlands 866 Phone: +31 20 357 1752 867 Email: klaas@cisco.com 869 Eliot Lear 870 Cisco Systems GmbH 871 Richtistrasse 7 872 Wallisellen, ZH CH-8304 873 Switzerland 875 Phone: +41 44 878 9200 876 Email: lear@cisco.com 878 Simon Josefsson 879 SJD AB 880 Hagagatan 24 881 Stockholm 113 47 882 SE 884 Email: simon@josefsson.org 885 URI: http://josefsson.org/