idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-10.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 23, 2013) is 3860 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 1224, but not defined == Missing Reference: 'RFC5801' is mentioned on line 1251, but not defined == Missing Reference: 'RFC5554' is mentioned on line 1246, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1227, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1230, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1233, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1238, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1242, but not defined ** Obsolete undefined reference: RFC 4402 (Obsoleted by RFC 7802) == Missing Reference: 'RFC6680' is mentioned on line 1256, but not defined == Missing Reference: 'I-D.ietf-abfab-gss-eap-naming' is mentioned on line 1219, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAMLECP20' -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 4 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 27, 2014 SJD AB 6 September 23, 2013 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-10.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 27, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 . . . . . . . . . . . . 16 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 . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . 34 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 95 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 37 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 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. Obviating the need for the RP to interact with the client 138 to determine the right IdP (and its network location) is both a user 139 interface and security improvement. 141 The SAML mechanism described in this document is an adaptation of an 142 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 143 (V2.0) [SAMLECP20], and therefore does not establish a separate 144 authentication, integrity and confidentiality mechanism. It is 145 anticipated that existing security layers, such as Transport Layer 146 Security (TLS) or Secure Shell (SSH), will continued to be used. 148 Figure 1 describes the interworking between SAML and SASL: this 149 document requires enhancements to the RP and to the client (as the 150 two SASL communication endpoints) but no changes to the SAML IdP are 151 assumed apart from its support for the applicable SAML profile. To 152 accomplish this, a SAML protocol exchange between the RP and the IdP, 153 brokered by the client, is tunneled within SASL. There is no assumed 154 communication between the RP and the IdP, but such communication may 155 occur in conjunction with additional SAML-related profiles not in 156 scope for this document. 158 +-----------+ 159 | SAML | 160 | Relying | 161 | Party | 162 | | 163 +-----------+ 164 ^ 165 +--|--+ 166 | S| | 167 S | A| | 168 A | M| | 169 S | L| | 170 L | | | 171 | | | 172 +--|--+ 173 +------------+ v 174 | | +----------+ 175 | SAML | SAML SOAP | | 176 | Identity |<--------------->| Client | 177 | Provider | Binding | | 178 +------------+ +----------+ 180 Figure 1: Interworking Architecture 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 The reader is also assumed to be familiar with the terms used in the 189 SAML 2.0 specification, and an understanding of the Enhanced Client 190 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 191 this mechanism explicitly reuses and references it. 193 This document can be implemented without knowledge of GSS-API since 194 the normative aspects of the GS2 protocol syntax have been duplicated 195 in this document. The document may also be implemented to provide a 196 GSS-API mechanism, and then knowledge of GSS-API is essential. To 197 faciliate these two variants, the references has been split into two 198 parts, one part that provides normative references for all readers, 199 and one part that adds additional normative references required for 200 implementers that wish to implement the GSS-API portion. 202 3. Applicability for Non-HTTP Use Cases 204 While SAML is designed to support a variety of application scenarios, 205 the profiles for authentication defined in the original standard are 206 designed around HTTP [RFC2616] applications. They are not, however, 207 limited to browsers, because it was recognized that browsers suffer 208 from a variety of functional and security deficiencies that would be 209 useful to avoid where possible. Specifically, the notion of an 210 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 211 thus the term "ECP") was specified for a software component that acts 212 somewhat like a browser from an application perspective, but includes 213 limited, but sufficient, awareness of SAML to play a more conscious 214 role in the authentication exchange between the RP and the IdP. What 215 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 216 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 218 1. The Enhanced Client requests a resource of a Relying Party (RP) 219 (via an HTTP request). In doing so, it advertises its "enhanced" 220 capability using HTTP headers. 222 2. The RP, desiring SAML authentication and noting the client's 223 capabilities, responds not with an HTTP redirect or form, but 224 with a SOAP [W3C.soap11] envelope containing a SAML 225 along with some supporting headers. This request 226 identifies the RP (and may be signed), and may provide hints to 227 the client as to what IdPs the RP finds acceptable, but the 228 choice of IdP is generally left to the client. 230 3. The client is then responsible for delivering the body of the 231 SOAP message to the IdP it is instructed to use (often via 232 configuration ahead of time). The user authenticates to the IdP 233 ahead of, during, or after the delivery of this message, and 234 perhaps explicitly authorizes the response to the RP. 236 4. Whether authentication succeeds or fails, the IdP responds with 237 its own SOAP envelope, generally containing a SAML 238 message for delivery to the RP. In a successful case, the 239 message will include one or more SAML elements 240 containing authentication, and possibly attribute, statements 241 about the subject. Either the response or each assertion is 242 signed, and the assertion(s) may be encrypted to a key negotiated 243 with or known to belong to the RP. 245 5. The client then delivers the SOAP envelope containing the 246 to the RP at a location the IdP directs (which acts as 247 an additional, though limited, defense against MITM attacks). 248 This completes the SAML exchange. 250 6. The RP now has sufficient identity information to approve the 251 original HTTP request or not, and acts accordingly. Everything 252 between the original request and this response can be thought of 253 as an "interruption" of the original HTTP exchange. 255 When considering this flow in the context of an arbitrary application 256 protocol and SASL, the RP and the client both must change their code 257 to implement this SASL mechanism, but the IdP can remain untouched. 258 The existing RP/client exchange that is tunneled through HTTP maps 259 well to the tunneling of that same exchange in SASL. In the parlance 260 of SASL [RFC4422], this mechanism is "client-first" for consistency 261 with GS2. The steps are shown below: 263 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 264 mechanisms. 266 2. The client initiates a SASL authentication with SAML20EC or 267 SAML20EC-PLUS. 269 3. The server sends the client a challenge consisting of a SOAP 270 envelope containing its SAML . 272 4. The SASL client unpacks the SOAP message and communicates with 273 its chosen IdP to relay the SAML to it. This 274 communication, and the authentication with the IdP, proceeds 275 separately from the SASL process. 277 5. Upon completion of the exchange with the IdP, the client responds 278 to the SASL server with a SOAP envelope containing the SAML 279 it obtained, or a SOAP fault, as warranted. 281 6. The SASL Server indicates success or failure. 283 Note: The details of the SAML processing, which are consistent with 284 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 285 such that the client MUST interact with the IdP in order to complete 286 any SASL exchange with the RP. The assertions issued by the IdP for 287 the purposes of the profile, and by extension this SASL mechanism, 288 are short lived, and therefore cannot be cached by the client for 289 later use. 291 Encompassed in step four is the client-driven selection of the IdP, 292 authentication to it, and the acquisition of a response to provide to 293 the SASL server. These processes are all external to SASL. 295 With all of this in mind, the typical flow appears as follows: 297 SASL Serv. Client IdP 298 |>-----(1)----->| | Advertisement 299 | | | 300 |<-----(2)-----<| | Initiation 301 | | | 302 |>-----(3)----->| | SASL Server Response 303 | | | 304 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 305 | | | 306 |<-----(5)-----<| | SASL Client Response 307 | | | 308 |>-----(6)----->| | Server sends Outcome 309 | | | 311 ----- = SASL 312 - - - = SOAP over HTTPS (external to SASL) 314 Figure 2: Authentication flow 316 4. SAML SASL Mechanism Specification 318 Based on the previous figures, the following operations are defined 319 by the SAML SASL mechanism: 321 4.1. Advertisement 323 To advertise that a server supports this mechanism, during 324 application session initiation, it displays the name "SAML20EC" 325 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the 326 latter indicating support for channel binding). 328 4.2. Initiation 330 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 331 supported by the application protocol, the client MAY include an 332 initial response, otherwise it waits until the server has issued an 333 empty challenge (because the mechanism is client-first). 335 The format of the initial client response ("initresp") is as follows: 337 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 339 mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 340 "WantAuthnRequestsSigned" 342 del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation" 344 initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del] 346 The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate 347 whether the client supports channel binding. This takes the place of 348 the PAOS HTTP header extension used in [SAMLECP20] to indicate 349 channel binding support. 351 The optional "gs2-authzid" field holds the authorization identity, as 352 requested by the client. 354 The optional "hok" field is a constant that signals the client's 355 support for stronger security by means of a locally held key. This 356 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 357 to indicate "holder of key" support. 359 The optional "mut" field is a constant that signals the client's 360 desire for mutual authentication. If set, the SASL server MUST 361 digitally sign its SAML message. The URN constant 362 above is a single string; the linefeed is shown for RFC formatting 363 reasons. 365 The optional "del" field is a constant that signals the client's 366 desire for the acceptor to request an assertion usable for delegation 367 of the client's identity to the acceptor. 369 4.3. Server Response 371 The SASL server responds with a SOAP envelope constructed in 372 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 373 to the SOAP header requirements of the SAML PAOS Binding 374 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 375 profile. Various SOAP headers are also consumed by the client in 376 exactly the same manner prescribed by that section. 378 4.4. User Authentication with Identity Provider 380 Upon receipt of the Server Response (Section 4.3), the steps 381 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 382 performed between the client and the chosen IdP. The means by which 383 the client determines the IdP to use, and where it is located, are 384 out of scope of this mechanism. 386 The exact means of authentication to the IdP are also out of scope, 387 but clients supporting this mechanism MUST support HTTP Basic 388 Authentication as defined in [RFC2617] and TLS client authentication 389 as defined in [RFC5246]. 391 4.5. Client Response 393 Assuming a response is obtained from the IdP, the client responds to 394 the SASL server with a SOAP envelope constructed in accordance with 395 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 396 header requirements of the SAML PAOS Binding 397 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 398 profile. If the client is unable to obtain a response from the IdP, 399 or must otherwise signal, failure, it responds to the SASL server 400 with a SOAP envelope containing a SOAP fault. 402 4.6. Outcome 404 The SAML protocol exchange having completed, the SASL server will 405 transmit the outcome to the client depending on local validation of 406 the client responses. This outcome is transmitted in accordance with 407 the application protocol in use. 409 4.7. Additional Notes 411 Because this mechanism is an adaptation of an HTTP-based profile, 412 there are a few requirements outlined in [SAMLECP20] that make 413 reference to a response URL that is normally used to regulate where 414 the client returns information to the RP. There are also security- 415 related checks built into the profile that involve this location. 417 For compatibility with existing IdP and profile behavior, and to 418 provide for mutual authentication, the SASL server MUST populate the 419 responseConsumerURL and AssertionConsumerServiceURL attributes with 420 its service name. The parties then perform the steps described in 421 [SAMLECP20] as usual. 423 Similarly, the use of HTTP status signaling between the RP and client 424 mandated by [SAMLECP20] may not be applicable. 426 5. SAML EC GSS-API Mechanism Specification 428 This section and its sub-sections and all normative references of it 429 not referenced elsewhere in this document are INFORMATIONAL for SASL 430 implementors, but they are NORMATIVE for GSS-API implementors. 432 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 433 The messages are the same, but a) the GS2 header on the client's 434 first message is excluded when SAML EC is used as a GSS-API 435 mechanism, and b) the [RFC2743] section 3.1 initial context token 436 header is prefixed to the client's first authentication message 437 (context token). 439 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 440 IANA considerations). The DER encoding of the OID is TBD. 442 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 443 resulting in the "mutual-auth" option set in the initial client 444 response. The security context mutual_state flag is set to TRUE only 445 if the server digitally signs its SAML message, and 446 the identity provider signals this to the client in an SOAP header block. 449 If the mutual_state flag is not requested, or is not set, then the 450 security layer managed by the application outside of the GSS-API 451 mechanism is responsible for authenticating the acceptor. In this 452 case, applications MUST match the server identity from the existing 453 security layer with the target name. For TLS, this matching MUST be 454 performed as discussed in [RFC6125]. For SSH, this matching MUST be 455 performed as discussed in [RFC4462]. 457 The lifetime of a security context established with this mechanism 458 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 459 any, in the element(s) of the SAML assertion(s) 460 received by the RP. By convention, in the rare case that multiple 461 valid/confirmed assertions containing elements are 462 received, the most restrictive SessionNotOnOrAfter is generally 463 applied. 465 5.1. GSS-API Credential Delegation 467 This mechanism supports credential delegation through the issuance of 468 SAML assertions that the issuing identity provider will accept as 469 proof of authentication by a service on behalf of a subject. An 470 initiator may request delegation of its credentials by setting the 471 "del" option field in the initial client response to 472 "urn:oasis:names:tc:SAML:2.0:conditions:delegation". 474 An acceptor, upon receipt of this constant, requests a delegated 475 assertion by including in its message a 476 element containing an identifying the IdP as a 477 desired audience for the assertion(s) to be issued. In the event 478 that the specific identity provider to be used is unknown, the 479 constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be 480 used as a stand-in, per Section 2.3.2 of [SAMLECP20]. 482 Upon receipt of an assertion satisfying this property, and containing 483 a element that the acceptor can satisfy, the 484 security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set 485 to TRUE. 487 The identity provider, if it issues a delegated assertion to the 488 acceptor, MUST include in the SOAP response to the initiator a 489 SOAP header block, indicating that delegation was 490 enabled. It has no content, other than mandatory SOAP attributes (an 491 example follows): 493 498 Upon receipt of such a header block, the initiator MUST fail the 499 establishment of the security context if it did not request 500 delegation in its initial client response to the acceptor. It SHOULD 501 signal this failure to the acceptor with a SOAP fault message in its 502 final client response. 504 As noted previously, the exact means of client authentication to the 505 IdP is formally out of scope of this mechanism. This extends to the 506 use of a delegation assertion as a means of authentication by an 507 acceptor acting as an initiator. In practice, some profile of 508 [WSS-SAML] is used to attach the assertion and a confirmation proof 509 to the SOAP message from the client to the IdP. 511 5.2. GSS-API Channel Binding 513 GSS-API channel binding [RFC5554] is a protected facility for 514 exchanging a cryptographic name for an enclosing channel between the 515 initiator and acceptor. The initiator sends channel binding data and 516 the acceptor confirms that channel binding data has been checked. 518 The acceptor SHOULD accept any channel binding provided by the 519 initiator if null channel bindings are passed into 520 gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] 521 depend on this behavior of some Kerberos implementations. 523 The exchange and verification of channel binding information is 524 described by [SAMLECP20]. 526 5.3. Session Key Derivation 528 Some GSS-API features (discussed in the following sections) require a 529 session key be established as a result of security context 530 establishment. In the common case of a "bearer" assertion in SAML, a 531 mechanism is defined to communicate a key to both parties via the 532 identity provider. In other cases such as assertions based on 533 "holder of key" confirmation bound to a client-controlled key, there 534 may be additional methods defined in the future, and extension points 535 are provided for this purpose. 537 Information defining or describing the session key, or a process for 538 deriving one, is communicated between the initiator and acceptor 539 using a element, defined by the XML schema in 540 Appendix A. This element is a SOAP header block. The content of the 541 element further depends on the specific use in the mechanism. The 542 Algorithm XML attribute identifies a mechanism for key derivation. 543 It is omitted to identify the use of an Identity Provider-generated 544 key (see following section) or will contain a URI value identifying a 545 derivation mechanism defined outside this specification. Each header 546 block's mustUnderstand and actor attributes MUST be set to "1" and 547 "http://schemas.xmlsoap.org/soap/actor/next" respectively. 549 In the acceptor's first response message containing its SAML request, 550 one or more SOAP header blocks MUST be included. 551 The element MUST contain one or more elements containing 552 the name of a supported encryption type defined in accordance with 553 [RFC3961]. Encryption types should be provided in order of 554 preference by the acceptor. 556 In the final client response message, a single 557 SOAP header block MUST be included. A single element MUST 558 be included to identify the chosen encryption type used by the 559 initiator. 561 All parties MUST support the "aes128-cts-hmac-sha1-96" encryption 562 type, defined by [RFC3962]. 564 Further details depend on the mechanism used, one of which is 565 described in the following section. 567 5.3.1. Generated by Identity Provider 569 The identity provider, if issuing a bearer assertion for use with 570 this mechanism, SHOULD provide a generated key for use by the 571 initiator and acceptor. This key is used as pseudorandom input to 572 the "random-to-key" function for a specific encryption type defined 573 in accordance with [RFC3961]. The key is base64-encoded and placed 574 inside a element. The identity provider does 575 not participate in the selection of the encryption type and simply 576 generates enough pseudorandom bits to supply key material to the 577 other parties. 579 The resulting element is placed within the 580 element of the assertion issued. The identity provider 581 SHOULD encrypt the assertion; if channel binding is not used, the 582 assertion MUST be encrypted. If multiple assertions are issued 583 (allowed, but not typical), the element need only be included in one 584 of the assertions issued for use by the relying party. 586 A copy of the element is also added as a SOAP header block in the 587 response from the identity provider to the client (and then removed 588 when constructing the response to the acceptor). 590 If this mechanism is used by the initiator, then the SOAP header block attached to the final client response 592 message will identify this via the omission of the Algorithm 593 attribute and will identify the chosen encryption type using the 594 element: 596 600 aes128-cts-hmac-sha1-96 601 603 Both the initiator and acceptor MUST execute the chosen encryption 604 type's random-to-key function over the pseudorandom value provided by 605 the element. The result of that function is 606 used as the protocol key. 608 5.3.2. Alternate Key Derivation Mechanisms 610 In the event that a client is proving possession of a secret or 611 private key, a formal key agreement algorithm might be supported. 612 This specification does not define such a mechanism, but the element is extensible to allow for future work in this 615 space by means of the Algorithm attribute and an optional child element to carry extensible content related to key 617 establishment. 619 However a key is derived, the element will identify 620 the chosen encrytion type, and both the initiator and acceptor MUST 621 execute the encryption type's random-to-key function over the result 622 of the key agreement or derivation process. The result of that 623 function is used as the protocol key. 625 5.4. Per-Message Tokens 627 The per-message tokens SHALL be the same as those for the Kerberos V5 628 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). 630 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 631 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 632 (GSS_C_INTEG_FLAG) security context flags are always set to TRUE. 634 The "protocol key" SHALL be a key established in a manner described 635 in the previous section. "Specific keys" are then derived as usual 636 as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. 638 The terms "protocol key" and "specific key" are Kerberos V5 terms 639 [RFC3961]. 641 SAML20EC is PROT_READY as soon as the SAML response message has been 642 seen. 644 5.5. Pseudo-Random Function (PRF) 646 The GSS-API has been extended with a Pseudo-Random Function (PRF) 647 interface in [RFC4401]. The purpose is to enable applications to 648 derive a cryptographic key from an established GSS-API security 649 context. This section defines a GSS_Pseudo_random that is applicable 650 for the SAML20EC GSS-API mechanism. 652 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 653 Kerberos V5 GSS-API mechanism [RFC4402]. There is no acceptor- 654 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 655 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 656 for the GSS_Pseudo_random() SHALL be the same as the key defined in 657 the previous section. 659 5.6. GSS-API Principal Name Types for SAML EC 661 Services that act as SAML relying parties are typically identified by 662 means of a URI called an "entityID". Clients that are named in the 663 element of a SAML assertion are typically identified by 664 means of a element, which is an extensible XML structure 665 containing, at minimum, an element value that names the subject and a 666 Format attribute. 668 In practice, a GSS-API client and server are unlikely to know in 669 advance the name of the initiator as it will be expressed by the SAML 670 identity provider upon completion of authentication. It is also 671 generally incorrect to assume that a particular acceptor name will 672 directly map into a particular RP entityID, because there is often a 673 layer of naming indirection between particular services on hosts and 674 the identity of a relying party in SAML terms. 676 To avoid complexity, and avoid unnecessary use of XML within the 677 naming layer, the SAML EC mechanism relies on the common/expected 678 name types used for acceptors and initiators, 679 GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism 680 provides for validation of the host-based service name in conjunction 681 with the SAML exchange. It does not attempt to solve the problem of 682 mapping between an initiator "username", the user's identity while 683 authenticating to the identity provider, and the information supplied 684 by the identity provider to the acceptor. These relationships must 685 be managed through local policy at the initiator and acceptor. 687 SAML-based information associated with the initiator SHOULD be 688 expressed to the acceptor using GSS-API naming extensions [RFC6680], 689 in accordance with [I-D.ietf-abfab-gss-eap-naming]. 691 5.6.1. User Naming Considerations 693 The GSS_C_NT_USER_NAME form represents the name of an individual 694 user. Clients often rely on this value to determine the appropriate 695 credentials to use in authenticating to the identity provider, and 696 supply it to the server for use by the acceptor. 698 Upon successful completion of this mechanism, the server MUST 699 construct the authenticated initiator name based on the 700 element in the assertion it successfully validated. The name is 701 constructed as a UTF-8 string in the following form: 703 name = element-value "!" Format "!" NameQualifier 704 "!" SPNameQualifier "!" SPProvidedID 706 The "element-value" token refers to the content of the 707 element. The other tokens refer to the identically named XML 708 attributes defined for use with the element. If an attribute is not 709 present, which is common, it is omitted (i.e., replaced with the 710 empty string). The Format value is never omitted; if not present, 711 the SAML-equivalent value of 712 "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used. 714 Not all SAML assertions contain a element. In the 715 event that no such element is present, including the exceptional 716 cases of a element or a element that 717 cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used 718 for the initiator name. 720 As noted in the previous section, it is expected that most 721 applications able to rely on SAML authentication would make use of 722 naming extensions to obtain additional information about the user 723 based on the assertion. This is particularly true in the anonymous 724 case, or in cases in which the SAML name is pseudonymous or transient 725 in nature. The ability to express the SAML name in 726 GSS_C_NT_USER_NAME form is intended for compatibility with 727 applications that cannot make use of additional information. 729 5.6.2. Service Naming Considerations 731 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 732 on a host; it is textually represented as "service@host". This name 733 form is required by most SASL profiles and is used by many existing 734 applications that use the Kerberos GSS-API mechanism. Such a name is 735 used directly by this mechanism as the effective 736 AssertionConsumerService "location" associated with the service. 738 This value is used in the construction of the responseConsumerURL and 739 AssertionConsumerServiceURL attributes, and for eventual comparison 740 and validation by the client before completing the exchange. The 741 value MUST be securely associated with the SAML entityID claimed by 742 the server by the identity provider, such as through the use of SAML 743 metadata [OASIS.saml-metadata-2.0-os]. 745 6. Example 747 Suppose the user has an identity at the SAML IdP saml.example.org and 748 a Jabber Identifier (jid) "somenode@example.com", and wishes to 749 authenticate his XMPP connection to xmpp.example.com (and example.com 750 and example.org have established a SAML-capable trust relationship). 751 The authentication on the wire would then look something like the 752 following: 754 Step 1: Client initiates stream to server: 756 760 Step 2: Server responds with a stream tag sent to client: 762 766 Step 3: Server informs client of available authentication mechanisms: 768 769 770 DIGEST-MD5 771 PLAIN 772 SAML20EC 773 774 776 Step 4: Client selects an authentication mechanism and sends the 777 initial client response (it is base64 encoded as specified by the 778 XMPP SASL protocol profile): 780 781 biwsLCw= 782 784 The initial response is "n,,,," which signals that channel binding is 785 not used, there is no authorization identity, and the client does not 786 support key-based confirmation, or want mutual authentication or 787 delegation. 789 Step 5: Server sends a challenge to client in the form of a SOAP 790 envelope containing its SAML : 792 793 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 794 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 795 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 796 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 797 ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy 798 MDAzLTA4IgogICAgICBtZXNzYWdlSUQ9ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRl 799 cnN0YW5kPSIxIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2Fw 800 Lm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIHJlc3BvbnNlQ29uc3VtZXJVUkw9 801 InhtcHBAeG1wcC5leGFtcGxlLmNvbSIKICAgICAgc2VydmljZT0idXJuOm9hc2lz 802 Om5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4KICAgIDxlY3A6 803 UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M 804 OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No 805 ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu 806 ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t 807 Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv 808 c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz 809 aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s 810 ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv 811 YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT 812 OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l 813 eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMTI4LWN0cy1obWFjLXNoYTEt 814 OTY8L3NhbWxlYzpFbmNUeXBlPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMjU2 815 LWN0cy1obWFjLXNoYTEtOTY8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNhbWxlYzpT 816 ZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxzYW1scDpB 817 dXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9uPSIyLjAi 818 IElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAgIFByb3Rv 819 Y29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdz 820 OlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4 821 bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9 822 InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAg 823 aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAg 824 ICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAg 825 ICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZv 826 cm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNv 827 bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250 828 ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6 829 YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z 830 YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl 831 ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6 832 Qm9keT4KPC9TOkVudmVsb3BlPg== 833 835 The Base64 [RFC4648] decoded envelope: 837 841 842 847 851 https://xmpp.example.com 852 853 857 aes128-cts-hmac-sha1-96 858 aes256-cts-hmac-sha1-96 859 860 861 862 866 867 https://xmpp.example.com 868 869 871 872 873 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 874 875 876 877 879 881 Step 5 (alt): Server returns error to client: 883 884 885 886 888 Step 6: Client relays the request to IdP in a SOAP message 889 transmitted over HTTP (over TLS). HTTP portion not shown, use of 890 Basic Authentication is assumed. The body of the SOAP envelope is 891 exactly the same as received in the previous step. 893 897 898 899 900 901 902 904 Step 7: IdP responds to client with a SOAP response containing a SAML 905 containing a short-lived SSO assertion (shown as an 906 encrypted variant in the example). A generated key is included in 907 the assertion and in a header for the client. 909 913 914 917 918 3w1wSBKUosRLsU69xGK7dg== 919 920 921 922 925 https://saml.example.org 926 927 929 930 931 932 933 934 935 937 Step 8: Client sends SOAP envelope containing the SAML as 938 a response to the SASL server's challenge: 940 941 PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT 942 QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h 943 bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj 944 aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K 945 ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6 946 MjAwMy0wOCIKICAgICAgUzphY3Rvcj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 947 cmcvc29hcC9hY3Rvci9uZXh0IgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIiBy 948 ZWZUb01lc3NhZ2VJRD0iNmMzYTRmOGI5YzJkIi8+CiAgICA8c2FtbGVjOlNlc3Np 949 b25LZXkgeG1sbnM6c2FtbGVjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNhbWxl 950 YyIKICAgICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29h 951 cC9lbnZlbG9wZS8iCiAgICAgIFM6bXVzdFVuZGVyc3RhbmQ9IjEiCiAgICAgIFM6 952 YWN0b3I9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvYWN0b3IvbmV4 953 dCI+CiAgICAgIDxzYW1sZWM6RW5jVHlwZT5hZXMxMjgtY3RzLWhtYWMtc2hhMS05 954 Njwvc2FtbGVjOkVuY1R5cGU+CiAgICA8c2FtbGVjOlNlc3Npb25LZXk+CiAgPC9T 955 OkhlYWRlcj4KICA8UzpCb2R5PgogICAgPHNhbWxwOlJlc3BvbnNlIElEPSJkNDNo 956 OTRyMzg5MzA5ciIgVmVyc2lvbj0iMi4wIgogICAgICAgIElzc3VlSW5zdGFudD0i 957 MjAwNy0xMi0xMFQxMTo0MjozNFoiIEluUmVzcG9uc2VUbz0iYzNhNGY4YjljMmQi 958 CiAgICAgICAgRGVzdGluYXRpb249InhtcHBAeG1wcC5leGFtcGxlLmNvbSI+CiAg 959 ICAgIDxzYW1sOklzc3Vlcj5odHRwczovL3NhbWwuZXhhbXBsZS5vcmc8L3NhbWw6 960 SXNzdWVyPgogICAgICA8c2FtbHA6U3RhdHVzPgogICAgICAgIDxzYW1scDpTdGF0 961 dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 962 TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg 963 ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl 964 bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj 965 ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft 966 bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K 967 969 The Base64 [RFC4648] decoded envelope: 971 975 976 979 983 aes128-cts-hmac-sha1-96 984 985 986 987 990 https://saml.example.org 991 992 994 995 996 997 998 999 1000 1002 Step 9: Server informs client of successful authentication: 1004 1006 Step 9 (alt): Server informs client of failed authentication: 1008 1009 1010 1011 1013 Step 10: Client initiates a new stream to server: 1015 1019 Step 11: Server responds by sending a stream header to client along 1020 with any additional features (or an empty features element): 1022 1025 1026 1027 1028 1030 Step 12: Client binds a resource: 1032 1033 1034 someresource 1035 1036 1038 Step 13: Server informs client of successful resource binding: 1040 1041 1042 somenode@example.com/someresource 1043 1044 1046 Please note: line breaks were added to the base64 for clarity. 1048 7. Security Considerations 1050 This section will address only security considerations associated 1051 with the use of SAML with SASL applications. For considerations 1052 relating to SAML in general, the reader is referred to the SAML 1053 specification and to other literature. Similarly, for general SASL 1054 Security Considerations, the reader is referred to that 1055 specification. 1057 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 1058 optional support for channel binding and use of "Holder of Key" 1059 subject confirmation. The former is strongly recommended for use 1060 with this mechanism to detect "Man in the Middle" attacks between the 1061 client and the RP without relying on flawed commercial TLS 1062 infrastructure. The latter may be impractical in many cases, but is 1063 a valuable way of strengthening client authentication, protecting 1064 against phishing, and improving the overall mechanism. 1066 7.1. Risks Left Unaddressed 1068 The adaptation of a web-based profile that is largely designed around 1069 security-oblivious clients and a bearer model for security token 1070 validation results in a number of basic security exposures that 1071 should be weighed against the compatibility and client simplification 1072 benefits of this mechanism. 1074 When channel binding is not used, protection against "Man in the 1075 Middle" attacks is left to lower layer protocols such as TLS, and the 1076 development of user interfaces able to implement that has not been 1077 effectively demonstrated. Failure to detect a MITM can result in 1078 phishing of the user's credentials if the attacker is between the 1079 client and IdP, or the theft and misuse of a short-lived credential 1080 (the SAML assertion) if the attacker is able to impersonate a RP. 1081 SAML allows for source address checking as a minor mitigation to the 1082 latter threat, but this is often impractical. IdPs can mitigate to 1083 some extent the exposure of personal information to RP attackers by 1084 encrypting assertions with authenticated keys. 1086 7.2. User Privacy 1088 The IdP is aware of each RP that a user logs into. There is nothing 1089 in the protocol to hide this information from the IdP. It is not a 1090 requirement to track the activity, but there is nothing technically 1091 that prohibits the collection of this information. Servers should be 1092 aware that SAML IdPs will track - to some extent - user access to 1093 their services. This exposure extends to the use of session keys 1094 generated by the IdP to secure messages between the parties, but note 1095 that when bearer assertions are involved, the IdP can freely 1096 impersonate the user to any relying party in any case. 1098 It is also out of scope of the mechanism to determine under what 1099 conditions an IdP will release particular information to a relying 1100 party, and it is generally unclear in what fashion user consent could 1101 be established in real time for the release of particular 1102 information. The SOAP exchange with the IdP does not preclude such 1103 interaction, but neither does it define that interoperably. 1105 7.3. Collusion between RPs 1107 Depending on the information supplied by the IdP, it may be possible 1108 for RPs to correlate data that they have collected. By using the 1109 same identifier to log into every RP, collusion between RPs is 1110 possible. SAML supports the notion of pairwise, or targeted/ 1111 directed, identity. This allows the IdP to manage opaque, pairwise 1112 identifiers for each user that are specific to each RP. However, 1113 correlation is often possible based on other attributes supplied, and 1114 is generally a topic that is beyond the scope of this mechanism. It 1115 is sufficient to say that this mechanism does not introduce new 1116 correlation opportunities over and above the use of SAML in web-based 1117 use cases. 1119 8. IANA Considerations 1121 8.1. GSS-API and SASL Mechanism Registration 1123 The IANA is requested to assign a new entry for this GSS mechanism in 1124 the sub-registry for SMI Security for Mechanism Codes, whose prefix 1125 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 1126 reference this specification in the registry. 1128 The IANA is requested to register the following SASL profile: 1130 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 1132 Security Considerations: See this document 1134 Published Specification: See this document 1136 For further information: Contact the authors of this document. 1138 Owner/Change controller: the IETF 1140 Note: None 1142 8.2. XML Namespace Name for SAML-EC 1144 A URN sub-namespace for XML constructs introduced by this mechanism 1145 is defined as follows: 1147 URI: urn:ietf:params:xml:ns:samlec 1149 Specification: See Appendix A of this document. 1151 Description: This is the XML namespace name for XML constructs 1152 introduced by the SAML Enhanced Client SASL and GSS-API Mechanisms. 1154 Registrant Contact: the IESG 1156 9. References 1158 9.1. Normative References 1160 [OASIS.saml-bindings-2.0-os] 1161 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1162 Maler, "Bindings for the OASIS Security Assertion Markup 1163 Language (SAML) V2.0", OASIS 1164 Standard saml-bindings-2.0-os, March 2005. 1166 [OASIS.saml-core-2.0-os] 1167 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1168 "Assertions and Protocol for the OASIS Security Assertion 1169 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1170 2.0-os, March 2005. 1172 [OASIS.saml-profiles-2.0-os] 1173 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1174 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1175 Security Assertion Markup Language (SAML) V2.0", OASIS 1176 Standard OASIS.saml-profiles-2.0-os, March 2005. 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, March 1997. 1181 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1182 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1183 Authentication: Basic and Digest Access Authentication", 1184 RFC 2617, June 1999. 1186 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1187 Security Layer (SASL)", RFC 4422, June 2006. 1189 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1190 "Generic Security Service Application Program Interface 1191 (GSS-API) Authentication and Key Exchange for the Secure 1192 Shell (SSH) Protocol", RFC 4462, May 2006. 1194 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1195 Encodings", RFC 4648, October 2006. 1197 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1198 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1200 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1201 Verification of Domain-Based Application Service Identity 1202 within Internet Public Key Infrastructure Using X.509 1203 (PKIX) Certificates in the Context of Transport Layer 1204 Security (TLS)", RFC 6125, March 2011. 1206 [SAMLECP20] 1207 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1208 Version 2.0", OASIS Committee Specification OASIS.sstc- 1209 saml-ecp-v2.0-cs01, August 2013. 1211 [W3C.soap11] 1212 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1213 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1214 "Simple Object Access Protocol (SOAP) 1.1", W3C 1215 Note soap11, May 2000, . 1217 9.2. Normative References for GSS-API Implementers 1219 [I-D.ietf-abfab-gss-eap-naming] 1220 Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1221 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-07 1222 (work in progress), November 2012. 1224 [RFC2743] Linn, J., "Generic Security Service Application Program 1225 Interface Version 2, Update 1", RFC 2743, January 2000. 1227 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1228 Kerberos 5", RFC 3961, February 2005. 1230 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1231 Encryption for Kerberos 5", RFC 3962, February 2005. 1233 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1234 Version 5 Generic Security Service Application Program 1235 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1236 July 2005. 1238 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1239 Extension for the Generic Security Service Application 1240 Program Interface (GSS-API)", RFC 4401, February 2006. 1242 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1243 Kerberos V Generic Security Service Application Program 1244 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1246 [RFC5554] Williams, N., "Clarifications and Extensions to the 1247 Generic Security Service Application Program Interface 1248 (GSS-API) for the Use of Channel Bindings", RFC 5554, 1249 May 2009. 1251 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1252 Service Application Program Interface (GSS-API) Mechanisms 1253 in Simple Authentication and Security Layer (SASL): The 1254 GS2 Mechanism Family", RFC 5801, July 2010. 1256 [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. 1257 Josefsson, "Generic Security Service Application 1258 Programming Interface (GSS-API) Naming Extensions", 1259 RFC 6680, August 2012. 1261 9.3. Informative References 1263 [OASIS.saml-metadata-2.0-os] 1264 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1265 "Metadata for the Security Assertion Markup Language 1266 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1267 March 2005. 1269 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1270 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1271 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1273 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1274 Protocol (XMPP): Core", RFC 3920, October 2004. 1276 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1277 Kerberos and NTLM HTTP Authentication in Microsoft 1278 Windows", RFC 4559, June 2006. 1280 [W3C.REC-xmlschema-1] 1281 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1282 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, 1283 May 2001, . 1285 [WSS-SAML] 1286 Monzillo, R., "Web Services Security SAML Token Profile 1287 Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, 1288 May 2012. 1290 Appendix A. XML Schema 1292 The following schema formally defines the 1293 "urn:ietf:params:xml:ns:samlec" namespace used in this document, in 1294 conformance with [W3C.REC-xmlschema-1] While XML validation is 1295 optional, the schema that follows is the normative definition of the 1296 constructs it defines. Where the schema differs from any prose in 1297 this specification, the schema takes precedence. 1299 1310 1311 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 1326 1327 1328 1329 1330 1331 1332 1333 1334 1336 1337 1338 1339 1340 1341 1343 1345 Appendix B. Acknowledgments 1347 The authors would like to thank Klaas Wierenga, Sam Hartman, Nico 1348 Williams, Jim Basney, and Venkat Yekkirala for their contributions. 1350 Appendix C. Changes 1352 This section to be removed prior to publication. 1354 o 10, update SAML ECP reference to final CS 1356 o 09, align delegation signaling to updated ECP draft 1358 o 08, more corrections, added a delegation signaling header 1360 o 07, corrections, revised section on delegation 1362 o 06, simplified session key schema, moved responsibility for 1363 random-to-key to the endpoints, and defined advertisement of 1364 session key algorithm and enctypes by acceptor 1366 o 05, revised session key material, added requirement for random-to- 1367 key, revised XML schema to capture enctype name, updated GSS 1368 naming reference 1370 o 04, stripped down the session key material to simplify it, and 1371 define an IdP-brokered keying approach, moved session key XML 1372 constructs from OASIS draft into this one 1374 o 03, added TLS key export as a session key option, revised GSS 1375 naming material based on list discussion 1377 o 02, major revision of GSS-API material and updated references 1379 o 01, SSH language added, noted non-assumption of HTTP error 1380 handling, added guidance on life of security context. 1382 o 00, Initial Revision, first WG-adopted draft. Removed support for 1383 unsolicited SAML responses. 1385 Authors' Addresses 1387 Scott Cantor 1388 Shibboleth Consortium 1389 2740 Airport Drive 1390 Columbus, Ohio 43219 1391 United States 1393 Phone: +1 614 247 6147 1394 Email: cantor.2@osu.edu 1396 Simon Josefsson 1397 SJD AB 1398 Hagagatan 24 1399 Stockholm 113 47 1400 SE 1402 Email: simon@josefsson.org 1403 URI: http://josefsson.org/