idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-20.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 (May 10, 2021) is 1082 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAMLECP20' -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 2 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 M. Cullen 5 Expires: November 11, 2021 Painless Security 6 S. Josefsson 7 SJD AB 8 May 10, 2021 10 SAML Enhanced Client SASL and GSS-API Mechanisms 11 draft-ietf-kitten-sasl-saml-ec-20 13 Abstract 15 Security Assertion Markup Language (SAML) 2.0 is a generalized 16 framework for the exchange of security-related information between 17 asserting and relying parties. Simple Authentication and Security 18 Layer (SASL) and the Generic Security Service Application Program 19 Interface (GSS-API) are application frameworks that facilitate an 20 extensible authentication model, among other things. This document 21 specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages 22 the capabilities of a SAML-aware "enhanced client" to address 23 significant barriers to federated authentication in a manner that 24 encourages reuse of existing SAML bindings and profiles designed for 25 non-browser scenarios. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 11, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . 6 64 4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 8 65 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 68 4.4. User Authentication with Identity Provider . . . . . . . 10 69 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 70 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . 10 72 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 11 73 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 12 74 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 13 75 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . 13 76 5.3.1. Generated by Identity Provider . . . . . . . . . . . 14 77 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 15 78 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . 15 79 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . 15 80 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . 16 81 5.6.1. User Naming Considerations . . . . . . . . . . . . . 16 82 5.6.2. Service Naming Considerations . . . . . . . . . . . . 17 83 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . 26 86 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . 26 87 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 89 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 27 90 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . 27 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 93 9.2. Informative References . . . . . . . . . . . . . . . . . 30 94 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 31 95 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 96 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 33 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 99 1. Introduction 101 Security Assertion Markup Language (SAML) 2.0 102 [OASIS.saml-core-2.0-os] is a modular specification that provides 103 various means for a user to be identified to a relying party (RP) 104 through the exchange of (typically signed) assertions issued by an 105 identity provider (IdP). 107 Simple Authentication and Security Layer (SASL) [RFC4422] is a 108 generalized mechanism for identifying and authenticating a user and 109 for optionally negotiating a security layer for subsequent protocol 110 interactions. SASL is used by application protocols like IMAP 111 [RFC3501], the Post Office Protocol(POP [RFC1939]) and XMPP 112 [RFC6120]. The effect of SASL is to make authentication modular, so 113 that newer authentication mechanisms can be added as needed. 115 There are related protocols, protocol bindings 116 [OASIS.saml-bindings-2.0-os], and interoperability profiles 117 [OASIS.saml-profiles-2.0-os] designed for different use cases. 118 Additional profiles and extensions are also routinely developed and 119 published. 121 The Generic Security Service Application Program Interface (GSS-API) 122 [RFC2743] provides a framework for applications to support multiple 123 authentication mechanisms through a unified programming interface, as 124 well as additional optional cryptographic functionality. This 125 document defines a pure SASL mechanism for SAML, but it conforms to 126 the bridge between SASL and GSS-API called GS2 [RFC5801]. This means 127 that this document defines both a SASL mechanism and a GSS-API 128 mechanism. The GSS-API interface is optional for SASL implementers, 129 and the GSS-API considerations can be avoided in environments that 130 use SASL directly without GSS-API. 132 The mechanisms specified in this document allow a SASL- or GSS-API- 133 enabled server to act as a SAML relying party, or service provider 134 (SP), by advertising this mechanism as an option for SASL or GSS-API 135 clients that support the use of SAML to communicate identity and 136 attribute information. Clients supporting this mechanism are termed 137 "enhanced clients" in SAML terminology because they understand the 138 federated authentication model and have specific knowledge of the 139 IdP(s) associated with the user. This knowledge, and the ability to 140 act on it, addresses a significant problem with browser-based SAML 141 profiles known as the "discovery", or "where are you from?" (WAYF) 142 problem. In a "dumb" client such as a web browser, various intrusive 143 user interface techniques are used to determine the appropriate IdP 144 to use because the request to the IdP is generated as an HTTP 145 redirect by the RP, which does not generally have prior knowledge of 146 the IdP to use. Obviating the need for the RP to interact with the 147 client to determine the right IdP (and its network location) is both 148 a user interface and security improvement. 150 The SAML mechanism described in this document is an adaptation of an 151 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 152 (V2.0) [SAMLECP20]. 154 Figure 1 describes the interworking between SAML and SASL: this 155 document requires enhancements to the RP and to the client (as the 156 two SASL communication endpoints) but no changes to the SAML IdP are 157 assumed apart from its support for the applicable SAML profile. To 158 accomplish this, a SAML protocol exchange between the RP and the IdP, 159 brokered by the client, is tunneled within SASL. There is no assumed 160 communication between the RP and the IdP, but such communication may 161 occur in conjunction with additional SAML-related profiles not in 162 scope for this document. 164 +-----------+ 165 | SAML | 166 | Relying | 167 | Party | 168 | | 169 +-----------+ 170 ^ 171 +--|--+ 172 | S| | 173 S | A| | 174 A | M| | 175 S | L| | 176 L | | | 177 | | | 178 +--|--+ 179 +------------+ v 180 | | +----------+ 181 | SAML | SAML SOAP | | 182 | Identity |<--------------->| Client | 183 | Provider | Binding | | 184 +------------+ +----------+ 186 Figure 1: Interworking Architecture 188 +-------+ +-------+ +-------+ 189 | SAML | |Client | | SAML | 190 | IDP | | | | RP | 191 +---+---+ +---+---+ +---+---+ 192 | | | 193 | |---------------------->| 194 | | Resource Request | 195 | | | 196 | | | 197 |<----------------------+-----------------------| 198 | | SAML Auth Request | 199 | | | 200 | | | 201 |<--------------------->| | 202 | User Authentication | | 203 | | | 204 | | | 205 |-----------------------+---------------------->| 206 | SAML Auth Response | | 207 | | | 208 | | | 209 | |<----------------------| 210 | | Requested Resource | 211 | | | 213 Figure 2: Communication Flow 215 2. Terminology 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in BCP 220 14 [RFC2119][RFC8174] when, and only when, they appear in all 221 capitals, as shown here. 223 The reader is also assumed to be familiar with the terms used in the 224 SAML 2.0 specification, and an understanding of the Enhanced Client 225 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 226 this mechanism explicitly reuses and references it. 228 This document can be implemented without knowledge of GSS-API since 229 the normative aspects of the GS2 protocol syntax have been duplicated 230 in this document. The document may also be implemented to provide a 231 GSS-API mechanism, and then knowledge of GSS-API is essential. 233 3. Applicability for Non-HTTP Use Cases 235 While SAML is designed to support a variety of application scenarios, 236 the profiles for authentication defined in the original standard are 237 designed around HTTP [RFC7230] applications. They are not, however, 238 limited to browsers, because browsers do not always meet the needs of 239 more security-sensitive applications. Specifically, the notion of an 240 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 241 thus the term "ECP") was specified for a software component that acts 242 somewhat like a browser from an application perspective, but includes 243 limited, but sufficient, awareness of SAML to play a more conscious 244 role in the authentication exchange between the RP and the IdP. What 245 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 246 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 248 1. The Enhanced Client requests a resource of a Relying Party (RP) 249 (via an HTTP request). In doing so, it advertises its "enhanced" 250 capability using HTTP headers. 252 2. The RP, desiring SAML authentication and noting the client's 253 capabilities, responds not with an HTTP redirect or form, but 254 with a SOAP [W3C.soap11] envelope containing a SAML 255 along with some supporting headers. This request 256 identifies the RP (and may be signed), and may provide hints to 257 the client as to what IdPs the RP finds acceptable, but the 258 choice of IdP is generally left to the client. 260 3. The client is then responsible for delivering the body of the 261 SOAP message to the IdP it is instructed to use (often via out- 262 of-band configuration). The user authenticates to the IdP ahead 263 of, during, or after the delivery of this message, and perhaps 264 explicitly authorizes the response to the RP. 266 4. Whether authentication succeeds or fails, the IdP responds with 267 its own SOAP envelope, generally containing a SAML 268 message for delivery to the RP. In a successful case, the 269 message will include one or more SAML elements 270 containing authentication, and possibly attribute, statements 271 about the subject. Either the response or each assertion is 272 signed, and the assertion(s) may be encrypted to a key negotiated 273 with or known to belong to the RP. 275 5. The client then delivers the SOAP envelope containing the 276 to the RP at a location the IdP directs (which acts as 277 an additional, though limited, defense against MITM attacks). 278 This completes the SAML exchange. 280 6. The RP now has sufficient identity information to approve the 281 original HTTP request or not, and acts accordingly. Everything 282 between the original request and this response can be thought of 283 as an "interruption" of the original HTTP exchange. 285 When considering this flow in the context of an arbitrary application 286 protocol and SASL, the RP and the client both must change their code 287 to implement this SASL mechanism, but the IdP can remain unmodified. 288 The existing RP/client exchange that is tunneled through HTTP maps 289 well to the tunneling of that same exchange in SASL. In the parlance 290 of SASL [RFC4422], this mechanism is "client-first" for consistency 291 with GS2. The steps are shown below: 293 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 294 mechanisms. 296 2. The client initiates a SASL authentication with SAML20EC or 297 SAML20EC-PLUS. 299 3. The server sends the client a challenge consisting of a SOAP 300 envelope containing its SAML . 302 4. The SASL client unpacks the SOAP message and communicates with 303 its chosen IdP to relay the SAML to it. This 304 communication, and the authentication with the IdP, proceeds 305 separately from the SASL process. 307 5. Upon completion of the exchange with the IdP, the client responds 308 to the SASL server with a SOAP envelope containing the SAML 309 it obtained, or a SOAP fault, as warranted. 311 6. The SASL Server indicates success or failure. 313 Note: The details of the SAML processing, which are consistent with 314 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 315 such that the client MUST interact with the IdP in order to complete 316 any SASL exchange with the RP. The assertions issued by the IdP for 317 the purposes of the profile, and by extension this SASL mechanism, 318 are short lived, and therefore cannot be cached by the client for 319 later use. 321 Encompassed in step four is the client-driven selection of the IdP, 322 authentication to it, and the acquisition of a response to provide to 323 the SASL server. These processes are all external to SASL. 325 Note also that unlike an HTTP-based profile, the IdP cannot 326 participate in the selection of, or evaluation of, the location to 327 which the SASL Client Response will be delivered by the client. The 328 use of GSS-API Channel Binding is an important mitigation of the risk 329 of a "Man in the Middle" attack between the client and RP, as is the 330 use of a negotiated or derived session key in whatever protocol is 331 secured by this mechanism. 333 With all of this in mind, the typical flow appears as follows: 335 SASL Serv. Client IdP 336 |------(1)----->| | Advertisement 337 | | | 338 |<-----(2)------| | Initiation 339 | | | 340 |------(3)----->| | SASL Server Response 341 | | | 342 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 343 | | | 344 |<-----(5)------| | SASL Client Response 345 | | | 346 |------(6)----->| | Server sends Outcome 347 | | | 349 ----- = SASL 350 - - - = SOAP over HTTPS (external to SASL) 352 Figure 3: Authentication flow 354 4. SAML Enhanced Client SASL Mechanism Specification 356 Based on the previous figures, the following operations are defined 357 by the SAML SASL mechanism: 359 4.1. Advertisement 361 To advertise that a server supports this mechanism, during 362 application session initiation, it displays the name "SAML20EC" and/ 363 or "SAML20EC-PLUS" in the list of supported SASL mechanisms. 365 In accordance with [RFC5801] the "-PLUS" variant indicates that the 366 server supports channel binding and would be selected by a client 367 with that capability. 369 4.2. Initiation 371 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 372 supported by the application protocol, the client MAY include an 373 initial response, otherwise it waits until the server has issued an 374 empty challenge (because the mechanism is client-first). 376 The format of the initial client response ("initresp") is as follows: 378 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 380 mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 381 "WantAuthnRequestsSigned" 383 del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation" 385 initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del] 387 The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate 388 whether the client supports channel binding. This takes the place of 389 the PAOS HTTP header extension used in [SAMLECP20] to indicate 390 channel binding support. 392 The optional "gs2-authzid" field holds the authorization identity, as 393 requested by the client. 395 The optional "hok" field is a constant that signals the client's 396 support for stronger security by means of a locally held key. This 397 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 398 to indicate "holder of key" support. 400 The optional "mut" field is a constant that signals the client's 401 desire for mutual authentication. If set, the SASL server MUST 402 digitally sign its SAML message. The URN constant 403 above is a single string; the linefeed is shown for RFC formatting 404 reasons. 406 The optional "del" field is a constant that signals the client's 407 desire for the acceptor to request an assertion usable for delegation 408 of the client's identity to the acceptor. 410 4.3. Server Response 412 The SASL server responds with a SOAP envelope constructed in 413 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 414 to the SOAP header requirements of the SAML PAOS Binding 415 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 416 profile. Various SOAP headers are also consumed by the client in 417 exactly the same manner prescribed by that section. 419 4.4. User Authentication with Identity Provider 421 Upon receipt of the Server Response (Section 4.3), the steps 422 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 423 performed between the client and the chosen IdP. The means by which 424 the client determines the IdP to use, and where it is located, are 425 out of scope of this mechanism. 427 The exact means of authentication to the IdP are also out of scope, 428 but clients supporting this mechanism MUST support HTTP Basic 429 Authentication as defined in [RFC7617] and TLS 1.3 client 430 authentication as defined in [RFC8446]. 432 4.5. Client Response 434 Assuming a response is obtained from the IdP, the client responds to 435 the SASL server with a SOAP envelope constructed in accordance with 436 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 437 header requirements of the SAML PAOS Binding 438 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 439 profile. If the client is unable to obtain a response from the IdP, 440 or must otherwise signal failure, it responds to the SASL server with 441 a SOAP envelope containing a SOAP fault. 443 4.6. Outcome 445 The SAML protocol exchange having completed, the SASL server will 446 transmit the outcome to the client depending on local validation of 447 the client responses (including the assertion conveyed from the 448 chosen IDP). This outcome is transmitted in accordance with the 449 application protocol in use. 451 4.7. Additional Notes 453 Because this mechanism is an adaptation of an HTTP-based profile, 454 there are a few requirements outlined in [SAMLECP20] that make 455 reference to a response URL that is normally used to regulate where 456 the client returns information to the RP. There are also security- 457 related checks built into the profile that involve this location. 459 For compatibility with existing IdP and profile behavior, and to 460 provide for mutual authentication, the SASL server MUST populate the 461 responseConsumerURL and AssertionConsumerServiceURL attributes with 462 its service name. As discussed in Section 5.6.2, most SASL profiles 463 rely on a service name format of "service@host", but regardless of 464 the form, the service name is used directly rather than transformed 465 into an absolute URI if it is not already one, and MUST be percent- 466 encoded per [RFC3986]. 468 The IdP MUST securely associate the service name with the SAML 469 entityID claimed by the SASL server, such as through the use of SAML 470 metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL 471 service's role MUST contain a corresponding 472 whose Location attribute contains the 473 appropriate service name, as described above. The Binding attribute 474 MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or 475 "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with 476 older implementations of the ECP profile in existing IdP software). 478 Finally, note that the use of HTTP status signaling between the RP 479 and client mandated by [SAMLECP20] may not be applicable. 481 5. SAML EC GSS-API Mechanism Specification 483 This section and its sub-sections and all normative references of it 484 not referenced elsewhere in this document are INFORMATIONAL for SASL 485 implementors, but they are NORMATIVE for GSS-API implementors. 487 The SAML Enhanced Client SASL mechanism is also a GSS-API mechanism. 488 The messages are the same, but a) the GS2 [RFC5801] header on the 489 client's first authentication message is excluded when SAML EC is 490 used as a GSS-API mechanism, and b) the [RFC2743] section 3.1 initial 491 context token header is used for the client's first authentication 492 message (context token) instead, with the body of the message being 493 the same as for the SASL mechanism case. 495 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 496 IANA considerations). The DER encoding of the OID is TBD. 498 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 499 resulting in the "mut" option set in the initial client response. 500 The security context mutual_state flag is set to TRUE only if the 501 server digitally signs its SAML message and the 502 signature and signing credential are appropriately verified by the 503 IdP. The IdP signals this to the client in an 504 SOAP header block. 506 The lifetime of a security context established with this mechanism 507 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 508 any, in the element(s) of the SAML assertion(s) 509 received by the RP. By convention, in the rare case that multiple 510 valid/confirmed assertions containing elements are 511 received, the most restrictive SessionNotOnOrAfter is generally 512 applied. 514 5.1. GSS-API Credential Delegation 516 This mechanism can support credential delegation through the issuance 517 of SAML assertions that an IdP will accept as proof of authentication 518 by a service on behalf of a subject. An initiator may request 519 delegation of its credentials by setting the "del" option field in 520 the initial client response to 521 "urn:oasis:names:tc:SAML:2.0:conditions:delegation". 523 An acceptor, upon receipt of this constant, requests a delegated 524 assertion by including in its message a 525 element containing an identifying the IdP as a 526 desired audience for the assertion(s) to be issued. In the event 527 that the specific IdP to be used is unknown, the constant 528 "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be used as a 529 stand-in, per Section 2.3.2 of [SAMLECP20]. 531 Upon receipt of an assertion satisfying this property, and containing 532 a element that the acceptor can satisfy, the 533 security context will have its deleg_state flag (GSS_C_DELEG_FLAG) 534 set to TRUE. 536 The IdP, if it issues a delegated assertion to the acceptor, MUST 537 include in the SOAP response to the initiator a 538 SOAP header block, indicating that delegation was enabled. It has no 539 content, other than mandatory SOAP attributes (an example follows): 541 546 Upon receipt of such a header block, the initiator MUST fail the 547 establishment of the security context if it did not request 548 delegation in its initial client response to the acceptor. It SHOULD 549 signal this failure to the acceptor with a SOAP fault message in its 550 final client response. 552 As noted previously, the exact means of client authentication to the 553 IdP is formally out of scope of this mechanism. This extends to the 554 use of a delegation assertion as a means of authentication by an 555 acceptor acting as an initiator. In practice, some profile of 557 [WSS-SAML] is used to attach the assertion and a confirmation proof 558 to the SOAP message from the client to the IdP. 560 5.2. GSS-API Channel Binding 562 GSS-API channel binding [RFC5554] is a protected facility for 563 exchanging a cryptographic identifier for an enclosing channel 564 between the initiator and acceptor. The initiator sends channel 565 binding data and the acceptor confirms that channel binding data has 566 been checked. 568 The acceptor SHOULD accept any channel binding provided by the 569 initiator if null channel bindings are passed into 570 gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] 571 depend on this behavior of some Kerberos implementations. 573 The exchange and verification of channel binding information is 574 described by [SAMLECP20]. 576 5.3. Session Key Derivation 578 Some GSS-API features (discussed in the following sections) require a 579 session key be established as a result of security context 580 establishment. In the common case of a "bearer" assertion in SAML, a 581 mechanism is defined to communicate a key to both parties via the 582 IdP. In other cases such as assertions based on "holder of key" 583 confirmation bound to a client-controlled key, there may be 584 additional methods defined in the future, and extension points are 585 provided for this purpose. 587 Information defining or describing the session key, or a process for 588 deriving one, is communicated between the initiator and acceptor 589 using a element, defined by the XML schema in 590 Appendix A. This element is a SOAP header block. The content of the 591 element further depends on the specific use in the mechanism. The 592 Algorithm XML attribute identifies a mechanism for key derivation. 593 It is omitted to identify the use of an IdP-generated key (see 594 following section) or will contain a URI value identifying a 595 derivation mechanism defined outside this specification. Each header 596 block's mustUnderstand and actor attributes MUST be set to "1" and 597 "http://schemas.xmlsoap.org/soap/actor/next" respectively. 599 In the acceptor's first response message containing its SAML request, 600 one or more SOAP header blocks MUST be included. 601 The element MUST contain one or more elements containing 602 the number of a supported encryption type defined in accordance with 603 [RFC3961]. Encryption types should be provided in order of 604 preference by the acceptor. 606 In the final client response message, a single 607 SOAP header block MUST be included. A single element MUST 608 be included to identify the chosen encryption type used by the 609 initiator. 611 All parties MUST support the "aes128-cts-hmac-sha1-96" encryption 612 type, number 17, defined by [RFC3962]. 614 Further details depend on the mechanism used, one of which is 615 described in the following section. 617 5.3.1. Generated by Identity Provider 619 The IdP, if issuing a bearer assertion for use with this mechanism, 620 SHOULD provide a generated key for use by the initiator and acceptor. 621 This key is used as pseudorandom input to the "random-to-key" 622 function for a specific encryption type defined in accordance with 623 [RFC3961]. The key is base64-encoded and placed inside a 624 element. The IdP does not participate in the 625 selection of the encryption type and simply generates enough 626 pseudorandom bits to supply key material to the other parties. 628 The resulting element is placed within the 629 element of the assertion issued. The identity provider 630 MUST encrypt the assertion (implying that it MUST have the means to 631 do so, typically knowledge of a key associated with the RP). If 632 multiple assertions are issued (allowed, but not typical), the 633 element need only be included in one of the assertions issued for use 634 by the relying party. 636 A copy of the element is also added as a SOAP header block in the 637 response from the IdP to the client (and then removed when 638 constructing the response to the acceptor). 640 If this mechanism is used by the initiator, then the 641 SOAP header block attached to the final client 642 response message will identify this via the omission of the Algorithm 643 attribute and will identify the chosen encryption type using the 644 element: 646 650 17 651 652 Both the initiator and acceptor MUST execute the chosen encryption 653 type's random-to-key function over the pseudorandom value provided by 654 the element. The result of that function is 655 used as the protocol and session key. Support for subkeys from the 656 initiator or acceptor is not specified. 658 5.3.2. Alternate Key Derivation Mechanisms 660 In the event that a client is proving possession of a secret or 661 private key, a formal key agreement algorithm might be supported. 662 This specification does not define such a mechanism, but the 663 element is extensible to allow for future work in 664 this space by means of the Algorithm attribute and an optional 665 child element to carry extensible content related to key 666 establishment. 668 However a key is derived, the element will identify 669 the chosen encrytion type, and both the initiator and acceptor MUST 670 execute the encryption type's random-to-key function over the result 671 of the key agreement or derivation process. The result of that 672 function is used as the protocol key. 674 5.4. Per-Message Tokens 676 The per-message tokens SHALL be the same as those for the Kerberos V5 677 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). 679 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 680 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 681 (GSS_C_INTEG_FLAG) security context flags are always set to TRUE. 683 The "protocol key" SHALL be a key established in a manner described 684 in the previous section. "Specific keys" are then derived as usual 685 as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. 687 The terms "protocol key" and "specific key" are Kerberos V5 terms 688 [RFC3961]. 690 SAML20EC is PROT_READY as soon as the SAML response message has been 691 seen. 693 5.5. Pseudo-Random Function (PRF) 695 The GSS-API has been extended with a Pseudo-Random Function (PRF) 696 interface in [RFC4401]. The purpose is to enable applications to 697 derive a cryptographic key from an established GSS-API security 698 context. This section defines a GSS_Pseudo_random that is applicable 699 for the SAML20EC GSS-API mechanism. 701 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 702 Kerberos V5 GSS-API mechanism [RFC7802]. There is no acceptor- 703 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 704 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 705 for the GSS_Pseudo_random() SHALL be the same as the key defined in 706 the previous section. 708 5.6. GSS-API Principal Name Types for SAML EC 710 Services that act as SAML relying parties are typically identified by 711 means of a URI called an "entityID". Clients that are named in the 712 element of a SAML assertion are typically identified by 713 means of a element, which is an extensible XML structure 714 containing, at minimum, an element value that names the subject and a 715 Format attribute. 717 In practice, a GSS-API client and server are unlikely to know in 718 advance the name of the initiator as it will be expressed by the SAML 719 IdP upon completion of authentication. It is also generally 720 incorrect to assume that a particular acceptor name will directly map 721 into a particular RP entityID, because there is often a layer of 722 naming indirection between particular services on hosts and the 723 identity of a relying party in SAML terms. 725 To avoid complexity, and avoid unnecessary use of XML within the 726 naming layer, the SAML EC mechanism relies on the common/expected 727 name types used for acceptors and initiators, 728 GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism 729 provides for validation of the host-based service name in conjunction 730 with the SAML exchange. It does not attempt to solve the problem of 731 mapping between an initiator "username", the user's identity while 732 authenticating to the IdP, and the information supplied by the IdP to 733 the acceptor. These relationships must be managed through local 734 policy at the initiator and acceptor. 736 SAML-based information associated with the initiator SHOULD be 737 expressed to the acceptor using GSS-API naming extensions [RFC6680], 738 in a similar manner to [RFC7056]. 740 5.6.1. User Naming Considerations 742 The GSS_C_NT_USER_NAME form represents the name of an individual 743 user. Clients often rely on this value to determine the appropriate 744 credentials to use in authenticating to the IdP, and supply it to the 745 server for use by the acceptor. 747 Upon successful completion of this mechanism, the server MUST 748 construct the authenticated initiator name based on the 749 element in the assertion it successfully validated. The name is 750 constructed as a UTF-8 string in the following form: 752 name = element-value "!" Format "!" NameQualifier 753 "!" SPNameQualifier "!" SPProvidedID 755 The "element-value" token refers to the content of the 756 element. The other tokens refer to the identically named XML 757 attributes defined for use with the element. If an attribute is not 758 present, which is common, it is omitted (i.e., replaced with the 759 empty string). The Format value is never omitted; if not present, 760 the SAML-equivalent value of "urn:oasis:names:tc:SAML:1.1:nameid- 761 format:unspecified" is used. 763 Not all SAML assertions contain a element. In the 764 event that no such element is present, including the exceptional 765 cases of a element or a element that 766 cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used 767 for the initiator name. 769 As noted in the previous section, it is expected that most 770 applications able to rely on SAML authentication would make use of 771 naming extensions to obtain additional information about the user 772 based on the assertion. This is particularly true in the anonymous 773 case, or in cases in which the SAML name is pseudonymous or transient 774 in nature. The ability to express the SAML name in 775 GSS_C_NT_USER_NAME form is intended for compatibility with 776 applications that cannot make use of additional information. 778 5.6.2. Service Naming Considerations 780 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 781 on a host; it is textually represented as "service@host". This name 782 form is required by most SASL profiles and is used by many existing 783 applications that use the Kerberos GSS-API mechanism. As described 784 in in the SASL mechanism's Section 4.7, such a name is used directly 785 by this mechanism as the effective AssertionConsumerService 786 "location" associated with the service and applied in IdP 787 verification of the request against the claimed SAML entityID. 789 6. Example 791 Suppose the user has an identity at the SAML IdP saml.example.org and 792 a Jabber Identifier (jid) "somenode@example.com", and wishes to 793 authenticate his XMPP connection to xmpp.example.com (and example.com 794 and example.org have established a SAML-capable trust relationship). 795 The authentication on the wire would then look something like the 796 following: 798 Step 1: Client initiates stream to server: 800 804 Step 2: Server responds with a stream tag sent to client: 806 810 Step 3: Server informs client of available authentication mechanisms: 812 813 814 DIGEST-MD5 815 PLAIN 816 SAML20EC 817 818 820 Step 4: Client selects an authentication mechanism and sends the 821 initial client response (it is base64 encoded as specified by the 822 XMPP SASL protocol profile): 824 825 biwsLCw= 826 828 The initial response is "n,,,," which signals that channel binding is 829 not used, there is no authorization identity, and the client does not 830 support key-based confirmation, or want mutual authentication or 831 delegation. 833 Step 5: Server sends a challenge to client in the form of a SOAP 834 envelope containing its SAML : 836 837 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 838 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 839 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 840 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 841 ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy 842 MDAzLTA4IgogICAgICBtZXNzYWdlSUQ9ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRl 843 cnN0YW5kPSIxIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2Fw 844 Lm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIHJlc3BvbnNlQ29uc3VtZXJVUkw9 845 InhtcHBAeG1wcC5leGFtcGxlLmNvbSIKICAgICAgc2VydmljZT0idXJuOm9hc2lz 846 Om5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4KICAgIDxlY3A6 847 UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M 848 OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No 849 ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu 850 ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t 851 Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv 852 c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz 853 aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s 854 ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv 855 YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT 856 OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l 857 eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+MTc8L3NhbWxlYzpFbmNUeXBlPgog 858 ICAgICA8c2FtbGVjOkVuY1R5cGU+MTg8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNh 859 bWxlYzpTZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxz 860 YW1scDpBdXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9u 861 PSIyLjAiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAg 862 IEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4bXBwLmV4YW1wbGUu 863 Y29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9InVybjpvYXNpczpu 864 YW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAgaHR0cHM6Ly94bXBw 865 LmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAgICAgIDxzYW1scDpO 866 YW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAgICAgRm9ybWF0PSJ1 867 cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZvcm1hdDpwZXJzaXN0 868 ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQgQ29tcGFy 869 aXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+ 870 CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQ 871 YXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9zYW1sOkF1dGhuQ29u 872 dGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV4 873 dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6Qm9keT4KPC9TOkVu 874 dmVsb3BlPgo= 875 877 The Base64 [RFC4648] decoded envelope: 879 883 884 889 893 https://xmpp.example.com 894 895 899 17 900 18 901 902 903 904 907 908 https://xmpp.example.com 909 910 912 913 914 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 915 916 917 918 919 921 Step 5 (alt): Server returns error to client: 923 924 925 926 928 Step 6: Client relays the request to IdP in a SOAP message 929 transmitted over HTTP (over TLS). The HTTP portion is not shown, so 930 the use of Basic Authentication is assumed. The body of the SOAP 931 envelope is exactly the same as received in the previous step. 933 937 938 939 940 941 942 944 Step 7: IdP responds to client with a SOAP response containing a SAML 945 containing a short-lived SSO assertion (shown as an 946 encrypted variant in the example). A generated key is included in 947 the assertion and in a header for the client. 949 953 954 957 958 3w1wSBKUosRLsU69xGK7dg== 959 960 961 962 965 https://saml.example.org 966 967 969 970 971 972 973 974 975 977 Step 8: Client sends SOAP envelope containing the SAML as 978 a response to the SASL server's challenge: 980 981 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 982 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 983 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 984 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 985 ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6 986 MjAwMy0wOCIKICAgICAgUzphY3Rvcj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 987 cmcvc29hcC9hY3Rvci9uZXh0IgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIiBy 988 ZWZUb01lc3NhZ2VJRD0iNmMzYTRmOGI5YzJkIi8+CiAgICA8c2FtbGVjOlNlc3Np 989 b25LZXkgeG1sbnM6c2FtbGVjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNhbWxl 990 YyIKICAgICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29h 991 cC9lbnZlbG9wZS8iCiAgICAgIFM6bXVzdFVuZGVyc3RhbmQ9IjEiCiAgICAgIFM6 992 YWN0b3I9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvYWN0b3IvbmV4 993 dCI+CiAgICAgIDxzYW1sZWM6RW5jVHlwZT5hZXMxMjgtY3RzLWhtYWMtc2hhMS05 994 Njwvc2FtbGVjOkVuY1R5cGU+CiAgICA8c2FtbGVjOlNlc3Npb25LZXk+CiAgPC9T 995 OkhlYWRlcj4KICA8UzpCb2R5PgogICAgPHNhbWxwOlJlc3BvbnNlIElEPSJkNDNo 996 OTRyMzg5MzA5ciIgVmVyc2lvbj0iMi4wIgogICAgICAgIElzc3VlSW5zdGFudD0i 997 MjAwNy0xMi0xMFQxMTo0MjozNFoiIEluUmVzcG9uc2VUbz0iYzNhNGY4YjljMmQi 998 CiAgICAgICAgRGVzdGluYXRpb249InhtcHBAeG1wcC5leGFtcGxlLmNvbSI+CiAg 999 ICAgIDxzYW1sOklzc3Vlcj5odHRwczovL3NhbWwuZXhhbXBsZS5vcmc8L3NhbWw6 1000 SXNzdWVyPgogICAgICA8c2FtbHA6U3RhdHVzPgogICAgICAgIDxzYW1scDpTdGF0 1001 dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 1002 TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg 1003 ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl 1004 bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj 1005 ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft 1006 bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K 1007 1009 The Base64 [RFC4648] decoded envelope: 1011 1015 1016 1019 1023 17 1024 1025 1026 1027 1030 https://saml.example.org 1031 1032 1034 1035 1036 1037 1038 1039 1040 1042 Step 9: Server informs client of successful authentication: 1044 1046 Step 9 (alt): Server informs client of failed authentication: 1048 1049 1050 1051 1053 Step 10: Client initiates a new stream to server: 1055 1059 Step 11: Server responds by sending a stream header to client along 1060 with any additional features (or an empty features element): 1062 1065 1066 1067 1068 1070 Step 12: Client binds a resource: 1072 1073 1074 someresource 1075 1076 1078 Step 13: Server informs client of successful resource binding: 1080 1081 1082 somenode@example.com/someresource 1083 1084 1086 Please note: line breaks were added to the base64 for clarity. 1088 7. Security Considerations 1090 This section will address only security considerations associated 1091 with the use of SAML with SASL applications. For considerations 1092 relating to SAML in general, the reader is referred to the SAML 1093 specification and to other literature. Similarly, for general SASL 1094 Security Considerations, the reader is referred to that 1095 specification. 1097 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 1098 optional support for channel binding and use of "Holder of Key" 1099 subject confirmation. The former is strongly recommended for use 1100 with this mechanism to detect "Man in the Middle" attacks between the 1101 client and the RP without relying on the commercial TLS 1102 infrastructure that does not provide the level of assurance desired 1103 by sensitive SAML applications. The latter may be impractical in 1104 many cases, but is a valuable way of strengthening client 1105 authentication, protecting against phishing, and improving the 1106 overall mechanism. 1108 7.1. Risks Left Unaddressed 1110 The adaptation of a web-based profile that is largely designed around 1111 security-oblivious clients and a bearer model for security token 1112 validation results in a number of basic security exposures that 1113 should be weighed against the compatibility and client simplification 1114 benefits of this mechanism. 1116 When channel binding is not used, protection against "Man in the 1117 Middle" attacks is left solely to lower layer protocols such as TLS, 1118 and the development of user interfaces able to implement that has not 1119 been effectively demonstrated. Failure to detect a MITM can result 1120 in phishing of the user's credentials if the attacker is between the 1121 client and IdP, or the theft and misuse of a short-lived credential 1122 (the SAML assertion) if the attacker is able to impersonate a RP. 1123 SAML allows for source address checking as a minor mitigation to the 1124 latter threat, but this is often impractical. IdPs can mitigate to 1125 some extent the exposure of personal information to RP attackers by 1126 encrypting assertions with authenticated keys. 1128 7.2. User Privacy 1130 The IdP is aware of each RP that a user logs into. There is nothing 1131 in the protocol to hide this information from the IdP. It is not a 1132 requirement to track the activity, but there is nothing technically 1133 that prohibits the collection of this information. Servers should be 1134 aware that SAML IdPs will track - to some extent - user access to 1135 their services. This exposure extends to the use of session keys 1136 generated by the IdP to secure messages between the parties, but note 1137 that when bearer assertions are involved, the IdP can freely 1138 impersonate the user to any relying party in any case. 1140 It is also out of scope of the mechanism to determine under what 1141 conditions an IdP will release particular information to a relying 1142 party, and it is generally unclear in what fashion user consent could 1143 be established in real time for the release of particular 1144 information. The SOAP exchange with the IdP does not preclude such 1145 interaction, but neither does it define that interoperably. 1147 7.3. Collusion between RPs 1149 Depending on the information supplied by the IdP, it may be possible 1150 for RPs to correlate data that they have collected. By using the 1151 same identifier to log into every RP, collusion between RPs is 1152 possible. SAML supports the notion of pairwise, or targeted/ 1153 directed, identity. This allows the IdP to manage opaque, pairwise 1154 identifiers for each user that are specific to each RP. However, 1155 correlation is often possible based on other attributes supplied, and 1156 is generally a topic that is beyond the scope of this mechanism. It 1157 is sufficient to say that this mechanism does not introduce new 1158 correlation opportunities over and above the use of SAML in web-based 1159 use cases. 1161 8. IANA Considerations 1163 8.1. GSS-API and SASL Mechanism Registration 1165 The IANA is requested to assign a new entry for this GSS mechanism in 1166 the sub-registry for SMI Security for Mechanism Codes, whose prefix 1167 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 1168 reference this specification in the registry. 1170 The IANA is requested to register the following SASL profile: 1172 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 1174 Security Considerations: See this document 1176 Published Specification: See this document 1178 For further information: Contact the authors of this document. 1180 Owner/Change controller: the IETF 1182 Note: None 1184 8.2. XML Namespace Name for SAML-EC 1186 A URN sub-namespace for XML constructs introduced by this mechanism 1187 is defined as follows: 1189 URI: urn:ietf:params:xml:ns:samlec 1191 Specification: See Appendix A of this document. 1193 Description: This is the XML namespace name for XML constructs 1194 introduced by the SAML Enhanced Client SASL and GSS-API Mechanisms. 1196 Registrant Contact: the IESG 1198 9. References 1200 9.1. Normative References 1202 [OASIS.saml-bindings-2.0-os] 1203 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1204 Maler, "Bindings for the OASIS Security Assertion Markup 1205 Language (SAML) V2.0", OASIS Standard saml-bindings- 1206 2.0-os, March 2005. 1208 [OASIS.saml-core-2.0-os] 1209 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1210 "Assertions and Protocol for the OASIS Security Assertion 1211 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1212 2.0-os, March 2005. 1214 [OASIS.saml-profiles-2.0-os] 1215 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1216 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1217 Security Assertion Markup Language (SAML) V2.0", OASIS 1218 Standard OASIS.saml-profiles-2.0-os, March 2005. 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, 1222 DOI 10.17487/RFC2119, March 1997, 1223 . 1225 [RFC2743] Linn, J., "Generic Security Service Application Program 1226 Interface Version 2, Update 1", RFC 2743, 1227 DOI 10.17487/RFC2743, January 2000, 1228 . 1230 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1231 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 1232 2005, . 1234 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1235 Encryption for Kerberos 5", RFC 3962, 1236 DOI 10.17487/RFC3962, February 2005, 1237 . 1239 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1240 Resource Identifier (URI): Generic Syntax", STD 66, 1241 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1242 . 1244 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1245 Version 5 Generic Security Service Application Program 1246 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1247 DOI 10.17487/RFC4121, July 2005, 1248 . 1250 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1251 Extension for the Generic Security Service Application 1252 Program Interface (GSS-API)", RFC 4401, 1253 DOI 10.17487/RFC4401, February 2006, 1254 . 1256 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1257 Authentication and Security Layer (SASL)", RFC 4422, 1258 DOI 10.17487/RFC4422, June 2006, 1259 . 1261 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1262 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1263 . 1265 [RFC5554] Williams, N., "Clarifications and Extensions to the 1266 Generic Security Service Application Program Interface 1267 (GSS-API) for the Use of Channel Bindings", RFC 5554, 1268 DOI 10.17487/RFC5554, May 2009, 1269 . 1271 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1272 Service Application Program Interface (GSS-API) Mechanisms 1273 in Simple Authentication and Security Layer (SASL): The 1274 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 1275 July 2010, . 1277 [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. 1278 Josefsson, "Generic Security Service Application 1279 Programming Interface (GSS-API) Naming Extensions", 1280 RFC 6680, DOI 10.17487/RFC6680, August 2012, 1281 . 1283 [RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1284 API Extensible Authentication Protocol (EAP) Mechanism", 1285 RFC 7056, DOI 10.17487/RFC7056, December 2013, 1286 . 1288 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1289 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1290 . 1292 [RFC7802] Emery, S. and N. Williams, "A Pseudo-Random Function (PRF) 1293 for the Kerberos V Generic Security Service Application 1294 Program Interface (GSS-API) Mechanism", RFC 7802, 1295 DOI 10.17487/RFC7802, March 2016, 1296 . 1298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1300 May 2017, . 1302 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1303 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1304 . 1306 [SAMLECP20] 1307 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1308 Version 2.0", OASIS Committee Specification OASIS.sstc- 1309 saml-ecp-v2.0-cs01, August 2013. 1311 [W3C.soap11] 1312 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1313 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1314 "Simple Object Access Protocol (SOAP) 1.1", W3C 1315 Note soap11, May 2000, . 1317 9.2. Informative References 1319 [OASIS.saml-metadata-2.0-os] 1320 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1321 "Metadata for the Security Assertion Markup Language 1322 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1323 2005. 1325 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1326 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1327 . 1329 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1330 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1331 . 1333 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1334 Kerberos and NTLM HTTP Authentication in Microsoft 1335 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 1336 . 1338 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1339 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1340 March 2011, . 1342 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1343 Protocol (HTTP/1.1): Message Syntax and Routing", 1344 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1345 . 1347 [W3C.REC-xmlschema-1] 1348 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1349 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 1350 2001, . 1352 [WSS-SAML] 1353 Monzillo, R., "Web Services Security SAML Token Profile 1354 Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, 1355 May 2012. 1357 Appendix A. XML Schema 1359 The following schema formally defines the 1360 "urn:ietf:params:xml:ns:samlec" namespace used in this document, in 1361 conformance with [W3C.REC-xmlschema-1] While XML validation is 1362 optional, the schema that follows is the normative definition of the 1363 constructs it defines. Where the schema differs from any prose in 1364 this specification, the schema takes precedence. 1366 1377 1378 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1391 1393 1394 1395 1396 1397 1398 1399 1400 1401 1403 1404 1405 1406 1407 1408 1410 1412 Appendix B. Acknowledgments 1414 The authors would also like to thank Klaas Wierenga, Sam Hartman, 1415 Nico Williams, Jim Basney, Venkat Yekkirala, and Ben Kaduk for their 1416 contributions. 1418 Appendix C. Changes 1420 This section to be removed prior to publication. 1422 o 20, address nits and easy fixes from Ben Kaduk's AD review 1424 o 19, update obsoleted references 1426 o 15,16,17,18 avoid expiration 1428 o 14, address some minor comments 1430 o 13, clarify SAML metadata usage, adding a recommended Binding 1431 value alongside the backward-compatibility usage of PAOS 1433 o 12, clarifying comments based on WG feedback, with a normative 1434 change to use enctype numbers instead of names 1436 o 11, update EAP Naming reference to RFC 1438 o 10, update SAML ECP reference to final CS 1440 o 09, align delegation signaling to updated ECP draft 1442 o 08, more corrections, added a delegation signaling header 1444 o 07, corrections, revised section on delegation 1446 o 06, simplified session key schema, moved responsibility for 1447 random-to-key to the endpoints, and defined advertisement of 1448 session key algorithm and enctypes by acceptor 1450 o 05, revised session key material, added requirement for random-to- 1451 key, revised XML schema to capture enctype name, updated GSS 1452 naming reference 1454 o 04, stripped down the session key material to simplify it, and 1455 define an IdP-brokered keying approach, moved session key XML 1456 constructs from OASIS draft into this one 1458 o 03, added TLS key export as a session key option, revised GSS 1459 naming material based on list discussion 1461 o 02, major revision of GSS-API material and updated references 1463 o 01, SSH language added, noted non-assumption of HTTP error 1464 handling, added guidance on life of security context. 1466 o 00, Initial Revision, first WG-adopted draft. Removed support for 1467 unsolicited SAML responses. 1469 Authors' Addresses 1471 Scott Cantor 1472 Shibboleth Consortium 1473 1050 Carmack Rd 1474 Columbus, Ohio 43210 1475 United States 1477 Phone: +1 614 247 6147 1478 Email: cantor.2@osu.edu 1480 Margaret Cullen 1481 Painless Security 1482 4 High St, Suite 134 1483 North Andover, Massachusets 01845 1484 United States 1486 Phone: +1 781 405 7464 1487 Email: mrcullen42@painless-security.com 1489 Simon Josefsson 1490 SJD AB 1491 Hagagatan 24 1492 Stockholm 113 47 1493 SE 1495 Email: simon@josefsson.org 1496 URI: http://josefsson.org/