idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-13.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 (September 25, 2015) is 3136 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 1235, but not defined == Missing Reference: 'RFC5801' is mentioned on line 1273, but not defined == Missing Reference: 'RFC5554' is mentioned on line 1267, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1240, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1244, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1249, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1255, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1261, but not defined ** Obsolete undefined reference: RFC 4402 (Obsoleted by RFC 7802) == Missing Reference: 'RFC6680' is mentioned on line 1279, but not defined == Missing Reference: 'RFC7056' is mentioned on line 1285, 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) -- 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 (~~), 12 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: March 28, 2016 SJD AB 6 September 25, 2015 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-13.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 March 28, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7 62 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 10 63 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 64 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 66 4.4. User Authentication with Identity Provider . . . . . . . . 11 67 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11 68 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 11 70 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13 71 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13 72 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14 73 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 15 74 5.3.1. Generated by Identity Provider . . . . . . . . . . . . 15 75 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16 76 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 17 77 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17 78 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 17 79 5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18 80 5.6.2. Service Naming Considerations . . . . . . . . . . . . 19 81 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 83 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28 84 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 85 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 87 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30 88 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 91 9.2. Normative References for GSS-API Implementers . . . . . . 32 92 9.3. Informative References . . . . . . . . . . . . . . . . . . 33 93 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 35 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 95 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 38 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 98 1. Introduction 100 Security Assertion Markup Language (SAML) 2.0 101 [OASIS.saml-core-2.0-os] is a modular specification that provides 102 various means for a user to be identified to a relying party (RP) 103 through the exchange of (typically signed) assertions issued by an 104 identity provider (IdP). It includes a number of protocols, protocol 105 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 106 [OASIS.saml-profiles-2.0-os] designed for different use cases. 107 Additional profiles and extensions are also routinely developed and 108 published. 110 Simple Authentication and Security Layer (SASL) [RFC4422] is a 111 generalized mechanism for identifying and authenticating a user and 112 for optionally negotiating a security layer for subsequent protocol 113 interactions. SASL is used by application protocols like IMAP, POP 114 and XMPP [RFC3920]. The effect is to make authentication modular, so 115 that newer authentication mechanisms can be added as needed. 117 The Generic Security Service Application Program Interface (GSS-API) 118 [RFC2743] provides a framework for applications to support multiple 119 authentication mechanisms through a unified programming interface. 120 This document defines a pure SASL mechanism for SAML, but it conforms 121 to the bridge between SASL and the GSS-API called GS2 [RFC5801]. 122 This means that this document defines both a SASL mechanism and a 123 GSS-API mechanism. The GSS-API interface is optional for SASL 124 implementers, and the GSS-API considerations can be avoided in 125 environments that use SASL directly without GSS-API. 127 The mechanisms specified in this document allow a SASL- or GSS-API- 128 enabled server to act as a SAML relying party, or service provider 129 (SP), by advertising this mechanism as an option for SASL or GSS-API 130 clients that support the use of SAML to communicate identity and 131 attribute information. Clients supporting this mechanism are termed 132 "enhanced clients" in SAML terminology because they understand the 133 federated authentication model and have specific knowledge of the 134 IdP(s) associated with the user. This knowledge, and the ability to 135 act on it, addresses a significant problem with browser-based SAML 136 profiles known as the "discovery", or "where are you from?" (WAYF) 137 problem. In a "dumb" client such as a web browser, various intrusive 138 user interface techniques are used to determine the appropriate IdP 139 to use because the request to the IdP is generated as an HTTP 140 redirect by the RP, which does not generally have prior knowledge of 141 the IdP to use. Obviating the need for the RP to interact with the 142 client to determine the right IdP (and its network location) is both 143 a user interface and security improvement. 145 The SAML mechanism described in this document is an adaptation of an 146 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 147 (V2.0) [SAMLECP20]. 149 Figure 1 describes the interworking between SAML and SASL: this 150 document requires enhancements to the RP and to the client (as the 151 two SASL communication endpoints) but no changes to the SAML IdP are 152 assumed apart from its support for the applicable SAML profile. To 153 accomplish this, a SAML protocol exchange between the RP and the IdP, 154 brokered by the client, is tunneled within SASL. There is no assumed 155 communication between the RP and the IdP, but such communication may 156 occur in conjunction with additional SAML-related profiles not in 157 scope for this document. 159 +-----------+ 160 | SAML | 161 | Relying | 162 | Party | 163 | | 164 +-----------+ 165 ^ 166 +--|--+ 167 | S| | 168 S | A| | 169 A | M| | 170 S | L| | 171 L | | | 172 | | | 173 +--|--+ 174 +------------+ v 175 | | +----------+ 176 | SAML | SAML SOAP | | 177 | Identity |<--------------->| Client | 178 | Provider | Binding | | 179 +------------+ +----------+ 181 Figure 1: Interworking Architecture 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 The reader is also assumed to be familiar with the terms used in the 190 SAML 2.0 specification, and an understanding of the Enhanced Client 191 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 192 this mechanism explicitly reuses and references it. 194 This document can be implemented without knowledge of GSS-API since 195 the normative aspects of the GS2 protocol syntax have been duplicated 196 in this document. The document may also be implemented to provide a 197 GSS-API mechanism, and then knowledge of GSS-API is essential. To 198 faciliate these two variants, the references has been split into two 199 parts, one part that provides normative references for all readers, 200 and one part that adds additional normative references required for 201 implementers that wish to implement the GSS-API portion. 203 3. Applicability for Non-HTTP Use Cases 205 While SAML is designed to support a variety of application scenarios, 206 the profiles for authentication defined in the original standard are 207 designed around HTTP [RFC2616] applications. They are not, however, 208 limited to browsers, because it was recognized that browsers suffer 209 from a variety of functional and security deficiencies that would be 210 useful to avoid where possible. Specifically, the notion of an 211 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 212 thus the term "ECP") was specified for a software component that acts 213 somewhat like a browser from an application perspective, but includes 214 limited, but sufficient, awareness of SAML to play a more conscious 215 role in the authentication exchange between the RP and the IdP. What 216 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 217 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 219 1. The Enhanced Client requests a resource of a Relying Party (RP) 220 (via an HTTP request). In doing so, it advertises its "enhanced" 221 capability using HTTP headers. 223 2. The RP, desiring SAML authentication and noting the client's 224 capabilities, responds not with an HTTP redirect or form, but 225 with a SOAP [W3C.soap11] envelope containing a SAML 226 along with some supporting headers. This request 227 identifies the RP (and may be signed), and may provide hints to 228 the client as to what IdPs the RP finds acceptable, but the 229 choice of IdP is generally left to the client. 231 3. The client is then responsible for delivering the body of the 232 SOAP message to the IdP it is instructed to use (often via 233 configuration ahead of time). The user authenticates to the IdP 234 ahead of, during, or after the delivery of this message, and 235 perhaps explicitly authorizes the response to the RP. 237 4. Whether authentication succeeds or fails, the IdP responds with 238 its own SOAP envelope, generally containing a SAML 239 message for delivery to the RP. In a successful case, the 240 message will include one or more SAML elements 241 containing authentication, and possibly attribute, statements 242 about the subject. Either the response or each assertion is 243 signed, and the assertion(s) may be encrypted to a key negotiated 244 with or known to belong to the RP. 246 5. The client then delivers the SOAP envelope containing the 247 to the RP at a location the IdP directs (which acts as 248 an additional, though limited, defense against MITM attacks). 249 This completes the SAML exchange. 251 6. The RP now has sufficient identity information to approve the 252 original HTTP request or not, and acts accordingly. Everything 253 between the original request and this response can be thought of 254 as an "interruption" of the original HTTP exchange. 256 When considering this flow in the context of an arbitrary application 257 protocol and SASL, the RP and the client both must change their code 258 to implement this SASL mechanism, but the IdP can remain unmodified. 259 The existing RP/client exchange that is tunneled through HTTP maps 260 well to the tunneling of that same exchange in SASL. In the parlance 261 of SASL [RFC4422], this mechanism is "client-first" for consistency 262 with GS2. The steps are shown below: 264 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 265 mechanisms. 267 2. The client initiates a SASL authentication with SAML20EC or 268 SAML20EC-PLUS. 270 3. The server sends the client a challenge consisting of a SOAP 271 envelope containing its SAML . 273 4. The SASL client unpacks the SOAP message and communicates with 274 its chosen IdP to relay the SAML to it. This 275 communication, and the authentication with the IdP, proceeds 276 separately from the SASL process. 278 5. Upon completion of the exchange with the IdP, the client responds 279 to the SASL server with a SOAP envelope containing the SAML 280 it obtained, or a SOAP fault, as warranted. 282 6. The SASL Server indicates success or failure. 284 Note: The details of the SAML processing, which are consistent with 285 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 286 such that the client MUST interact with the IdP in order to complete 287 any SASL exchange with the RP. The assertions issued by the IdP for 288 the purposes of the profile, and by extension this SASL mechanism, 289 are short lived, and therefore cannot be cached by the client for 290 later use. 292 Encompassed in step four is the client-driven selection of the IdP, 293 authentication to it, and the acquisition of a response to provide to 294 the SASL server. These processes are all external to SASL. 296 Note also that unlike an HTTP-based profile, the IdP cannot 297 participate in the selection of, or evaluation of, the location to 298 which the SASL Client Response will be delivered by the client. The 299 use of GSS-API Channel Binding is an important mitigation of the risk 300 of a "Man in the Middle" attack between the client and RP, as is the 301 use of a negotiated or derived session key in whatever protocol is 302 secured by this mechanism. 304 With all of this in mind, the typical flow appears as follows: 306 SASL Serv. Client IdP 307 |>-----(1)----->| | Advertisement 308 | | | 309 |<-----(2)-----<| | Initiation 310 | | | 311 |>-----(3)----->| | SASL Server Response 312 | | | 313 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 314 | | | 315 |<-----(5)-----<| | SASL Client Response 316 | | | 317 |>-----(6)----->| | Server sends Outcome 318 | | | 320 ----- = SASL 321 - - - = SOAP over HTTPS (external to SASL) 323 Figure 2: Authentication flow 325 4. SAML SASL Mechanism Specification 327 Based on the previous figures, the following operations are defined 328 by the SAML SASL mechanism: 330 4.1. Advertisement 332 To advertise that a server supports this mechanism, during 333 application session initiation, it displays the name "SAML20EC" 334 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the 335 latter indicating support for channel binding). 337 4.2. Initiation 339 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 340 supported by the application protocol, the client MAY include an 341 initial response, otherwise it waits until the server has issued an 342 empty challenge (because the mechanism is client-first). 344 The format of the initial client response ("initresp") is as follows: 346 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 348 mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 349 "WantAuthnRequestsSigned" 351 del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation" 353 initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del] 355 The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate 356 whether the client supports channel binding. This takes the place of 357 the PAOS HTTP header extension used in [SAMLECP20] to indicate 358 channel binding support. 360 The optional "gs2-authzid" field holds the authorization identity, as 361 requested by the client. 363 The optional "hok" field is a constant that signals the client's 364 support for stronger security by means of a locally held key. This 365 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 366 to indicate "holder of key" support. 368 The optional "mut" field is a constant that signals the client's 369 desire for mutual authentication. If set, the SASL server MUST 370 digitally sign its SAML message. The URN constant 371 above is a single string; the linefeed is shown for RFC formatting 372 reasons. 374 The optional "del" field is a constant that signals the client's 375 desire for the acceptor to request an assertion usable for delegation 376 of the client's identity to the acceptor. 378 4.3. Server Response 380 The SASL server responds with a SOAP envelope constructed in 381 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 382 to the SOAP header requirements of the SAML PAOS Binding 383 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 384 profile. Various SOAP headers are also consumed by the client in 385 exactly the same manner prescribed by that section. 387 4.4. User Authentication with Identity Provider 389 Upon receipt of the Server Response (Section 4.3), the steps 390 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 391 performed between the client and the chosen IdP. The means by which 392 the client determines the IdP to use, and where it is located, are 393 out of scope of this mechanism. 395 The exact means of authentication to the IdP are also out of scope, 396 but clients supporting this mechanism MUST support HTTP Basic 397 Authentication as defined in [RFC2617] and TLS client authentication 398 as defined in [RFC5246]. 400 4.5. Client Response 402 Assuming a response is obtained from the IdP, the client responds to 403 the SASL server with a SOAP envelope constructed in accordance with 404 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 405 header requirements of the SAML PAOS Binding 406 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 407 profile. If the client is unable to obtain a response from the IdP, 408 or must otherwise signal, failure, it responds to the SASL server 409 with a SOAP envelope containing a SOAP fault. 411 4.6. Outcome 413 The SAML protocol exchange having completed, the SASL server will 414 transmit the outcome to the client depending on local validation of 415 the client responses. This outcome is transmitted in accordance with 416 the application protocol in use. 418 4.7. Additional Notes 420 Because this mechanism is an adaptation of an HTTP-based profile, 421 there are a few requirements outlined in [SAMLECP20] that make 422 reference to a response URL that is normally used to regulate where 423 the client returns information to the RP. There are also security- 424 related checks built into the profile that involve this location. 426 For compatibility with existing IdP and profile behavior, and to 427 provide for mutual authentication, the SASL server MUST populate the 428 responseConsumerURL and AssertionConsumerServiceURL attributes with 429 its service name. The service name is used directly rather than 430 transformed into an absolute URI if it is not already one, and MUST 431 be percent-encoded per [RFC3986]. 433 The value MUST be securely associated with the SAML entityID claimed 434 by the SASL server by the identity provider, such as through the use 435 of SAML metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, 436 a SASL service's role MUST contain a corresponding 437 whose Location attribute contains the 438 appropriate service name, as described above. The Binding attribute 439 MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or 440 "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with 441 older implementations of the ECP profile in existing identity 442 provider software). 444 Finally, note that the use of HTTP status signaling between the RP 445 and client mandated by [SAMLECP20] may not be applicable. 447 5. SAML EC GSS-API Mechanism Specification 449 This section and its sub-sections and all normative references of it 450 not referenced elsewhere in this document are INFORMATIONAL for SASL 451 implementors, but they are NORMATIVE for GSS-API implementors. 453 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 454 The messages are the same, but a) the GS2 header on the client's 455 first message is excluded when SAML EC is used as a GSS-API 456 mechanism, and b) the [RFC2743] section 3.1 initial context token 457 header is prefixed to the client's first authentication message 458 (context token). 460 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 461 IANA considerations). The DER encoding of the OID is TBD. 463 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 464 resulting in the "mutual-auth" option set in the initial client 465 response. The security context mutual_state flag is set to TRUE only 466 if the server digitally signs its SAML message and the 467 signature and signing credential are appropriately verified by the 468 identity provider. The identity provider signals this to the client 469 in an SOAP header block. 471 The lifetime of a security context established with this mechanism 472 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 473 any, in the element(s) of the SAML assertion(s) 474 received by the RP. By convention, in the rare case that multiple 475 valid/confirmed assertions containing elements are 476 received, the most restrictive SessionNotOnOrAfter is generally 477 applied. 479 5.1. GSS-API Credential Delegation 481 This mechanism can support credential delegation through the issuance 482 of SAML assertions that an identity provider will accept as proof of 483 authentication by a service on behalf of a subject. An initiator may 484 request delegation of its credentials by setting the "del" option 485 field in the initial client response to 486 "urn:oasis:names:tc:SAML:2.0:conditions:delegation". 488 An acceptor, upon receipt of this constant, requests a delegated 489 assertion by including in its message a 490 element containing an identifying the IdP as a 491 desired audience for the assertion(s) to be issued. In the event 492 that the specific identity provider to be used is unknown, the 493 constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be 494 used as a stand-in, per Section 2.3.2 of [SAMLECP20]. 496 Upon receipt of an assertion satisfying this property, and containing 497 a element that the acceptor can satisfy, the 498 security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set 499 to TRUE. 501 The identity provider, if it issues a delegated assertion to the 502 acceptor, MUST include in the SOAP response to the initiator a 503 SOAP header block, indicating that delegation was 504 enabled. It has no content, other than mandatory SOAP attributes (an 505 example follows): 507 512 Upon receipt of such a header block, the initiator MUST fail the 513 establishment of the security context if it did not request 514 delegation in its initial client response to the acceptor. It SHOULD 515 signal this failure to the acceptor with a SOAP fault message in its 516 final client response. 518 As noted previously, the exact means of client authentication to the 519 IdP is formally out of scope of this mechanism. This extends to the 520 use of a delegation assertion as a means of authentication by an 521 acceptor acting as an initiator. In practice, some profile of 522 [WSS-SAML] is used to attach the assertion and a confirmation proof 523 to the SOAP message from the client to the IdP. 525 5.2. GSS-API Channel Binding 527 GSS-API channel binding [RFC5554] is a protected facility for 528 exchanging a cryptographic name for an enclosing channel between the 529 initiator and acceptor. The initiator sends channel binding data and 530 the acceptor confirms that channel binding data has been checked. 532 The acceptor SHOULD accept any channel binding provided by the 533 initiator if null channel bindings are passed into 534 gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] 535 depend on this behavior of some Kerberos implementations. 537 The exchange and verification of channel binding information is 538 described by [SAMLECP20]. 540 5.3. Session Key Derivation 542 Some GSS-API features (discussed in the following sections) require a 543 session key be established as a result of security context 544 establishment. In the common case of a "bearer" assertion in SAML, a 545 mechanism is defined to communicate a key to both parties via the 546 identity provider. In other cases such as assertions based on 547 "holder of key" confirmation bound to a client-controlled key, there 548 may be additional methods defined in the future, and extension points 549 are provided for this purpose. 551 Information defining or describing the session key, or a process for 552 deriving one, is communicated between the initiator and acceptor 553 using a element, defined by the XML schema in 554 Appendix A. This element is a SOAP header block. The content of the 555 element further depends on the specific use in the mechanism. The 556 Algorithm XML attribute identifies a mechanism for key derivation. 557 It is omitted to identify the use of an Identity Provider-generated 558 key (see following section) or will contain a URI value identifying a 559 derivation mechanism defined outside this specification. Each header 560 block's mustUnderstand and actor attributes MUST be set to "1" and 561 "http://schemas.xmlsoap.org/soap/actor/next" respectively. 563 In the acceptor's first response message containing its SAML request, 564 one or more SOAP header blocks MUST be included. 565 The element MUST contain one or more elements containing 566 the number of a supported encryption type defined in accordance with 567 [RFC3961]. Encryption types should be provided in order of 568 preference by the acceptor. 570 In the final client response message, a single 571 SOAP header block MUST be included. A single element MUST 572 be included to identify the chosen encryption type used by the 573 initiator. 575 All parties MUST support the "aes128-cts-hmac-sha1-96" encryption 576 type, number 17, defined by [RFC3962]. 578 Further details depend on the mechanism used, one of which is 579 described in the following section. 581 5.3.1. Generated by Identity Provider 583 The identity provider, if issuing a bearer assertion for use with 584 this mechanism, SHOULD provide a generated key for use by the 585 initiator and acceptor. This key is used as pseudorandom input to 586 the "random-to-key" function for a specific encryption type defined 587 in accordance with [RFC3961]. The key is base64-encoded and placed 588 inside a element. The identity provider does 589 not participate in the selection of the encryption type and simply 590 generates enough pseudorandom bits to supply key material to the 591 other parties. 593 The resulting element is placed within the 594 element of the assertion issued. The identity provider 595 MUST encrypt the assertion (implying that it MUST have the means to 596 do so, typically knowledge of a key associated with the RP). If 597 multiple assertions are issued (allowed, but not typical), the 598 element need only be included in one of the assertions issued for use 599 by the relying party. 601 A copy of the element is also added as a SOAP header block in the 602 response from the identity provider to the client (and then removed 603 when constructing the response to the acceptor). 605 If this mechanism is used by the initiator, then the SOAP header block attached to the final client response 607 message will identify this via the omission of the Algorithm 608 attribute and will identify the chosen encryption type using the 609 element: 611 615 17 616 618 Both the initiator and acceptor MUST execute the chosen encryption 619 type's random-to-key function over the pseudorandom value provided by 620 the element. The result of that function is 621 used as the protocol and session key. Support for subkeys from the 622 initiator or acceptor is not specified. 624 5.3.2. Alternate Key Derivation Mechanisms 626 In the event that a client is proving possession of a secret or 627 private key, a formal key agreement algorithm might be supported. 628 This specification does not define such a mechanism, but the element is extensible to allow for future work in this 630 space by means of the Algorithm attribute and an optional child element to carry extensible content related to key 632 establishment. 634 However a key is derived, the element will identify 635 the chosen encrytion type, and both the initiator and acceptor MUST 636 execute the encryption type's random-to-key function over the result 637 of the key agreement or derivation process. The result of that 638 function is used as the protocol key. 640 5.4. Per-Message Tokens 642 The per-message tokens SHALL be the same as those for the Kerberos V5 643 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). 645 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 646 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 647 (GSS_C_INTEG_FLAG) security context flags are always set to TRUE. 649 The "protocol key" SHALL be a key established in a manner described 650 in the previous section. "Specific keys" are then derived as usual 651 as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. 653 The terms "protocol key" and "specific key" are Kerberos V5 terms 654 [RFC3961]. 656 SAML20EC is PROT_READY as soon as the SAML response message has been 657 seen. 659 5.5. Pseudo-Random Function (PRF) 661 The GSS-API has been extended with a Pseudo-Random Function (PRF) 662 interface in [RFC4401]. The purpose is to enable applications to 663 derive a cryptographic key from an established GSS-API security 664 context. This section defines a GSS_Pseudo_random that is applicable 665 for the SAML20EC GSS-API mechanism. 667 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 668 Kerberos V5 GSS-API mechanism [RFC4402]. There is no acceptor- 669 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 670 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 671 for the GSS_Pseudo_random() SHALL be the same as the key defined in 672 the previous section. 674 5.6. GSS-API Principal Name Types for SAML EC 676 Services that act as SAML relying parties are typically identified by 677 means of a URI called an "entityID". Clients that are named in the 678 element of a SAML assertion are typically identified by 679 means of a element, which is an extensible XML structure 680 containing, at minimum, an element value that names the subject and a 681 Format attribute. 683 In practice, a GSS-API client and server are unlikely to know in 684 advance the name of the initiator as it will be expressed by the SAML 685 identity provider upon completion of authentication. It is also 686 generally incorrect to assume that a particular acceptor name will 687 directly map into a particular RP entityID, because there is often a 688 layer of naming indirection between particular services on hosts and 689 the identity of a relying party in SAML terms. 691 To avoid complexity, and avoid unnecessary use of XML within the 692 naming layer, the SAML EC mechanism relies on the common/expected 693 name types used for acceptors and initiators, 694 GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism 695 provides for validation of the host-based service name in conjunction 696 with the SAML exchange. It does not attempt to solve the problem of 697 mapping between an initiator "username", the user's identity while 698 authenticating to the identity provider, and the information supplied 699 by the identity provider to the acceptor. These relationships must 700 be managed through local policy at the initiator and acceptor. 702 SAML-based information associated with the initiator SHOULD be 703 expressed to the acceptor using GSS-API naming extensions [RFC6680], 704 in accordance with [RFC7056]. 706 5.6.1. User Naming Considerations 708 The GSS_C_NT_USER_NAME form represents the name of an individual 709 user. Clients often rely on this value to determine the appropriate 710 credentials to use in authenticating to the identity provider, and 711 supply it to the server for use by the acceptor. 713 Upon successful completion of this mechanism, the server MUST 714 construct the authenticated initiator name based on the 715 element in the assertion it successfully validated. The name is 716 constructed as a UTF-8 string in the following form: 718 name = element-value "!" Format "!" NameQualifier 719 "!" SPNameQualifier "!" SPProvidedID 721 The "element-value" token refers to the content of the 722 element. The other tokens refer to the identically named XML 723 attributes defined for use with the element. If an attribute is not 724 present, which is common, it is omitted (i.e., replaced with the 725 empty string). The Format value is never omitted; if not present, 726 the SAML-equivalent value of 727 "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used. 729 Not all SAML assertions contain a element. In the 730 event that no such element is present, including the exceptional 731 cases of a element or a element that 732 cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used 733 for the initiator name. 735 As noted in the previous section, it is expected that most 736 applications able to rely on SAML authentication would make use of 737 naming extensions to obtain additional information about the user 738 based on the assertion. This is particularly true in the anonymous 739 case, or in cases in which the SAML name is pseudonymous or transient 740 in nature. The ability to express the SAML name in 741 GSS_C_NT_USER_NAME form is intended for compatibility with 742 applications that cannot make use of additional information. 744 5.6.2. Service Naming Considerations 746 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 747 on a host; it is textually represented as "service@host". This name 748 form is required by most SASL profiles and is used by many existing 749 applications that use the Kerberos GSS-API mechanism. As noted above 750 in the SASL mechanism notes, such a name is used directly by this 751 mechanism as the effective AssertionConsumerService "location" 752 associated with the service. 754 This value is used in the construction of the responseConsumerURL and 755 AssertionConsumerServiceURL attributes, and for eventual comparison 756 and validation by the client before completing the exchange. The 757 service name is used directly rather than transformed into an 758 absolute URI if it is not already one, and MUST be percent-encoded 759 per [RFC3986]. The value MUST be securely associated with the SAML 760 entityID claimed by the server by the identity provider, such as 761 through the use of SAML metadata [OASIS.saml-metadata-2.0-os], as 762 described previously. 764 6. Example 766 Suppose the user has an identity at the SAML IdP saml.example.org and 767 a Jabber Identifier (jid) "somenode@example.com", and wishes to 768 authenticate his XMPP connection to xmpp.example.com (and example.com 769 and example.org have established a SAML-capable trust relationship). 770 The authentication on the wire would then look something like the 771 following: 773 Step 1: Client initiates stream to server: 775 779 Step 2: Server responds with a stream tag sent to client: 781 785 Step 3: Server informs client of available authentication mechanisms: 787 788 789 DIGEST-MD5 790 PLAIN 791 SAML20EC 792 793 795 Step 4: Client selects an authentication mechanism and sends the 796 initial client response (it is base64 encoded as specified by the 797 XMPP SASL protocol profile): 799 800 biwsLCw= 801 803 The initial response is "n,,,," which signals that channel binding is 804 not used, there is no authorization identity, and the client does not 805 support key-based confirmation, or want mutual authentication or 806 delegation. 808 Step 5: Server sends a challenge to client in the form of a SOAP 809 envelope containing its SAML : 811 812 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 813 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 814 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 815 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 816 ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy 817 MDAzLTA4IgogICAgICBtZXNzYWdlSUQ9ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRl 818 cnN0YW5kPSIxIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2Fw 819 Lm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIHJlc3BvbnNlQ29uc3VtZXJVUkw9 820 InhtcHBAeG1wcC5leGFtcGxlLmNvbSIKICAgICAgc2VydmljZT0idXJuOm9hc2lz 821 Om5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4KICAgIDxlY3A6 822 UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M 823 OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No 824 ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu 825 ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t 826 Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv 827 c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz 828 aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s 829 ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv 830 YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT 831 OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l 832 eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+MTc8L3NhbWxlYzpFbmNUeXBlPgog 833 ICAgICA8c2FtbGVjOkVuY1R5cGU+MTg8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNh 834 bWxlYzpTZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxz 835 YW1scDpBdXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9u 836 PSIyLjAiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAg 837 IEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4bXBwLmV4YW1wbGUu 838 Y29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9InVybjpvYXNpczpu 839 YW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAgaHR0cHM6Ly94bXBw 840 LmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAgICAgIDxzYW1scDpO 841 YW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAgICAgRm9ybWF0PSJ1 842 cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZvcm1hdDpwZXJzaXN0 843 ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQgQ29tcGFy 844 aXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+ 845 CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQ 846 YXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9zYW1sOkF1dGhuQ29u 847 dGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV4 848 dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6Qm9keT4KPC9TOkVu 849 dmVsb3BlPgo= 850 851 The Base64 [RFC4648] decoded envelope: 853 857 858 863 867 https://xmpp.example.com 868 869 873 17 874 18 875 876 877 878 881 882 https://xmpp.example.com 883 884 886 887 888 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 889 890 891 892 893 895 Step 5 (alt): Server returns error to client: 897 898 899 900 902 Step 6: Client relays the request to IdP in a SOAP message 903 transmitted over HTTP (over TLS). HTTP portion not shown, use of 904 Basic Authentication is assumed. The body of the SOAP envelope is 905 exactly the same as received in the previous step. 907 911 912 913 914 915 916 918 Step 7: IdP responds to client with a SOAP response containing a SAML 919 containing a short-lived SSO assertion (shown as an 920 encrypted variant in the example). A generated key is included in 921 the assertion and in a header for the client. 923 927 928 931 932 3w1wSBKUosRLsU69xGK7dg== 933 934 935 936 939 https://saml.example.org 940 941 943 944 945 946 947 948 949 951 Step 8: Client sends SOAP envelope containing the SAML as 952 a response to the SASL server's challenge: 954 955 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 956 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 957 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 958 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 959 ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6 960 MjAwMy0wOCIKICAgICAgUzphY3Rvcj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 961 cmcvc29hcC9hY3Rvci9uZXh0IgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIiBy 962 ZWZUb01lc3NhZ2VJRD0iNmMzYTRmOGI5YzJkIi8+CiAgICA8c2FtbGVjOlNlc3Np 963 b25LZXkgeG1sbnM6c2FtbGVjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNhbWxl 964 YyIKICAgICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29h 965 cC9lbnZlbG9wZS8iCiAgICAgIFM6bXVzdFVuZGVyc3RhbmQ9IjEiCiAgICAgIFM6 966 YWN0b3I9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvYWN0b3IvbmV4 967 dCI+CiAgICAgIDxzYW1sZWM6RW5jVHlwZT5hZXMxMjgtY3RzLWhtYWMtc2hhMS05 968 Njwvc2FtbGVjOkVuY1R5cGU+CiAgICA8c2FtbGVjOlNlc3Npb25LZXk+CiAgPC9T 969 OkhlYWRlcj4KICA8UzpCb2R5PgogICAgPHNhbWxwOlJlc3BvbnNlIElEPSJkNDNo 970 OTRyMzg5MzA5ciIgVmVyc2lvbj0iMi4wIgogICAgICAgIElzc3VlSW5zdGFudD0i 971 MjAwNy0xMi0xMFQxMTo0MjozNFoiIEluUmVzcG9uc2VUbz0iYzNhNGY4YjljMmQi 972 CiAgICAgICAgRGVzdGluYXRpb249InhtcHBAeG1wcC5leGFtcGxlLmNvbSI+CiAg 973 ICAgIDxzYW1sOklzc3Vlcj5odHRwczovL3NhbWwuZXhhbXBsZS5vcmc8L3NhbWw6 974 SXNzdWVyPgogICAgICA8c2FtbHA6U3RhdHVzPgogICAgICAgIDxzYW1scDpTdGF0 975 dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 976 TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg 977 ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl 978 bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj 979 ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft 980 bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K 981 983 The Base64 [RFC4648] decoded envelope: 985 989 990 993 997 17 998 999 1000 1001 1004 https://saml.example.org 1005 1006 1008 1009 1010 1011 1012 1013 1014 1016 Step 9: Server informs client of successful authentication: 1018 1020 Step 9 (alt): Server informs client of failed authentication: 1022 1023 1024 1025 1027 Step 10: Client initiates a new stream to server: 1029 1033 Step 11: Server responds by sending a stream header to client along 1034 with any additional features (or an empty features element): 1036 1039 1040 1041 1042 1044 Step 12: Client binds a resource: 1046 1047 1048 someresource 1049 1050 1052 Step 13: Server informs client of successful resource binding: 1054 1055 1056 somenode@example.com/someresource 1057 1058 1060 Please note: line breaks were added to the base64 for clarity. 1062 7. Security Considerations 1064 This section will address only security considerations associated 1065 with the use of SAML with SASL applications. For considerations 1066 relating to SAML in general, the reader is referred to the SAML 1067 specification and to other literature. Similarly, for general SASL 1068 Security Considerations, the reader is referred to that 1069 specification. 1071 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 1072 optional support for channel binding and use of "Holder of Key" 1073 subject confirmation. The former is strongly recommended for use 1074 with this mechanism to detect "Man in the Middle" attacks between the 1075 client and the RP without relying on flawed commercial TLS 1076 infrastructure. The latter may be impractical in many cases, but is 1077 a valuable way of strengthening client authentication, protecting 1078 against phishing, and improving the overall mechanism. 1080 7.1. Risks Left Unaddressed 1082 The adaptation of a web-based profile that is largely designed around 1083 security-oblivious clients and a bearer model for security token 1084 validation results in a number of basic security exposures that 1085 should be weighed against the compatibility and client simplification 1086 benefits of this mechanism. 1088 When channel binding is not used, protection against "Man in the 1089 Middle" attacks is left to lower layer protocols such as TLS, and the 1090 development of user interfaces able to implement that has not been 1091 effectively demonstrated. Failure to detect a MITM can result in 1092 phishing of the user's credentials if the attacker is between the 1093 client and IdP, or the theft and misuse of a short-lived credential 1094 (the SAML assertion) if the attacker is able to impersonate a RP. 1095 SAML allows for source address checking as a minor mitigation to the 1096 latter threat, but this is often impractical. IdPs can mitigate to 1097 some extent the exposure of personal information to RP attackers by 1098 encrypting assertions with authenticated keys. 1100 7.2. User Privacy 1102 The IdP is aware of each RP that a user logs into. There is nothing 1103 in the protocol to hide this information from the IdP. It is not a 1104 requirement to track the activity, but there is nothing technically 1105 that prohibits the collection of this information. Servers should be 1106 aware that SAML IdPs will track - to some extent - user access to 1107 their services. This exposure extends to the use of session keys 1108 generated by the IdP to secure messages between the parties, but note 1109 that when bearer assertions are involved, the IdP can freely 1110 impersonate the user to any relying party in any case. 1112 It is also out of scope of the mechanism to determine under what 1113 conditions an IdP will release particular information to a relying 1114 party, and it is generally unclear in what fashion user consent could 1115 be established in real time for the release of particular 1116 information. The SOAP exchange with the IdP does not preclude such 1117 interaction, but neither does it define that interoperably. 1119 7.3. Collusion between RPs 1121 Depending on the information supplied by the IdP, it may be possible 1122 for RPs to correlate data that they have collected. By using the 1123 same identifier to log into every RP, collusion between RPs is 1124 possible. SAML supports the notion of pairwise, or targeted/ 1125 directed, identity. This allows the IdP to manage opaque, pairwise 1126 identifiers for each user that are specific to each RP. However, 1127 correlation is often possible based on other attributes supplied, and 1128 is generally a topic that is beyond the scope of this mechanism. It 1129 is sufficient to say that this mechanism does not introduce new 1130 correlation opportunities over and above the use of SAML in web-based 1131 use cases. 1133 8. IANA Considerations 1135 8.1. GSS-API and SASL Mechanism Registration 1137 The IANA is requested to assign a new entry for this GSS mechanism in 1138 the sub-registry for SMI Security for Mechanism Codes, whose prefix 1139 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 1140 reference this specification in the registry. 1142 The IANA is requested to register the following SASL profile: 1144 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 1146 Security Considerations: See this document 1148 Published Specification: See this document 1150 For further information: Contact the authors of this document. 1152 Owner/Change controller: the IETF 1154 Note: None 1156 8.2. XML Namespace Name for SAML-EC 1158 A URN sub-namespace for XML constructs introduced by this mechanism 1159 is defined as follows: 1161 URI: urn:ietf:params:xml:ns:samlec 1163 Specification: See Appendix A of this document. 1165 Description: This is the XML namespace name for XML constructs 1166 introduced by the SAML Enhanced Client SASL and GSS-API Mechanisms. 1168 Registrant Contact: the IESG 1170 9. References 1172 9.1. Normative References 1174 [OASIS.saml-bindings-2.0-os] 1175 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1176 Maler, "Bindings for the OASIS Security Assertion Markup 1177 Language (SAML) V2.0", OASIS 1178 Standard saml-bindings-2.0-os, March 2005. 1180 [OASIS.saml-core-2.0-os] 1181 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1182 "Assertions and Protocol for the OASIS Security Assertion 1183 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1184 2.0-os, March 2005. 1186 [OASIS.saml-profiles-2.0-os] 1187 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1188 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1189 Security Assertion Markup Language (SAML) V2.0", OASIS 1190 Standard OASIS.saml-profiles-2.0-os, March 2005. 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1194 RFC2119, March 1997, 1195 . 1197 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1198 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1199 Authentication: Basic and Digest Access Authentication", 1200 RFC 2617, DOI 10.17487/RFC2617, June 1999, 1201 . 1203 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1204 Resource Identifier (URI): Generic Syntax", STD 66, 1205 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1206 . 1208 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1209 Authentication and Security Layer (SASL)", RFC 4422, 1210 DOI 10.17487/RFC4422, June 2006, 1211 . 1213 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1214 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1215 . 1217 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1218 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1219 RFC5246, August 2008, 1220 . 1222 [SAMLECP20] 1223 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1224 Version 2.0", OASIS Committee Specification OASIS.sstc- 1225 saml-ecp-v2.0-cs01, August 2013. 1227 [W3C.soap11] 1228 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1229 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1230 "Simple Object Access Protocol (SOAP) 1.1", W3C 1231 Note soap11, May 2000, . 1233 9.2. Normative References for GSS-API Implementers 1235 [RFC2743] Linn, J., "Generic Security Service Application Program 1236 Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ 1237 RFC2743, January 2000, 1238 . 1240 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1241 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, 1242 February 2005, . 1244 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1245 Encryption for Kerberos 5", RFC 3962, DOI 10.17487/ 1246 RFC3962, February 2005, 1247 . 1249 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1250 Version 5 Generic Security Service Application Program 1251 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1252 DOI 10.17487/RFC4121, July 2005, 1253 . 1255 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1256 Extension for the Generic Security Service Application 1257 Program Interface (GSS-API)", RFC 4401, DOI 10.17487/ 1258 RFC4401, February 2006, 1259 . 1261 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1262 Kerberos V Generic Security Service Application Program 1263 Interface (GSS-API) Mechanism", RFC 4402, DOI 10.17487/ 1264 RFC4402, February 2006, 1265 . 1267 [RFC5554] Williams, N., "Clarifications and Extensions to the 1268 Generic Security Service Application Program Interface 1269 (GSS-API) for the Use of Channel Bindings", RFC 5554, 1270 DOI 10.17487/RFC5554, May 2009, 1271 . 1273 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1274 Service Application Program Interface (GSS-API) Mechanisms 1275 in Simple Authentication and Security Layer (SASL): The 1276 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 1277 July 2010, . 1279 [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. 1280 Josefsson, "Generic Security Service Application 1281 Programming Interface (GSS-API) Naming Extensions", 1282 RFC 6680, DOI 10.17487/RFC6680, August 2012, 1283 . 1285 [RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1286 API Extensible Authentication Protocol (EAP) Mechanism", 1287 RFC 7056, DOI 10.17487/RFC7056, December 2013, 1288 . 1290 9.3. Informative References 1292 [OASIS.saml-metadata-2.0-os] 1293 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1294 "Metadata for the Security Assertion Markup Language 1295 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1296 March 2005. 1298 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1299 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1300 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 1301 RFC2616, June 1999, 1302 . 1304 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1305 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 1306 October 2004, . 1308 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1309 Kerberos and NTLM HTTP Authentication in Microsoft 1310 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 1311 . 1313 [W3C.REC-xmlschema-1] 1314 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1315 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, 1316 May 2001, . 1318 [WSS-SAML] 1319 Monzillo, R., "Web Services Security SAML Token Profile 1320 Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, 1321 May 2012. 1323 Appendix A. XML Schema 1325 The following schema formally defines the 1326 "urn:ietf:params:xml:ns:samlec" namespace used in this document, in 1327 conformance with [W3C.REC-xmlschema-1] While XML validation is 1328 optional, the schema that follows is the normative definition of the 1329 constructs it defines. Where the schema differs from any prose in 1330 this specification, the schema takes precedence. 1332 1343 1344 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1357 1359 1360 1361 1362 1363 1364 1365 1366 1367 1369 1370 1371 1372 1373 1374 1376 1378 Appendix B. Acknowledgments 1380 The authors would like to thank Klaas Wierenga, Sam Hartman, Nico 1381 Williams, Jim Basney, and Venkat Yekkirala for their contributions. 1383 Appendix C. Changes 1385 This section to be removed prior to publication. 1387 o 13, clarify SAML metadata usage, adding a recommended Binding 1388 value alongside the backward-compatibility usage of PAOS 1390 o 12, clarifying comments based on WG feedback, with a normative 1391 change to use enctype numbers instead of names 1393 o 11, update EAP Naming reference to RFC 1395 o 10, update SAML ECP reference to final CS 1397 o 09, align delegation signaling to updated ECP draft 1399 o 08, more corrections, added a delegation signaling header 1401 o 07, corrections, revised section on delegation 1403 o 06, simplified session key schema, moved responsibility for 1404 random-to-key to the endpoints, and defined advertisement of 1405 session key algorithm and enctypes by acceptor 1407 o 05, revised session key material, added requirement for random-to- 1408 key, revised XML schema to capture enctype name, updated GSS 1409 naming reference 1411 o 04, stripped down the session key material to simplify it, and 1412 define an IdP-brokered keying approach, moved session key XML 1413 constructs from OASIS draft into this one 1415 o 03, added TLS key export as a session key option, revised GSS 1416 naming material based on list discussion 1418 o 02, major revision of GSS-API material and updated references 1420 o 01, SSH language added, noted non-assumption of HTTP error 1421 handling, added guidance on life of security context. 1423 o 00, Initial Revision, first WG-adopted draft. Removed support for 1424 unsolicited SAML responses. 1426 Authors' Addresses 1428 Scott Cantor 1429 Shibboleth Consortium 1430 2740 Airport Drive 1431 Columbus, Ohio 43219 1432 United States 1434 Phone: +1 614 247 6147 1435 Email: cantor.2@osu.edu 1437 Simon Josefsson 1438 SJD AB 1439 Hagagatan 24 1440 Stockholm 113 47 1441 SE 1443 Email: simon@josefsson.org 1444 URI: http://josefsson.org/