idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2012) is 4207 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 1116, but not defined == Missing Reference: 'RFC5801' is mentioned on line 1143, but not defined == Missing Reference: 'RFC5554' is mentioned on line 1138, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1119, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1122, but not defined == Missing Reference: 'XMLENC11' is mentioned on line 1148, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1125, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1130, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1134, but not defined ** Obsolete undefined reference: RFC 4402 (Obsoleted by RFC 7802) == Missing Reference: 'I-D.ietf-kitten-gssapi-naming-exts' is mentioned on line 1110, but not defined == Missing Reference: 'I-D.ietf-abfab-gss-eap-naming' is mentioned on line 1105, 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 (~~), 13 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: April 20, 2013 SJD AB 6 October 17, 2012 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-04.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 April 20, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6 62 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 63 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 66 4.4. User Authentication with Identity Provider . . . . . . . . 10 67 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 68 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 70 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12 71 5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 72 5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13 73 5.2.1. Generated by Identity Provider . . . . . . . . . . . . 13 74 5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14 75 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 76 5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 77 5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 78 5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16 79 5.5.2. Service Naming Considerations . . . . . . . . . . . . 16 80 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26 83 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26 84 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28 87 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 90 9.2. Normative References for GSS-API Implementers . . . . . . 30 91 9.3. Informative References . . . . . . . . . . . . . . . . . . 31 92 Appendix A. Appendix A. XML Schema . . . . . . . . . . . . . . . 32 93 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 94 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 35 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 97 1. Introduction 99 Security Assertion Markup Language (SAML) 2.0 100 [OASIS.saml-core-2.0-os] is a modular specification that provides 101 various means for a user to be identified to a relying party (RP) 102 through the exchange of (typically signed) assertions issued by an 103 identity provider (IdP). It includes a number of protocols, protocol 104 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 105 [OASIS.saml-profiles-2.0-os] designed for different use cases. 106 Additional profiles and extensions are also routinely developed and 107 published. 109 Simple Authentication and Security Layer (SASL) [RFC4422] is a 110 generalized mechanism for identifying and authenticating a user and 111 for optionally negotiating a security layer for subsequent protocol 112 interactions. SASL is used by application protocols like IMAP, POP 113 and XMPP [RFC3920]. The effect is to make authentication modular, so 114 that newer authentication mechanisms can be added as needed. 116 The Generic Security Service Application Program Interface (GSS-API) 117 [RFC2743] provides a framework for applications to support multiple 118 authentication mechanisms through a unified programming interface. 119 This document defines a pure SASL mechanism for SAML, but it conforms 120 to the bridge between SASL and the GSS-API called GS2 [RFC5801]. 121 This means that this document defines both a SASL mechanism and a 122 GSS-API mechanism. The GSS-API interface is optional for SASL 123 implementers, and the GSS-API considerations can be avoided in 124 environments that uses SASL directly without GSS-API. 126 The mechanisms specified in this document allow a SASL- or GSS-API- 127 enabled server to act as a SAML relying party, or service provider 128 (SP), by advertising this mechanism as an option for SASL or GSS-API 129 clients that support the use of SAML to communicate identity and 130 attribute information. Clients supporting this mechanism are termed 131 "enhanced clients" in SAML terminology because they understand the 132 federated authentication model and have specific knowledge of the 133 IdP(s) associated with the user. This knowledge, and the ability to 134 act on it, addresses a significant problem with browser-based SAML 135 profiles known as the "discovery", or "where are you from?" (WAYF) 136 problem. Obviating the need for the RP to interact with the client 137 to determine the right IdP (and its network location) is both a user 138 interface and security improvement. 140 The SAML mechanism described in this document is an adaptation of an 141 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 142 (V2.0) [SAMLECP20], and therefore does not establish a separate 143 authentication, integrity and confidentiality mechanism. It is 144 anticipated that existing security layers, such as Transport Layer 145 Security (TLS) or Secure Shell (SSH), will continued to be used. 147 Figure 1 describes the interworking between SAML and SASL: this 148 document requires enhancements to the RP and to the client (as the 149 two SASL communication endpoints) but no changes to the SAML IdP are 150 assumed apart from its support for the applicable SAML profile. To 151 accomplish this, a SAML protocol exchange between the RP and the IdP, 152 brokered by the client, is tunneled within SASL. There is no assumed 153 communication between the RP and the IdP, but such communication may 154 occur in conjunction with additional SAML-related profiles not in 155 scope for this document. 157 +-----------+ 158 | SAML | 159 | Relying | 160 | Party | 161 | | 162 +-----------+ 163 ^ 164 +--|--+ 165 | S| | 166 S | A| | 167 A | M| | 168 S | L| | 169 L | | | 170 | | | 171 +--|--+ 172 +------------+ v 173 | | +----------+ 174 | SAML | SAML SOAP | | 175 | Identity |<--------------->| Client | 176 | Provider | Binding | | 177 +------------+ +----------+ 179 Figure 1: Interworking Architecture 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 The reader is also assumed to be familiar with the terms used in the 188 SAML 2.0 specification, and an understanding of the Enhanced Client 189 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 190 this mechanism explicitly reuses and references it. 192 This document can be implemented without knowledge of GSS-API since 193 the normative aspects of the GS2 protocol syntax have been duplicated 194 in this document. The document may also be implemented to provide a 195 GSS-API mechanism, and then knowledge of GSS-API is essential. To 196 faciliate these two variants, the references has been split into two 197 parts, one part that provides normative references for all readers, 198 and one part that adds additional normative references required for 199 implementers that wish to implement the GSS-API portion. 201 3. Applicability for Non-HTTP Use Cases 203 While SAML is designed to support a variety of application scenarios, 204 the profiles for authentication defined in the original standard are 205 designed around HTTP [RFC2616] applications. They are not, however, 206 limited to browsers, because it was recognized that browsers suffer 207 from a variety of functional and security deficiencies that would be 208 useful to avoid where possible. Specifically, the notion of an 209 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 210 thus the term "ECP") was specified for a software component that acts 211 somewhat like a browser from an application perspective, but includes 212 limited, but sufficient, awareness of SAML to play a more conscious 213 role in the authentication exchange between the RP and the IdP. What 214 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 215 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 217 1. The Enhanced Client requests a resource of a Relying Party (RP) 218 (via an HTTP request). In doing so, it advertises its "enhanced" 219 capability using HTTP headers. 221 2. The RP, desiring SAML authentication and noting the client's 222 capabilities, responds not with an HTTP redirect or form, but 223 with a SOAP [W3C.soap11] envelope containing a SAML 224 along with some supporting headers. This request 225 identifies the RP (and may be signed), and may provide hints to 226 the client as to what IdPs the RP finds acceptable, but the 227 choice of IdP is generally left to the client. 229 3. The client is then responsible for delivering the body of the 230 SOAP message to the IdP it is instructed to use (often via 231 configuration ahead of time). The user authenticates to the IdP 232 ahead of, during, or after the delivery of this message, and 233 perhaps explicitly authorizes the response to the RP. 235 4. Whether authentication succeeds or fails, the IdP responds with 236 its own SOAP envelope, generally containing a SAML 237 message for delivery to the RP. In a successful case, the 238 message will include a SAML containing 239 authentication, and possibly attribute, information about the 240 user. Either the response or assertion alone is signed, and the 241 assertion may be encrypted to a key negotiated with or known to 242 belong to the RP. 244 5. The client then delivers the SOAP envelope containing the 245 to the RP at a location the IdP directs (which acts as 246 an additional, though limited, defense against MITM attacks). 247 This completes the SAML exchange. 249 6. The RP now has sufficient identity information to approve the 250 original HTTP request or not, and acts accordingly. Everything 251 between the original request and this response can be thought of 252 as an "interruption" of the original HTTP exchange. 254 When considering this flow in the context of an arbitrary application 255 protocol and SASL, the RP and the client both must change their code 256 to implement this SASL mechanism, but the IdP can remain untouched. 257 The existing RP/client exchange that is tunneled through HTTP maps 258 well to the tunneling of that same exchange in SASL. In the parlance 259 of SASL [RFC4422], this mechanism is "client-first" for consistency 260 with GS2. The steps are shown below: 262 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 263 mechanisms. 265 2. The client initiates a SASL authentication with SAML20EC or 266 SAML20EC-PLUS. 268 3. The server sends the client a challenge consisting of a SOAP 269 envelope containing its SAML . 271 4. The SASL client unpacks the SOAP message and communicates with 272 its chosen IdP to relay the SAML to it. This 273 communication, and the authentication with the IdP, proceeds 274 separately from the SASL process. 276 5. Upon completion of the exchange with the IdP, the client responds 277 to the SASL server with a SOAP envelope containing the SAML 278 it obtained, or a SOAP fault, as warranted. 280 6. The SASL Server indicates success or failure. 282 Note: The details of the SAML processing, which are consistent with 283 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 284 such that the client MUST interact with the IdP in order to complete 285 any SASL exchange with the RP. The assertions issued by the IdP for 286 the purposes of the profile, and by extension this SASL mechanism, 287 are short lived, and therefore cannot be cached by the client for 288 later use. 290 Encompassed in step four is the client-driven selection of the IdP, 291 authentication to it, and the acquisition of a response to provide to 292 the SASL server. These processes are all external to SASL. 294 With all of this in mind, the typical flow appears as follows: 296 SASL Serv. Client IdP 297 |>-----(1)----->| | Advertisement 298 | | | 299 |<-----(2)-----<| | Initiation 300 | | | 301 |>-----(3)----->| | SASL Server Response 302 | | | 303 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 304 | | | 305 |<-----(5)-----<| | SASL Client Response 306 | | | 307 |>-----(6)----->| | Server sends Outcome 308 | | | 310 ----- = SASL 311 - - - = SOAP over HTTPS (external to SASL) 313 Figure 2: Authentication flow 315 4. SAML SASL Mechanism Specification 317 Based on the previous figures, the following operations are defined 318 by the SAML SASL mechanism: 320 4.1. Advertisement 322 To advertise that a server supports this mechanism, during 323 application session initiation, it displays the name "SAML20EC" 324 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms 325 (depending on its support for channel binding). 327 4.2. Initiation 329 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 330 supported by the application protocol, the client MAY include an 331 initial response, otherwise it waits until the server has issued an 332 empty challenge (because the mechanism is client-first). 334 The format of the initial client response is as follows: 336 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 338 mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 339 "WantAuthnRequestsSigned" 341 initial-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mutual] 343 The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate 344 whether the client supports channel binding. This takes the place of 345 the PAOS HTTP header extension used in [SAMLECP20] to indicate 346 channel binding support. 348 The optional "gs2-authzid" field holds the authorization identity, as 349 requested by the client. 351 The optional "hok" field is a constant that signals the client's 352 support for stronger security by means of a locally held key. This 353 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 354 to indicate "holder of key" support. 356 The optional "mutual" field is a constant that signals the client's 357 desire for mutual authentication. If set, the SASL server MUST 358 digitally sign its SAML message. The URN constant 359 above is a single string; the linefeed is shown for RFC formatting 360 reasons. 362 4.3. Server Response 364 The SASL server responds with a SOAP envelope constructed in 365 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 366 to the SOAP header requirements of the SAML PAOS Binding 367 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 368 profile. Various SOAP headers are also consumed by the client in 369 exactly the same manner prescribed by that section. 371 4.4. User Authentication with Identity Provider 373 Upon receipt of the Server Response (Section 4.3), the steps 374 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 375 performed between the client and the chosen IdP. The means by which 376 the client determines the IdP to use, and where it is located, are 377 out of scope of this mechanism. 379 The exact means of authentication to the IdP are also out of scope, 380 but clients supporting this mechanism MUST support HTTP Basic 381 Authentication as defined in [RFC2617] and TLS client authentication 382 as defined in [RFC5246]. 384 4.5. Client Response 386 Assuming a response is obtained from the IdP, the client responds to 387 the SASL server with a SOAP envelope constructed in accordance with 388 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 389 header requirements of the SAML PAOS Binding 390 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 391 profile. If the client is unable to obtain a response from the IdP, 392 it responds to the SASL server with a SOAP envelope containing a SOAP 393 fault. 395 4.6. Outcome 397 The SAML protocol exchange having completed, the SASL server will 398 transmit the outcome to the client depending on local validation of 399 the client responses. This outcome is transmitted in accordance with 400 the application protocol in use. 402 4.7. Additional Notes 404 Because this mechanism is an adaptation of an HTTP-based profile, 405 there are a few requirements outlined in [SAMLECP20] that make 406 reference to a response URL that is normally used to regulate where 407 the client returns information to the RP. There are also security- 408 related checks built into the profile that involve this location. 410 For compatibility with existing IdP and profile behavior, and to 411 provide for mutual authentication, the SASL server MUST populate the 412 responseConsumerURL and AssertionConsumerServiceURL attributes with 413 its service name. The parties then perform the steps described in 414 [SAMLECP20] as usual. 416 Similarly, the use of HTTP status signaling between the RP and client 417 mandated by [SAMLECP20] may not be applicable. 419 5. SAML EC GSS-API Mechanism Specification 421 This section and its sub-sections and all normative references of it 422 not referenced elsewhere in this document are INFORMATIONAL for SASL 423 implementors, but they are NORMATIVE for GSS-API implementors. 425 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 426 The messages are the same, but a) the GS2 header on the client's 427 first message is excluded when SAML EC is used as a GSS-API 428 mechanism, and b) the [RFC2743] section 3.1 initial context token 429 header is prefixed to the client's first authentication message 430 (context token). 432 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 433 IANA considerations). The DER encoding of the OID is TBD. 435 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 436 resulting in the "mutual-auth" option set in the initial client 437 response. The security context mutual_state flag is set to TRUE only 438 if the server digitally signs its SAML message, and 439 the identity provider signals this to the client in an SOAP header block. 442 If the mutual_state flag is not requested, or is not set, then the 443 security layer managed by the application outside of the GSS-API 444 mechanism is responsible for authenticating the acceptor. In this 445 case, applications MUST match the server identity from the existing 446 security layer with the target name. For TLS, this matching MUST be 447 performed as discussed in [RFC6125]. For SSH, this matching MUST be 448 performed as discussed in [RFC4462]. 450 The lifetime of a security context established with this mechanism 451 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 452 any, in the of the SAML assertion received by the 453 RP. 455 SAML EC supports credential delegation through the issuance of SAML 456 assertions that the issuing identity provider will accept as proof of 457 authentication by a service on behalf of a user. Such assertions 458 MUST contain an condition element identifying 459 the identity provider, and a element that the 460 acceptor can satisy. In such a case, the security context will have 461 its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. 463 5.1. GSS-API Channel Binding 465 GSS-API channel binding [RFC5554] is a protected facility for 466 exchanging a cryptographic name for an enclosing channel between the 467 initiator and acceptor. The initiator sends channel binding data and 468 the acceptor confirms that channel binding data has been checked. 470 The acceptor SHOULD accept any channel binding provided by the 471 initiator if null channel bindings are passed into 472 gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] 473 depend on this behavior of some Kerberos implementations. 475 The exchange and verification of channel binding information is 476 described by [SAMLECP20]. 478 5.2. Session Key Derivation 480 Some GSS-API features (discussed in the following sections) require a 481 session key be established as a result of security context 482 establishment. In the common case of a "bearer" assertion in SAML, 483 there are a pair of approaches defined: exporting key material from 484 TLS and communicating a key to both parties via the identity 485 provider. Both are discussed below. In other cases such as 486 assertions based on "holder of key" confirmation bound to a client- 487 controlled key, there may be additional methods available. 489 Information defining or describing the session key, or a process for 490 deriving one, is communicated using a element, 491 defined in the schema in Appendix A. This element can be used as a 492 SOAP header block or as an extension within a SAML assertion, 493 depending on the context of communication. The content of the 494 element further depends on the specific use in the mechanism and is 495 discussed below. 497 5.2.1. Generated by Identity Provider 499 The identity provider, if issuing a bearer assertion for use with 500 this mechanism, SHOULD provide a generated key for use by the 501 initiator and acceptor. This key is used as the protocol key for a 502 specific encryption type defined in accordance with [RFC3961]. The 503 key is base64-encoded and placed inside a 504 element. The element's Algorithm XML attribute is set to the 505 encryption type name from the registry established by [RFC3961]. 507 The element is placed within a element, and this element is placed within the element of the assertion issued. A copy of the element is 510 also added as a SOAP header block in the response from the identity 511 provider to the client. 513 The identity provider is left to determine which encryption type the 514 parties should use. It is unspecified how the initiator's 515 capabilities are determined in this respect, but the acceptor MAY 516 indicate the algorithms it supports in its SAML metadata by means of 517 one or more elements in an 518 element, and an identity provider can leverage this information. 519 Multiple such extension elements may appear, in order of preference 520 by the acceptor. 522 All parties MUST support the "aes128-cts-hmac-sha1-96" encryption 523 type, defined by [RFC3962]. 525 5.2.2. Derived Session Keys 527 In the event that a client is proving possession of a secret or 528 private key, a formal key agreement algorithm may be supported. For 529 example, if the server has an elliptic curve public key, the ECDH-ES 530 key agreement algorithm, as defined in [XMLENC11] may be used. 532 In such a case, the initiator communicates to the acceptor what 533 algorithm to use and any inputs to the process using a 534 SOAP header block containing a element, added to the 535 client response to the acceptor. The element will 536 typically contain an element conforming to 537 [XMLENC11]. The element may also contain other 538 extensible content related to key establishment mechanisms defined 539 elsewhere. 541 5.3. Per-Message Tokens 543 The per-message tokens SHALL be the same as those for the Kerberos V5 544 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). 546 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 547 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 548 (GSS_C_CONF_FLAG) security context flags are always set to TRUE. 550 The "protocol key" SHALL be a session key established in a manner 551 described in the previous section. "Specific keys" are then derived 552 as usual as described in Section 2 of [RFC4121], [RFC3961], and 553 [RFC3962]. 555 The terms "protocol key" and "specific key" are Kerberos V5 terms 556 [RFC3961]. 558 SAML20EC is PROT_READY as soon as the SAML response message has been 559 seen. 561 5.4. Pseudo-Random Function (PRF) 563 The GSS-API has been extended with a Pseudo-Random Function (PRF) 564 interface in [RFC4401]. The purpose is to enable applications to 565 derive a cryptographic key from an established GSS-API security 566 context. This section defines a GSS_Pseudo_random that is applicable 567 for the SAML20EC GSS-API mechanism. 569 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 570 Kerberos V5 GSS-API mechanism [RFC4402]. There is no acceptor- 571 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 572 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 573 for the GSS_Pseudo_random() SHALL be the same as the key defined in 574 the previous section. 576 5.5. GSS-API Principal Name Types for SAML EC 578 Services that act as SAML relying parties are typically identified by 579 means of a URI called an "entityID". Clients that are named in the 580 element of a SAML assertion are typically identified by 581 means of a element, which is an extensible XML structure 582 containing, at minimum, an element value that names the subject and a 583 Format attribute. 585 In practice, a GSS-API client and server are unlikely to know in 586 advance the name of the initiator as it will be expressed by the SAML 587 identity provider upon completion of authentication. It is also 588 generally incorrect to assume that a particular acceptor name will 589 directly map into a particular RP entityID, because there is often a 590 layer of naming indirection between particular services on hosts and 591 the identity of a relying party in SAML terms. 593 To avoid complexity, and avoid unnecessary use of XML within the 594 naming layer, the SAML EC mechanism relies on the common/expected 595 name types used for acceptors and initiators, 596 GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism 597 provides for validation of the host-based service name in conjunction 598 with the SAML exchange. It does not attempt to solve the problem of 599 mapping between an initiator "username", the user's identity while 600 authenticating to the identity provider, and the information supplied 601 by the identity provider to the acceptor. These relationships must 602 be managed through local policy at the initiator and acceptor. 604 SAML-based information associated with the initiator SHOULD be 605 expressed to the acceptor using GSS-API naming extensions 606 [I-D.ietf-kitten-gssapi-naming-exts], in accordance with 607 [I-D.ietf-abfab-gss-eap-naming]. 609 5.5.1. User Naming Considerations 611 The GSS_C_NT_USER_NAME form represents the name of an individual 612 user. Clients often rely on this value to determine the appropriate 613 credentials to use in authenticating to the identity provider, and 614 supply it to the server for use by the acceptor. 616 Upon successful completion of this mechanism, the server MUST 617 construct the authenticated initiator name based on the 618 element in the assertion it successfully validated. The name is 619 constructed as a UTF-8 string in the following form: 621 name = element-value "!" Format "!" NameQualifier 622 "!" SPNameQualifier "!" SPProvidedID 624 The "element-value" token refers to the content of the 625 element. The other tokens refer to the identically named XML 626 attributes defined for use with the element. If an attribute is not 627 present, which is common, it is omitted (i.e., replaced with the 628 empty string). The Format value is never omitted; if not present, 629 the SAML-equivalent value of 630 "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used. 632 Not all SAML assertions contain a element. In the 633 event that no such element is present, including the exceptional 634 cases of a element or a element that 635 cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used 636 for the initiator name. 638 As noted in the previous section, it is expected that most 639 applications able to rely on SAML authentication would make use of 640 naming extensions to obtain additional information about the user 641 based on the assertion. This is particularly true in the anonymous 642 case, or in cases in which the SAML name is pseudonymous or transient 643 in nature. The ability to express the SAML name in 644 GSS_C_NT_USER_NAME form is intended for compatibility with 645 applications that cannot make use of additional information. 647 5.5.2. Service Naming Considerations 649 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 650 on a host; it is textually represented as "service@host". This name 651 form is required by most SASL profiles and is used by many existing 652 applications that use the Kerberos GSS-API mechanism. Such a name is 653 used directly by this mechanism as the effective 654 AssertionConsumerService of the server. 656 This value is used in the construction of the responseConsumerURL and 657 AssertionConsumerServiceURL attributes, and for eventual comparison 658 and validation by the client before completing the exchange. The 659 value MUST be securely associated with the SAML entityID claimed by 660 the server by the identity provider, such as through the use of SAML 661 metadata [OASIS.saml-metadata-2.0-os]. 663 6. Example 665 Suppose the user has an identity at the SAML IdP saml.example.org and 666 a Jabber Identifier (jid) "somenode@example.com", and wishes to 667 authenticate his XMPP connection to xmpp.example.com (and example.com 668 and example.org have established a SAML-capable trust relationship). 669 The authentication on the wire would then look something like the 670 following: 672 Step 1: Client initiates stream to server: 674 678 Step 2: Server responds with a stream tag sent to client: 680 684 Step 3: Server informs client of available authentication mechanisms: 686 687 688 DIGEST-MD5 689 PLAIN 690 SAML20EC 691 692 694 Step 4: Client selects an authentication mechanism and sends the 695 initial client response (it is base64 encoded as specified by the 696 XMPP SASL protocol profile): 698 699 biwsLA== 700 702 The initial response is "n,," which signals that channel binding is 703 not used, there is no authorization identity, and the client does not 704 support key-based confirmation or want mutual authentication. 706 Step 5: Server sends a challenge to client in the form of a SOAP 707 envelope containing its SAML : 709 710 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 711 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 712 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 713 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 714 bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 715 ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 716 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u 717 c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj 718 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg 719 ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB 720 TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h 721 cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k 722 PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft 723 bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 724 L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB 725 dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 726 ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n 727 PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz 728 c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N 729 CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 730 TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg 731 ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl 732 YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu 733 MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB 734 dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u 735 dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj 736 bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu 737 Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ 738 IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w 739 ZT4NCg== 740 742 The Base64 [RFC4648] decoded envelope: 744 748 749 754 758 https://xmpp.example.com 759 760 761 762 766 767 https://xmpp.example.com 768 769 771 772 773 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 774 775 776 777 778 780 Step 5 (alt): Server returns error to client: 782 783 784 785 787 Step 6: Client relays the request to IdP in a SOAP message 788 transmitted over HTTP (over TLS). HTTP portion not shown, use of 789 Basic Authentication is assumed. The body of the SOAP envelope is 790 exactly the same as received in the previous step. 792 796 797 798 799 800 801 803 Step 7: IdP responds to client with a SOAP response containing a SAML 804 containing a short-lived SSO assertion (shown as an 805 encrypted variant in the example). A session key is included in the 806 assertion and in a header for the client. 808 812 813 816 817 818 3w1wSBKUosRLsU69xGK7dg== 819 820 821 822 823 826 https://saml.example.org 827 828 830 831 832 833 834 835 836 838 Step 8: Client sends SOAP envelope containing the SAML as 839 a response to the SASL server's challenge: 841 842 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 843 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 844 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 845 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug 846 eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i 847 aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt 848 dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 849 L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 850 cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy 851 LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz 852 dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 853 ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s 854 cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 855 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg 856 ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg 857 ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk 858 QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu 859 dmVsb3BlPg0K 860 862 The Base64 [RFC4648] decoded envelope: 864 868 869 872 873 874 877 https://saml.example.org 878 879 881 882 883 884 885 886 888 890 Step 9: Server informs client of successful authentication: 892 894 Step 9 (alt): Server informs client of failed authentication: 896 897 898 899 901 Step 10: Client initiates a new stream to server: 903 907 Step 11: Server responds by sending a stream header to client along 908 with any additional features (or an empty features element): 910 913 914 915 916 918 Step 12: Client binds a resource: 920 921 922 someresource 923 924 926 Step 13: Server informs client of successful resource binding: 928 929 930 somenode@example.com/someresource 931 932 934 Please note: line breaks were added to the base64 for clarity. 936 7. Security Considerations 938 This section will address only security considerations associated 939 with the use of SAML with SASL applications. For considerations 940 relating to SAML in general, the reader is referred to the SAML 941 specification and to other literature. Similarly, for general SASL 942 Security Considerations, the reader is referred to that 943 specification. 945 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 946 optional support for channel binding and use of "Holder of Key" 947 subject confirmation. The former is strongly recommended for use 948 with this mechanism to detect "Man in the Middle" attacks between the 949 client and the RP without relying on flawed commercial TLS 950 infrastructure. The latter may be impractical in many cases, but is 951 a valuable way of strengthening client authentication, protecting 952 against phishing, and improving the overall mechanism. 954 7.1. Risks Left Unaddressed 956 The adaptation of a web-based profile that is largely designed around 957 security-oblivious clients and a bearer model for security token 958 validation results in a number of basic security exposures that 959 should be weighed against the compatibility and client simplification 960 benefits of this mechanism. 962 When channel binding is not used, protection against "Man in the 963 Middle" attacks is left to lower layer protocols such as TLS, and the 964 development of user interfaces able to implement that has not been 965 effectively demonstrated. Failure to detect a MITM can result in 966 phishing of the user's credentials if the attacker is between the 967 client and IdP, or the theft and misuse of a short-lived credential 968 (the SAML assertion) if the attacker is able to impersonate a RP. 969 SAML allows for source address checking as a minor mitigation to the 970 latter threat, but this is often impractical. IdPs can mitigate to 971 some extent the exposure of personal information to RP attackers by 972 encrypting assertions with authenticated keys. 974 7.2. User Privacy 976 The IdP is aware of each RP that a user logs into. There is nothing 977 in the protocol to hide this information from the IdP. It is not a 978 requirement to track the activity, but there is nothing technically 979 that prohibits the collection of this information. Servers should be 980 aware that SAML IdPs will track - to some extent - user access to 981 their services. This exposure extends to the use of session keys 982 generated by the IdP to secure messages between the parties. 984 It is also out of scope of the mechanism to determine under what 985 conditions an IdP will release particular information to a relying 986 party, and it is generally unclear in what fashion user consent could 987 be established in real time for the release of particular 988 information. The SOAP exchange with the IdP does not preclude such 989 interaction, but neither does it define that interoperably. 991 7.3. Collusion between RPs 993 Depending on the information supplied by the IdP, it may be possible 994 for RPs to correlate data that they have collected. By using the 995 same identifier to log into every RP, collusion between RPs is 996 possible. SAML supports the notion of pairwise, or targeted/ 997 directed, identity. This allows the IdP to manage opaque, pairwise 998 identifiers for each user that are specific to each RP. However, 999 correlation is often possible based on other attributes supplied, and 1000 is generally a topic that is beyond the scope of this mechanism. It 1001 is sufficient to say that this mechanism does not introduce new 1002 correlation opportunities over and above the use of SAML in web-based 1003 use cases. 1005 8. IANA Considerations 1007 8.1. GSS-API and SASL Mechanism Registration 1009 The IANA is requested to assign a new entry for this GSS mechanism in 1010 the sub-registry for SMI Security for Mechanism Codes, whose prefix 1011 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 1012 reference this specification in the registry. 1014 The IANA is requested to register the following SASL profile: 1016 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 1018 Security Considerations: See this document 1020 Published Specification: See this document 1022 For further information: Contact the authors of this document. 1024 Owner/Change controller: the IETF 1026 Note: None 1028 8.2. XML Namespace Name for SAML-EC 1030 A URN sub-namespace for XML constructs introduced by this mechanism 1031 is defined as follows: 1033 URI: urn:ietf:params:xml:ns:samlec 1035 Specification: See Appendix A of this document. 1037 Description: This is the XML namespace name for XML constructs 1038 introduced by the SAML Enhanced Client SASL and GSS-API Mechanisms. 1040 Registrant Contact: the IESG 1042 9. References 1044 9.1. Normative References 1046 [OASIS.saml-bindings-2.0-os] 1047 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1048 Maler, "Bindings for the OASIS Security Assertion Markup 1049 Language (SAML) V2.0", OASIS 1050 Standard saml-bindings-2.0-os, March 2005. 1052 [OASIS.saml-core-2.0-os] 1053 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1054 "Assertions and Protocol for the OASIS Security Assertion 1055 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1056 2.0-os, March 2005. 1058 [OASIS.saml-profiles-2.0-os] 1059 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1060 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1061 Security Assertion Markup Language (SAML) V2.0", OASIS 1062 Standard OASIS.saml-profiles-2.0-os, March 2005. 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, March 1997. 1067 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1068 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1069 Authentication: Basic and Digest Access Authentication", 1070 RFC 2617, June 1999. 1072 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1073 Security Layer (SASL)", RFC 4422, June 2006. 1075 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1076 "Generic Security Service Application Program Interface 1077 (GSS-API) Authentication and Key Exchange for the Secure 1078 Shell (SSH) Protocol", RFC 4462, May 2006. 1080 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1081 Encodings", RFC 4648, October 2006. 1083 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1084 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1086 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1087 Verification of Domain-Based Application Service Identity 1088 within Internet Public Key Infrastructure Using X.509 1089 (PKIX) Certificates in the Context of Transport Layer 1090 Security (TLS)", RFC 6125, March 2011. 1092 [SAMLECP20] 1093 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1094 Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp- 1095 v2.0-wd06, October 2012. 1097 [W3C.soap11] 1098 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1099 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1100 "Simple Object Access Protocol (SOAP) 1.1", W3C 1101 Note soap11, May 2000, . 1103 9.2. Normative References for GSS-API Implementers 1105 [I-D.ietf-abfab-gss-eap-naming] 1106 Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1107 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-06 1108 (work in progress), October 2012. 1110 [I-D.ietf-kitten-gssapi-naming-exts] 1111 Williams, N., Johansson, L., Hartman, S., and S. 1112 Josefsson, "GSS-API Naming Extensions", 1113 draft-ietf-kitten-gssapi-naming-exts-15 (work in 1114 progress), May 2012. 1116 [RFC2743] Linn, J., "Generic Security Service Application Program 1117 Interface Version 2, Update 1", RFC 2743, January 2000. 1119 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1120 Kerberos 5", RFC 3961, February 2005. 1122 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1123 Encryption for Kerberos 5", RFC 3962, February 2005. 1125 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1126 Version 5 Generic Security Service Application Program 1127 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1128 July 2005. 1130 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1131 Extension for the Generic Security Service Application 1132 Program Interface (GSS-API)", RFC 4401, February 2006. 1134 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1135 Kerberos V Generic Security Service Application Program 1136 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1138 [RFC5554] Williams, N., "Clarifications and Extensions to the 1139 Generic Security Service Application Program Interface 1140 (GSS-API) for the Use of Channel Bindings", RFC 5554, 1141 May 2009. 1143 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1144 Service Application Program Interface (GSS-API) Mechanisms 1145 in Simple Authentication and Security Layer (SASL): The 1146 GS2 Mechanism Family", RFC 5801, July 2010. 1148 [XMLENC11] 1149 Hirsch, F. and T. Roessler, "XML Encryption Syntax and 1150 Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- 1151 core-11-ed, September 2012. 1153 9.3. Informative References 1155 [OASIS.saml-metadata-2.0-os] 1156 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1157 "Metadata for the Security Assertion Markup Language 1158 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1159 March 2005. 1161 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1162 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1163 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1165 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1166 Protocol (XMPP): Core", RFC 3920, October 2004. 1168 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1169 Kerberos and NTLM HTTP Authentication in Microsoft 1170 Windows", RFC 4559, June 2006. 1172 [W3C.REC-xmlschema-1] 1173 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1174 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, 1175 May 2001, . 1177 Appendix A. Appendix A. XML Schema 1179 The following schema formally defines the 1180 "urn:ietf:params:xml:ns:samlec" namespace used in this document, in 1181 conformance with [W3C.REC-xmlschema-1] While XML validation is 1182 optional, the schema that follows is the normative definition of the 1183 constructs it defines. Where the schema differs from any prose in 1184 this specification, the schema takes precedence. 1186 1197 1198 1200 1201 1202 1203 1204 1205 1206 1207 1208 1210 1211 1212 1213 1214 1215 1216 1217 1219 1220 1221 1222 1224 1225 1226 1227 1229 Appendix B. Acknowledgments 1231 The authors would like to thank Klaas Wierenga, Sam Hartman, Nico 1232 Williams, and Jim Basney for their contributions. 1234 Appendix C. Changes 1236 This section to be removed prior to publication. 1238 o 04, stripped down the session key material to simplify it, and 1239 define an IdP-brokered keying approach, moved session key XML 1240 constructs from OASIS draft into this one 1242 o 03, added TLS key export as a session key option, revised GSS 1243 naming material based on list discussion 1245 o 02, major revision of GSS-API material and updated references 1247 o 01, SSH language added, noted non-assumption of HTTP error 1248 handling, added guidance on life of security context. 1250 o 00, Initial Revision, first WG-adopted draft. Removed support for 1251 unsolicited SAML responses. 1253 Authors' Addresses 1255 Scott Cantor 1256 Shibboleth Consortium 1257 2740 Airport Drive 1258 Columbus, Ohio 43219 1259 United States 1261 Phone: +1 614 247 6147 1262 Email: cantor.2@osu.edu 1264 Simon Josefsson 1265 SJD AB 1266 Hagagatan 24 1267 Stockholm 113 47 1268 SE 1270 Email: simon@josefsson.org 1271 URI: http://josefsson.org/