idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-01.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 28, 2012) is 4412 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) == Missing Reference: 'RFC2743' is mentioned on line 877, but not defined == Missing Reference: 'RFC5801' is mentioned on line 880, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAMLECP20' -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cantor 3 Internet-Draft Shibboleth Consortium 4 Intended status: Standards Track S. Josefsson 5 Expires: August 31, 2012 SJD AB 6 February 28, 2012 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-01.txt 11 Abstract 13 Security Assertion Markup Language (SAML) 2.0 is a generalized 14 framework for the exchange of security-related information between 15 asserting and relying parties. Simple Authentication and Security 16 Layer (SASL) and the Generic Security Service Application Program 17 Interface (GSS-API) are application frameworks to facilitate an 18 extensible authentication model. This document specifies a SASL and 19 GSS-API mechanism for SAML 2.0 that leverages the capabilities of a 20 SAML-aware "enhanced client" to address significant barriers to 21 federated authentication in a manner that encourages reuse of 22 existing SAML bindings and profiles designed for non-browser 23 scenarios. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 31, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6 62 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 63 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 66 4.4. User Authentication with Identity Provider . . . . . . . . 10 67 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 68 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 70 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 11 71 5.1. GSS-API Principal Name Types for SAML EC . . . . . . . . . 11 72 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 20 75 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 20 76 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 21 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 80 9.2. Normative References for GSS-API Implementers . . . . . . 24 81 9.3. Informative References . . . . . . . . . . . . . . . . . . 24 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 83 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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. 95 Additional profiles and extensions are also routinely developed and 96 published. 98 Simple Authentication and Security Layer (SASL) [RFC4422] is a 99 generalized mechanism for identifying and authenticating a user and 100 for optionally negotiating a security layer for subsequent protocol 101 interactions. SASL is used by application protocols like IMAP, POP 102 and XMPP [RFC3920]. The effect is to make authentication modular, so 103 that newer authentication mechanisms can be added as needed. 105 The Generic Security Service Application Program Interface (GSS-API) 106 [RFC2743] provides a framework for applications to support multiple 107 authentication mechanisms through a unified programming interface. 108 This document defines a pure SASL mechanism for SAML, but it conforms 109 to the bridge between SASL and the GSS-API called GS2 [RFC5801]. 110 This means that this document defines both a SASL mechanism and a 111 GSS-API mechanism. The GSS-API interface is optional for SASL 112 implementers, and the GSS-API considerations can be avoided in 113 environments that uses SASL directly without GSS-API. 115 The mechanisms specified in this document allow a SASL- or GSS-API- 116 enabled server to act as a SAML relying party, or service provider 117 (SP), by advertising this mechanism as an option for SASL or GSS-API 118 clients that support the use of SAML to communicate identity and 119 attribute information. Clients supporting this mechanism are termed 120 "enhanced clients" in SAML terminology because they understand the 121 federated authentication model and have specific knowledge of the 122 IdP(s) associated with the user. This knowledge, and the ability to 123 act on it, addresses a significant problem with browser-based SAML 124 profiles known as the "discovery", or "where are you from?" (WAYF) 125 problem. Obviating the need for the RP to interact with the client 126 to determine the right IdP (and its network location) is both a user 127 interface and security improvement. 129 The SAML mechanism described in this document is an adaptation of an 130 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 131 (V2.0) [SAMLECP20], and therefore does not establish a separate 132 authentication, integrity and confidentiality mechanism. It is 133 anticipated that existing security layers, such as Transport Layer 134 Security (TLS) or Secure Shell (SSH), will continued to be used. 136 Figure 1 describes the interworking between SAML and SASL: this 137 document requires enhancements to the RP and to the client (as the 138 two SASL communication endpoints) but no changes to the SAML IdP are 139 assumed apart from its support for the applicable SAML profile. To 140 accomplish this, a SAML protocol exchange between the RP and the IdP, 141 brokered by the client, is tunneled within SASL. There is no assumed 142 communication between the RP and the IdP, but such communication may 143 occur in conjunction with additional SAML-related profiles not in 144 scope for this document. 146 +-----------+ 147 | SAML | 148 | Relying | 149 | Party | 150 | | 151 +-----------+ 152 ^ 153 +--|--+ 154 | S| | 155 S | A| | 156 A | M| | 157 S | L| | 158 L | | | 159 | | | 160 +--|--+ 161 +------------+ v 162 | | +----------+ 163 | SAML | SAML SOAP | | 164 | Identity |<--------------->| Client | 165 | Provider | Binding | | 166 +------------+ +----------+ 168 Figure 1: Interworking Architecture 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 The reader is also assumed to be familiar with the terms used in the 177 SAML 2.0 specification, and an understanding of the Enhanced Client 178 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 179 this mechanism explicitly reuses and references it. 181 This document can be implemented without knowledge of GSS-API since 182 the normative aspects of the GS2 protocol syntax have been duplicated 183 in this document. The document may also be implemented to provide a 184 GSS-API mechanism, and then knowledge of GSS-API is essential. To 185 faciliate these two variants, the references has been split into two 186 parts, one part that provides normative references for all readers, 187 and one part that adds additional normative references required for 188 implementers that wish to implement the GSS-API portion. 190 3. Applicability for Non-HTTP Use Cases 192 While SAML is designed to support a variety of application scenarios, 193 the profiles for authentication defined in the original standard are 194 designed around HTTP [RFC2616] applications. They are not, however, 195 limited to browsers, because it was recognized that browsers suffer 196 from a variety of functional and security deficiencies that would be 197 useful to avoid where possible. Specifically, the notion of an 198 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 199 thus the term "ECP") was specified for a software component that acts 200 somewhat like a browser from an application perspective, but includes 201 limited, but sufficient, awareness of SAML to play a more conscious 202 role in the authentication exchange between the RP and the IdP. What 203 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 204 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 206 1. The Enhanced Client requests a resource of a Relying Party (RP) 207 (via an HTTP request). In doing so, it advertises its "enhanced" 208 capability using HTTP headers. 210 2. The RP, desiring SAML authentication and noting the client's 211 capabilities, responds not with an HTTP redirect or form, but 212 with a SOAP [W3C.soap11] envelope containing a SAML 213 along with some supporting headers. This request 214 identifies the RP (and may be signed), and may provide hints to 215 the client as to what IdPs the RP finds acceptable, but the 216 choice of IdP is generally left to the client. 218 3. The client is then responsible for delivering the body of the 219 SOAP message to the IdP it is instructed to use (often via 220 configuration ahead of time). The user authenticates to the IdP 221 ahead of, during, or after the delivery of this message, and 222 perhaps explicitly authorizes the response to the RP. 224 4. Whether authentication succeeds or fails, the IdP responds with 225 its own SOAP envelope, generally containing a SAML 226 message for delivery to the RP. In a successful case, the 227 message will include a SAML containing 228 authentication, and possibly attribute, information about the 229 user. Either the response or assertion alone is signed, and the 230 assertion may be encrypted to a key negotiated with or known to 231 belong to the RP. 233 5. The client then delivers the SOAP envelope containing the 234 to the RP at a location the IdP directs (which acts as 235 an additional, though limited, defense against MITM attacks). 236 This completes the SAML exchange. 238 6. The RP now has sufficient identity information to approve the 239 original HTTP request or not, and acts accordingly. Everything 240 between the original request and this response can be thought of 241 as an "interruption" of the original HTTP exchange. 243 When considering this flow in the context of an arbitrary application 244 protocol and SASL, the RP and the client both must change their code 245 to implement this SASL mechanism, but the IdP can remain untouched. 246 The existing RP/client exchange that is tunneled through HTTP maps 247 well to the tunneling of that same exchange in SASL. In the parlance 248 of SASL [RFC4422], this mechanism is "client-first" for consistency 249 with GS2. The steps are shown below: 251 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 252 mechanisms. 254 2. The client initiates a SASL authentication with SAML20EC or 255 SAML20EC-PLUS. 257 3. The server sends the client a challenge consisting of a SOAP 258 envelope containing its SAML . 260 4. The SASL client unpacks the SOAP message and communicates with 261 its chosen IdP to relay the SAML to it. This 262 communication, and the authentication with the IdP, proceeds 263 separately from the SASL process. 265 5. Upon completion of the exchange with the IdP, the client responds 266 to the SASL server with a SOAP envelope containing the SAML 267 it obtained, or a SOAP fault, as warranted. 269 6. The SASL Server indicates success or failure. 271 Note: The details of the SAML processing, which are consistent with 272 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 273 such that the client MUST interact with the IdP in order to complete 274 any SASL exchange with the RP. The assertions issued by the IdP for 275 the purposes of the profile, and by extension this SASL mechanism, 276 are short lived, and therefore cannot be cached by the client for 277 later use. 279 Encompassed in step four is the client-driven selection of the IdP, 280 authentication to it, and the acquisition of a response to provide to 281 the SASL server. These processes are all external to SASL. 283 With all of this in mind, the typical flow appears as follows: 285 SASL Serv. Client IdP 286 |>-----(1)----->| | Advertisement 287 | | | 288 |<-----(2)-----<| | Initiation 289 | | | 290 |>-----(3)----->| | SASL Server Response 291 | | | 292 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 293 | | | 294 |<-----(5)-----<| | SASL Client Response 295 | | | 296 |>-----(6)----->| | Server sends Outcome 297 | | | 299 ----- = SASL 300 - - - = SOAP over HTTPS (external to SASL) 302 Figure 2: Authentication flow 304 4. SAML SASL Mechanism Specification 306 Based on the previous figures, the following operations are defined 307 by the SAML SASL mechanism: 309 4.1. Advertisement 311 To advertise that a server supports this mechanism, during 312 application session initiation, it displays the name "SAML20EC" 313 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms 314 (depending on its support for channel binding). 316 4.2. Initiation 318 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 319 supported by the application protocol, the client MAY include an 320 initial response, otherwise it waits until the server has issued an 321 empty challenge (because the mechanism is client-first). 323 The format of the initial client response is as follows: 325 holder-of-key = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 327 initial-response = gs2-cb-flag "," [gs2-authzid] "," [holder-of-key] 329 The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate 330 whether the client supports channel binding. This takes the place of 331 the PAOS HTTP header extension used in [SAMLECP20] to indicate 332 channel binding support. 334 The optional "gs2-authzid" field holds the authorization identity, as 335 requested by the client. 337 The optional "holder-of-key" field is a constant that signals the 338 client's support for stronger security by means of a locally held 339 key. This takes the place of the PAOS HTTP header extension used in 340 [SAMLECP20] to indicate "holder of key" support. 342 4.3. Server Response 344 The SASL server responds with a SOAP envelope constructed in 345 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 346 to the SOAP header requirements of the SAML PAOS Binding 347 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 348 profile. Various SOAP headers are also consumed by the client in 349 exactly the same manner prescribed by that section. 351 4.4. User Authentication with Identity Provider 353 Upon receipt of the Server Response (Section 4.3), the steps 354 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 355 performed between the client and the chosen IdP. The means by which 356 the client determines the IdP to use, and where it is located, are 357 out of scope of this mechanism. 359 The exact means of authentication to the IdP are also out of scope, 360 but clients supporting this mechanism MUST support HTTP Basic 361 Authentication as defined in [RFC2617] and TLS client authentication 362 as defined in [RFC5246]. 364 4.5. Client Response 366 Assuming a response is obtained from the IdP, the client responds to 367 the SASL server with a SOAP envelope constructed in accordance with 368 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 369 header requirements of the SAML PAOS Binding 370 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 371 profile. If the client is unable to obtain a response from the IdP, 372 it responds to the SASL server with a SOAP envelope containing a SOAP 373 fault. 375 4.6. Outcome 377 The SAML protocol exchange having completed, the SASL server will 378 transmit the outcome to the client depending on local validation of 379 the client responses. This outcome is transmitted in accordance with 380 the application protocol in use. 382 4.7. Additional Notes 384 Because this mechanism is an adaptation of an HTTP-based profile, 385 there are a few requirements outlined in [SAMLECP20] that make 386 reference to a response URL that is normally used to regulate where 387 the client returns information to the RP. There are also security- 388 related checks built into the profile that involve this location. 390 For compatibility with existing IdP and profile behavior, and to 391 provide for secure identification of the RP to the client, the SASL 392 server MUST populate the responseConsumerURL and 393 AssertionConsumerServiceURL attributes with its service name, 394 expressed as an absolute URI. The parties then perform the steps 395 described in [SAMLECP20] as usual. 397 Similarly, the use of HTTP status signaling between the RP and client 398 mandated by [SAMLECP20] may not be applicable. 400 5. SAML EC GSS-API Mechanism Specification 402 This section and its sub-sections and all normative references of it 403 not referenced elsewhere in this document are INFORMATIONAL for SASL 404 implementors, but they are NORMATIVE for GSS-API implementors. 406 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 407 The messages are the same, but a) the GS2 header on the client's 408 first message is excluded when SAML EC is used as a GSS-API 409 mechanism, and b) the RFC2743 section 3.1 initial context token 410 header is prefixed to the client's first authentication message 411 (context token). 413 The GSS-API mechanism OID for SAML EC is 1.3.6.1.4.1.11591.4.6. 415 SAML EC security contexts always have the mutual_state flag 416 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML EC does not support credential 417 delegation, therefore SAML EC security contexts alway have the 418 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 420 The mutual authentication property of this mechanism relies on 421 successfully comparing the server identity from the existing security 422 layer (TLS, SSH, etc.) with the negotiated target name. Since the 423 existing security layer is managed by the application outside of the 424 GSS-API mechanism, the mechanism itself is unable to confirm the 425 name. For this reason, applications MUST match the server identity 426 from the existing security layer with the target name. For TLS, this 427 matching MUST be perfored as discussed in [RFC6125]. For SSH, this 428 matching MUST be performed as discussed in [RFC4462]. Applications 429 may rely on the GSS-API mechanism to perform this matching by passing 430 the server identity as the targ_name parameter to 431 GSS_Init_sec_context(). 433 The SAML EC mechanism does not support per-message tokens or 434 GSS_Pseudo_random. 436 The lifetime of a security context established with this mechanism 437 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 438 any, in the of the SAML assertion received by the 439 RP. 441 5.1. GSS-API Principal Name Types for SAML EC 443 SAML EC supports standard generic name syntaxes for acceptors such as 444 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). These 445 service names MUST be associated with the SAML "entityID" claimed by 446 the RP, such as through the use of SAML metadata 447 [OASIS.saml-metadata-2.0-os]. 449 SAML EC supports only a single name type for initiators: 450 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 451 SAML EC. 453 The query, display, and exported name syntaxes for SAML EC principal 454 names are all the same. There are no SAML EC-specific name syntaxes 455 -- applications should use generic GSS-API name types such as 456 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 457 Section 4). The exported name token does, of course, conform to 458 [RFC2743], Section 3.2, but the "NAME" part of the token should be 459 treated as a potential input string to the SAML EC name normalization 460 rules. 462 GSS-API name attributes may be defined in the future to hold the 463 normalized SAML EC Identifier. 465 6. Example 467 Suppose the user has an identity at the SAML IdP saml.example.org and 468 a Jabber Identifier (jid) "somenode@example.com", and wishes to 469 authenticate his XMPP connection to xmpp.example.com (and example.com 470 and example.org have established a SAML-capable trust relationship). 471 The authentication on the wire would then look something like the 472 following: 474 Step 1: Client initiates stream to server: 476 480 Step 2: Server responds with a stream tag sent to client: 482 486 Step 3: Server informs client of available authentication mechanisms: 488 489 490 DIGEST-MD5 491 PLAIN 492 SAML20EC 493 494 496 Step 4: Client selects an authentication mechanism and sends the 497 initial client response (it is base64 encoded as specified by the 498 XMPP SASL protocol profile): 500 501 biws 502 504 The initial response is "n,," which signals that channel binding is 505 not used, there is no authorization identity, and the client does not 506 support key-based confirmation. 508 Step 5: Server sends a challenge to client in the form of a SOAP 509 envelope containing its SAML : 511 512 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 513 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 514 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 515 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 516 bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 517 ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 518 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u 519 c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj 520 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg 521 ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB 522 TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h 523 cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k 524 PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft 525 bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 526 L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB 527 dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 528 ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n 529 PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz 530 c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N 531 CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 532 TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg 533 ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl 534 YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu 535 MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB 536 dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u 537 dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj 538 bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu 539 Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ 540 IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w 541 ZT4NCg== 542 544 The Base64 [RFC4648] decoded envelope: 546 550 551 556 560 https://xmpp.example.com 561 562 563 564 568 569 https://xmpp.example.com 570 571 573 574 575 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 576 577 578 579 580 582 Step 5 (alt): Server returns error to client: 584 585 586 587 589 Step 6: Client relays the request to IdP in a SOAP message 590 transmitted over HTTP (over TLS). HTTP portion not shown, use of 591 Basic Authentication is assumed. The body of the SOAP envelope is 592 exactly the same as received in the previous step. 594 598 599 600 601 602 603 605 Step 7: IdP responds to client with a SOAP response containing a SAML 606 containing a short-lived SSO assertion (shown as an 607 encrypted variant in the example). 609 613 614 617 618 619 622 https://saml.example.org 623 624 626 627 628 629 630 631 632 634 Step 8: Client sends SOAP envelope containing the SAML as 635 a response to the SASL server's challenge: 637 638 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 639 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 640 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 641 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug 642 eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i 643 aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt 644 dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 645 L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 646 cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy 647 LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz 648 dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 649 ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s 650 cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 651 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg 652 ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg 653 ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk 654 QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu 655 dmVsb3BlPg0K 656 658 The Base64 [RFC4648] decoded envelope: 660 664 665 668 669 670 673 https://saml.example.org 674 675 677 678 679 680 681 682 683 685 Step 9: Server informs client of successful authentication: 687 689 Step 9 (alt): Server informs client of failed authentication: 691 692 693 694 696 Step 10: Client initiates a new stream to server: 698 701 Step 11: Server responds by sending a stream header to client along 702 with any additional features (or an empty features element): 704 707 708 709 710 712 Step 12: Client binds a resource: 714 715 716 someresource 717 718 720 Step 13: Server informs client of successful resource binding: 722 723 724 somenode@example.com/someresource 725 726 728 Please note: line breaks were added to the base64 for clarity. 730 7. Security Considerations 732 This section will address only security considerations associated 733 with the use of SAML with SASL applications. For considerations 734 relating to SAML in general, the reader is referred to the SAML 735 specification and to other literature. Similarly, for general SASL 736 Security Considerations, the reader is referred to that 737 specification. 739 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 740 optional support for channel binding and use of "Holder of Key" 741 subject confirmation. The former is strongly recommended for use 742 with this mechanism to detect "Man in the Middle" attacks between the 743 client and the RP without relying on flawed commercial TLS 744 infrastructure. The latter may be impractical in many cases, but is 745 a valuable way of strengthening client authentication, protecting 746 against phishing, and improving the overall mechanism. 748 7.1. Risks Left Unaddressed 750 The adaptation of a web-based profile that is largely designed around 751 security-oblivious clients and a bearer model for security token 752 validation results in a number of basic security exposures that 753 should be weighed against the compatibility and client simplification 754 benefits of this mechanism. 756 When channel binding is not used, protection against "Man in the 757 Middle" attacks is left to lower layer protocols such as TLS, and the 758 development of user interfaces able to implement that has not been 759 effectively demonstrated. Failure to detect a MITM can result in 760 phishing of the user's credentials if the attacker is between the 761 client and IdP, or the theft and misuse of a short-lived credential 762 (the SAML assertion) if the attacker is able to impersonate a RP. 763 SAML allows for source address checking as a minor mitigation to the 764 latter threat, but this is often impractical. IdPs can mitigate to 765 some extent the exposure of personal information to RP attackers by 766 encrypting assertions with authenticated keys. 768 7.2. User Privacy 770 The IdP is aware of each RP that a user logs into. There is nothing 771 in the protocol to hide this information from the IdP. It is not a 772 requirement to track the activity, but there is nothing technically 773 that prohibits the collection of this information. SASL servers 774 should be aware that SAML IdPs will track - to some extent - user 775 access to their services. 777 It is also out of scope of the mechanism to determine under what 778 conditions an IdP will release particular information to a relying 779 party, and it is generally unclear in what fashion user consent could 780 be established in real time for the release of particular 781 information. The SOAP exchange with the IdP does not preclude such 782 interaction, but neither does it define that interoperably. 784 7.3. Collusion between RPs 786 Depending on the information supplied by the IdP, it may be possible 787 for RPs to correlate data that they have collected. By using the 788 same identifier to log into every RP, collusion between RPs is 789 possible. SAML supports the notion of pairwise, or targeted/ 790 directed, identity. This allows the IdP to manage opaque, pairwise 791 identifiers for each user that are specific to each RP. However, 792 correlation is often possible based on other attributes supplied, and 793 is generally a topic that is beyond the scope of this mechanism. It 794 is sufficient to say that this mechanism does not introduce new 795 correlation opportunities over and above the use of SAML in web-based 796 use cases. 798 8. IANA Considerations 800 The IANA is requested to register the following SASL profile: 802 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 804 Security Considerations: See this document 806 Published Specification: See this document 808 For further information: Contact the authors of this document. 810 Owner/Change controller: the IETF 812 Note: None 814 9. References 816 9.1. Normative References 818 [OASIS.saml-bindings-2.0-os] 819 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 820 Maler, "Bindings for the OASIS Security Assertion Markup 821 Language (SAML) V2.0", OASIS 822 Standard saml-bindings-2.0-os, March 2005. 824 [OASIS.saml-core-2.0-os] 825 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 826 "Assertions and Protocol for the OASIS Security Assertion 827 Markup Language (SAML) V2.0", OASIS Standard saml-core- 828 2.0-os, March 2005. 830 [OASIS.saml-profiles-2.0-os] 831 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 832 P., Philpott, R., and E. Maler, "Profiles for the OASIS 833 Security Assertion Markup Language (SAML) V2.0", OASIS 834 Standard OASIS.saml-profiles-2.0-os, March 2005. 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, March 1997. 839 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 840 Leach, P., Luotonen, A., and L. Stewart, "HTTP 841 Authentication: Basic and Digest Access Authentication", 842 RFC 2617, June 1999. 844 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 845 Security Layer (SASL)", RFC 4422, June 2006. 847 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 848 "Generic Security Service Application Program Interface 849 (GSS-API) Authentication and Key Exchange for the Secure 850 Shell (SSH) Protocol", RFC 4462, May 2006. 852 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 853 Encodings", RFC 4648, October 2006. 855 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 856 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 858 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 859 Verification of Domain-Based Application Service Identity 860 within Internet Public Key Infrastructure Using X.509 861 (PKIX) Certificates in the Context of Transport Layer 862 Security (TLS)", RFC 6125, March 2011. 864 [SAMLECP20] 865 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 866 Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp- 867 v2.0-wd04, August 2011. 869 [W3C.soap11] 870 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 871 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 872 "Simple Object Access Protocol (SOAP) 1.1", W3C 873 Note soap11, May 2000, . 875 9.2. Normative References for GSS-API Implementers 877 [RFC2743] Linn, J., "Generic Security Service Application Program 878 Interface Version 2, Update 1", RFC 2743, January 2000. 880 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 881 Service Application Program Interface (GSS-API) Mechanisms 882 in Simple Authentication and Security Layer (SASL): The 883 GS2 Mechanism Family", RFC 5801, July 2010. 885 9.3. Informative References 887 [OASIS.saml-metadata-2.0-os] 888 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 889 "Metadata for the Security Assertion Markup Language 890 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 891 March 2005. 893 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 894 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 895 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 897 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 898 Protocol (XMPP): Core", RFC 3920, October 2004. 900 Appendix A. Acknowledgments 902 The authors would like to thank Klaas Wierenga, Sam Hartman, and Nico 903 Williams for their contributions. 905 Appendix B. Changes 907 This section to be removed prior to publication. 909 o 01, SSH language added, noted non-assumption of HTTP error 910 handling, added guidance on life of security context. 912 o 00, Initial Revision, first WG-adopted draft. Removed support for 913 unsolicited SAML responses. 915 Authors' Addresses 917 Scott Cantor 918 Shibboleth Consortium 919 2740 Airport Drive 920 Columbus, Ohio 43219 921 United States 923 Phone: +1 614 247 6147 924 Email: cantor.2@osu.edu 926 Simon Josefsson 927 SJD AB 928 Hagagatan 24 929 Stockholm 113 47 930 SE 932 Email: simon@josefsson.org 933 URI: http://josefsson.org/