idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-03.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 17, 2012) is 4238 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 1121, but not defined == Missing Reference: 'RFC5801' is mentioned on line 1146, but not defined == Missing Reference: 'XMLENC11' is mentioned on line 1151, but not defined == Missing Reference: 'RFC5705' is mentioned on line 1143, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1130, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1127, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1124, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1135, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1139, 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 1115, but not defined == Missing Reference: 'I-D.ietf-abfab-gss-eap-naming' is mentioned on line 1110, 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: March 21, 2013 SJD AB 6 September 17, 2012 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-03.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 21, 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. Session Key Derivation . . . . . . . . . . . . . . . . . . 12 72 5.1.1. TLS-Exported Session Keys . . . . . . . . . . . . . . 13 73 5.1.2. Bearer Assertion Session Keys . . . . . . . . . . . . 14 74 5.1.3. Holder of Key Session Keys . . . . . . . . . . . . . . 14 75 5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15 76 5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 77 5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 16 78 5.4.1. User Naming Considerations . . . . . . . . . . . . . . 16 79 5.4.2. Service Naming Considerations . . . . . . . . . . . . 17 80 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 25 83 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 25 84 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 26 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 88 9.2. Normative References for GSS-API Implementers . . . . . . 29 89 9.3. Informative References . . . . . . . . . . . . . . . . . . 30 90 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 91 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 32 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 94 1. Introduction 96 Security Assertion Markup Language (SAML) 2.0 97 [OASIS.saml-core-2.0-os] is a modular specification that provides 98 various means for a user to be identified to a relying party (RP) 99 through the exchange of (typically signed) assertions issued by an 100 identity provider (IdP). It includes a number of protocols, protocol 101 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 102 [OASIS.saml-profiles-2.0-os] designed for different use cases. 103 Additional profiles and extensions are also routinely developed and 104 published. 106 Simple Authentication and Security Layer (SASL) [RFC4422] is a 107 generalized mechanism for identifying and authenticating a user and 108 for optionally negotiating a security layer for subsequent protocol 109 interactions. SASL is used by application protocols like IMAP, POP 110 and XMPP [RFC3920]. The effect is to make authentication modular, so 111 that newer authentication mechanisms can be added as needed. 113 The Generic Security Service Application Program Interface (GSS-API) 114 [RFC2743] provides a framework for applications to support multiple 115 authentication mechanisms through a unified programming interface. 116 This document defines a pure SASL mechanism for SAML, but it conforms 117 to the bridge between SASL and the GSS-API called GS2 [RFC5801]. 118 This means that this document defines both a SASL mechanism and a 119 GSS-API mechanism. The GSS-API interface is optional for SASL 120 implementers, and the GSS-API considerations can be avoided in 121 environments that uses SASL directly without GSS-API. 123 The mechanisms specified in this document allow a SASL- or GSS-API- 124 enabled server to act as a SAML relying party, or service provider 125 (SP), by advertising this mechanism as an option for SASL or GSS-API 126 clients that support the use of SAML to communicate identity and 127 attribute information. Clients supporting this mechanism are termed 128 "enhanced clients" in SAML terminology because they understand the 129 federated authentication model and have specific knowledge of the 130 IdP(s) associated with the user. This knowledge, and the ability to 131 act on it, addresses a significant problem with browser-based SAML 132 profiles known as the "discovery", or "where are you from?" (WAYF) 133 problem. Obviating the need for the RP to interact with the client 134 to determine the right IdP (and its network location) is both a user 135 interface and security improvement. 137 The SAML mechanism described in this document is an adaptation of an 138 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 139 (V2.0) [SAMLECP20], and therefore does not establish a separate 140 authentication, integrity and confidentiality mechanism. It is 141 anticipated that existing security layers, such as Transport Layer 142 Security (TLS) or Secure Shell (SSH), will continued to be used. 144 Figure 1 describes the interworking between SAML and SASL: this 145 document requires enhancements to the RP and to the client (as the 146 two SASL communication endpoints) but no changes to the SAML IdP are 147 assumed apart from its support for the applicable SAML profile. To 148 accomplish this, a SAML protocol exchange between the RP and the IdP, 149 brokered by the client, is tunneled within SASL. There is no assumed 150 communication between the RP and the IdP, but such communication may 151 occur in conjunction with additional SAML-related profiles not in 152 scope for this document. 154 +-----------+ 155 | SAML | 156 | Relying | 157 | Party | 158 | | 159 +-----------+ 160 ^ 161 +--|--+ 162 | S| | 163 S | A| | 164 A | M| | 165 S | L| | 166 L | | | 167 | | | 168 +--|--+ 169 +------------+ v 170 | | +----------+ 171 | SAML | SAML SOAP | | 172 | Identity |<--------------->| Client | 173 | Provider | Binding | | 174 +------------+ +----------+ 176 Figure 1: Interworking Architecture 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 The reader is also assumed to be familiar with the terms used in the 185 SAML 2.0 specification, and an understanding of the Enhanced Client 186 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 187 this mechanism explicitly reuses and references it. 189 This document can be implemented without knowledge of GSS-API since 190 the normative aspects of the GS2 protocol syntax have been duplicated 191 in this document. The document may also be implemented to provide a 192 GSS-API mechanism, and then knowledge of GSS-API is essential. To 193 faciliate these two variants, the references has been split into two 194 parts, one part that provides normative references for all readers, 195 and one part that adds additional normative references required for 196 implementers that wish to implement the GSS-API portion. 198 3. Applicability for Non-HTTP Use Cases 200 While SAML is designed to support a variety of application scenarios, 201 the profiles for authentication defined in the original standard are 202 designed around HTTP [RFC2616] applications. They are not, however, 203 limited to browsers, because it was recognized that browsers suffer 204 from a variety of functional and security deficiencies that would be 205 useful to avoid where possible. Specifically, the notion of an 206 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 207 thus the term "ECP") was specified for a software component that acts 208 somewhat like a browser from an application perspective, but includes 209 limited, but sufficient, awareness of SAML to play a more conscious 210 role in the authentication exchange between the RP and the IdP. What 211 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 212 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 214 1. The Enhanced Client requests a resource of a Relying Party (RP) 215 (via an HTTP request). In doing so, it advertises its "enhanced" 216 capability using HTTP headers. 218 2. The RP, desiring SAML authentication and noting the client's 219 capabilities, responds not with an HTTP redirect or form, but 220 with a SOAP [W3C.soap11] envelope containing a SAML 221 along with some supporting headers. This request 222 identifies the RP (and may be signed), and may provide hints to 223 the client as to what IdPs the RP finds acceptable, but the 224 choice of IdP is generally left to the client. 226 3. The client is then responsible for delivering the body of the 227 SOAP message to the IdP it is instructed to use (often via 228 configuration ahead of time). The user authenticates to the IdP 229 ahead of, during, or after the delivery of this message, and 230 perhaps explicitly authorizes the response to the RP. 232 4. Whether authentication succeeds or fails, the IdP responds with 233 its own SOAP envelope, generally containing a SAML 234 message for delivery to the RP. In a successful case, the 235 message will include a SAML containing 236 authentication, and possibly attribute, information about the 237 user. Either the response or assertion alone is signed, and the 238 assertion may be encrypted to a key negotiated with or known to 239 belong to the RP. 241 5. The client then delivers the SOAP envelope containing the 242 to the RP at a location the IdP directs (which acts as 243 an additional, though limited, defense against MITM attacks). 244 This completes the SAML exchange. 246 6. The RP now has sufficient identity information to approve the 247 original HTTP request or not, and acts accordingly. Everything 248 between the original request and this response can be thought of 249 as an "interruption" of the original HTTP exchange. 251 When considering this flow in the context of an arbitrary application 252 protocol and SASL, the RP and the client both must change their code 253 to implement this SASL mechanism, but the IdP can remain untouched. 254 The existing RP/client exchange that is tunneled through HTTP maps 255 well to the tunneling of that same exchange in SASL. In the parlance 256 of SASL [RFC4422], this mechanism is "client-first" for consistency 257 with GS2. The steps are shown below: 259 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 260 mechanisms. 262 2. The client initiates a SASL authentication with SAML20EC or 263 SAML20EC-PLUS. 265 3. The server sends the client a challenge consisting of a SOAP 266 envelope containing its SAML . 268 4. The SASL client unpacks the SOAP message and communicates with 269 its chosen IdP to relay the SAML to it. This 270 communication, and the authentication with the IdP, proceeds 271 separately from the SASL process. 273 5. Upon completion of the exchange with the IdP, the client responds 274 to the SASL server with a SOAP envelope containing the SAML 275 it obtained, or a SOAP fault, as warranted. 277 6. The SASL Server indicates success or failure. 279 Note: The details of the SAML processing, which are consistent with 280 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 281 such that the client MUST interact with the IdP in order to complete 282 any SASL exchange with the RP. The assertions issued by the IdP for 283 the purposes of the profile, and by extension this SASL mechanism, 284 are short lived, and therefore cannot be cached by the client for 285 later use. 287 Encompassed in step four is the client-driven selection of the IdP, 288 authentication to it, and the acquisition of a response to provide to 289 the SASL server. These processes are all external to SASL. 291 With all of this in mind, the typical flow appears as follows: 293 SASL Serv. Client IdP 294 |>-----(1)----->| | Advertisement 295 | | | 296 |<-----(2)-----<| | Initiation 297 | | | 298 |>-----(3)----->| | SASL Server Response 299 | | | 300 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 301 | | | 302 |<-----(5)-----<| | SASL Client Response 303 | | | 304 |>-----(6)----->| | Server sends Outcome 305 | | | 307 ----- = SASL 308 - - - = SOAP over HTTPS (external to SASL) 310 Figure 2: Authentication flow 312 4. SAML SASL Mechanism Specification 314 Based on the previous figures, the following operations are defined 315 by the SAML SASL mechanism: 317 4.1. Advertisement 319 To advertise that a server supports this mechanism, during 320 application session initiation, it displays the name "SAML20EC" 321 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms 322 (depending on its support for channel binding). 324 4.2. Initiation 326 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 327 supported by the application protocol, the client MAY include an 328 initial response, otherwise it waits until the server has issued an 329 empty challenge (because the mechanism is client-first). 331 The format of the initial client response is as follows: 333 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 335 mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 336 "WantAuthnRequestsSigned" 338 initial-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mutual] 340 The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate 341 whether the client supports channel binding. This takes the place of 342 the PAOS HTTP header extension used in [SAMLECP20] to indicate 343 channel binding support. 345 The optional "gs2-authzid" field holds the authorization identity, as 346 requested by the client. 348 The optional "hok" field is a constant that signals the client's 349 support for stronger security by means of a locally held key. This 350 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 351 to indicate "holder of key" support. 353 The optional "mutual" field is a constant that signals the client's 354 desire for mutual authentication. If set, the SASL server MUST 355 digitally sign its SAML message. The URN constant 356 above is a single string; the linefeed is shown for RFC formatting 357 reasons. 359 4.3. Server Response 361 The SASL server responds with a SOAP envelope constructed in 362 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 363 to the SOAP header requirements of the SAML PAOS Binding 364 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 365 profile. Various SOAP headers are also consumed by the client in 366 exactly the same manner prescribed by that section. 368 4.4. User Authentication with Identity Provider 370 Upon receipt of the Server Response (Section 4.3), the steps 371 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 372 performed between the client and the chosen IdP. The means by which 373 the client determines the IdP to use, and where it is located, are 374 out of scope of this mechanism. 376 The exact means of authentication to the IdP are also out of scope, 377 but clients supporting this mechanism MUST support HTTP Basic 378 Authentication as defined in [RFC2617] and TLS client authentication 379 as defined in [RFC5246]. 381 4.5. Client Response 383 Assuming a response is obtained from the IdP, the client responds to 384 the SASL server with a SOAP envelope constructed in accordance with 385 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 386 header requirements of the SAML PAOS Binding 387 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 388 profile. If the client is unable to obtain a response from the IdP, 389 it responds to the SASL server with a SOAP envelope containing a SOAP 390 fault. 392 4.6. Outcome 394 The SAML protocol exchange having completed, the SASL server will 395 transmit the outcome to the client depending on local validation of 396 the client responses. This outcome is transmitted in accordance with 397 the application protocol in use. 399 4.7. Additional Notes 401 Because this mechanism is an adaptation of an HTTP-based profile, 402 there are a few requirements outlined in [SAMLECP20] that make 403 reference to a response URL that is normally used to regulate where 404 the client returns information to the RP. There are also security- 405 related checks built into the profile that involve this location. 407 For compatibility with existing IdP and profile behavior, and to 408 provide for mutual authentication, the SASL server MUST populate the 409 responseConsumerURL and AssertionConsumerServiceURL attributes with 410 its service name. The parties then perform the steps described in 411 [SAMLECP20] as usual. 413 Similarly, the use of HTTP status signaling between the RP and client 414 mandated by [SAMLECP20] may not be applicable. 416 5. SAML EC GSS-API Mechanism Specification 418 This section and its sub-sections and all normative references of it 419 not referenced elsewhere in this document are INFORMATIONAL for SASL 420 implementors, but they are NORMATIVE for GSS-API implementors. 422 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 423 The messages are the same, but a) the GS2 header on the client's 424 first message is excluded when SAML EC is used as a GSS-API 425 mechanism, and b) the RFC2743 section 3.1 initial context token 426 header is prefixed to the client's first authentication message 427 (context token). 429 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 430 IANA considerations). The DER encoding of the OID is TBD. 432 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 433 resulting in the "mutual-auth" option set in the initial client 434 response. The security context mutual_state flag is set to TRUE only 435 if the server digitally signs its SAML message, and 436 the identity provider signals this to the client in an SOAP header block. 439 If the mutual_state flag is not requested, or is not set, then the 440 security layer managed by the application outside of the GSS-API 441 mechanism is responsible for authenticating the acceptor. In this 442 case, applications MUST match the server identity from the existing 443 security layer with the target name. For TLS, this matching MUST be 444 performed as discussed in [RFC6125]. For SSH, this matching MUST be 445 performed as discussed in [RFC4462]. 447 The lifetime of a security context established with this mechanism 448 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 449 any, in the of the SAML assertion received by the 450 RP. 452 SAML EC supports credential delegation through the issuance of SAML 453 assertions that the issuing identity provider will accept as proof of 454 authentication by a service on behalf of a user. Such assertions 455 MUST contain an condition element identifying 456 the identity provider, and a element that the 457 acceptor can satisy. In such a case, the security context will have 458 its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. 460 5.1. Session Key Derivation 462 Some GSS-API features (discussed in the following sections) require a 463 session key be established as a result security context 464 establishment. In the common case of a "bearer" assertion in SAML, 465 there is no secure mechanism by which such a key can be established 466 other than by exporting key material from TLS (discussed below). In 467 other cases such as assertions based on "holder of key" confirmation, 468 there may be additional methods available. 470 Information defining or describing the session key, or a process for 471 deriving one, is communicated by the client to the server using an 472 SOAP header block, as defined in [SAMLECP20]. This 473 header contains a element as a generic container, and is 474 designed to support reuse of mechanisms defined by [XMLENC11] or 475 other specifications. 477 5.1.1. TLS-Exported Session Keys 479 If a TLS session is established between the initiator and acceptor, 480 it may be used to produce a session key using the mechanism defined 481 by [RFC5705]. The disambiguating label string MUST be set to 482 "EXPORTER_SAML20EC". [Remove upon publication, IANA to assign at the 483 following location: http://www.iana.org/assignments/tls-parameters/ 484 tls-parameters.xml#exporter-labels] The per-association context value 485 MUST be set to a 128-bit pseudorandom value generated by the client. 486 The pseudorandom octets are then base64- encoded and placed in a 487 element inside a SOAP header block in 488 the following manner: 490 494 495 496 497 498 h1dqhs+aHxYjYNKiEwzjVg== 499 500 501 502 503 505 The derivation algorithm of TBD (IANA to assign: see IANA 506 considerations) signifies the TLS-Exported approach described above. 508 5.1.2. Bearer Assertion Session Keys 510 In the event that a client is not capable of supporting the "holder 511 of key" option (or if other infrastructure components do not do so) 512 and cannot use a TLS-exported key, but still wishes to make use of a 513 session key, the client MAY generate a pseudorandom value of 128 bits 514 to use as a key. The octets are then base64-encoded and placed in a 515 element inside a SOAP header block in 516 the following manner: 518 522 523 524 525 526 h1dqhs+aHxYjYNKiEwzjVg== 527 528 529 530 531 533 The derivation algorithm of TBD (IANA to assign: see IANA 534 considerations) signifies the client-generated approach described 535 above. 537 Applications that rely on this mechanism do so with the understanding 538 that it is not a secure approach, but merely for compatibility if the 539 risk is acceptable. 541 5.1.3. Holder of Key Session Keys 543 In the event that a client is proving possession of a secret or 544 private key, the session key can be communicated in a manner that 545 proves its authenticity, or a formal key agreement algorithm may be 546 supported. For example, if the server has an elliptic curve public 547 key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11] 548 may be used. 550 If a key agreement or derivation process is not possible, then the 551 mechanism defined in the previous section can be used, with the added 552 benefit that the client's request will be strongly authenticated by a 553 key. However, if channel binding is not used, the generated key 554 SHOULD be wrapped or transported under the protection of a key 555 belonging to the server, such as an RSA public key. The element and associated key wrap and transport 557 algorithms (see [XMLENC11]) can be used for this purpose. 559 Note that this serves no purpose in the bearer case, since if channel 560 binding is not used, an attacker can generate its own key, and if it 561 is used, there is no MITM to see the key. 563 5.2. Per-Message Tokens 565 The per-message tokens SHALL be the same as those for the Kerberos V 566 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections), using 567 the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962]. 569 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 570 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 571 (GSS_C_CONF_FLAG) security context flags are always set to TRUE. 573 The 128-bit session "protocol key" SHALL be a session key established 574 in a manner described in the previous section. "Specific keys" are 575 then derived as usual as described in Section 2 of [RFC4121], 576 [RFC3961], and [RFC3962]. 578 The terms "protocol key" and "specific key" are Kerberos V5 terms 579 [RFC3961]. 581 SAML20EC is PROT_READY as soon as the SAML response message has been 582 seen. 584 5.3. Pseudo-Random Function (PRF) 586 The GSS-API has been extended with a Pseudo-Random Function (PRF) 587 interface in [RFC4401]. The purpose is to enable applications to 588 derive a cryptographic key from an established GSS-API security 589 context. This section defines a GSS_Pseudo_random that is applicable 590 for the SAML20EC GSS-API mechanism. 592 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 593 Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor- 594 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 595 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 596 for the GSS_Pseudo_random() SHALL be the same as the key defined in 597 the previous section. 599 5.4. GSS-API Principal Name Types for SAML EC 601 Services that act as SAML relying parties are typically identified by 602 means of a URI called an "entityID". Clients that are named in the 603 element of a SAML assertion are typically identified by 604 means of a element, which is an extensible XML structure 605 containing, at minimum, an element value that names the subject and a 606 Format attribute. 608 In practice, a GSS-API client and server are unlikely to know in 609 advance the name of the initiator as it will be expressed by the SAML 610 identity provider upon completion of authentication. It is also 611 generally incorrect to assume that a particular acceptor name will 612 directly map into a particular RP entityID, because there is often a 613 layer of naming indirection between particular services on hosts and 614 the identity of a relying party in SAML terms. 616 To avoid complexity, and avoid unnecessary use of XML within the 617 naming layer, the SAML EC mechanism relies on the common/expected 618 name types used for acceptors and initiators, 619 GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism 620 provides for validation of the host-based service name in conjunction 621 with the SAML exchange. It does not attempt to solve the problem of 622 mapping between an initiator "username", the user's identity while 623 authenticating to the identity provider, and the information supplied 624 by the identity provider to the acceptor. These relationships must 625 be managed through local policy at the initiator and acceptor. 627 SAML-based information associated with the initiator SHOULD be 628 expressed to the acceptor using GSS-API naming extensions 629 [I-D.ietf-kitten-gssapi-naming-exts], in accordance with 630 [I-D.ietf-abfab-gss-eap-naming]. 632 5.4.1. User Naming Considerations 634 The GSS_C_NT_USER_NAME form represents the name of an individual 635 user. Clients often rely on this value to determine the appropriate 636 credentials to use in authenticating to the identity provider, and 637 supply it to the server for use by the acceptor. 639 Upon successful completion of this mechanism, the server MUST 640 construct the authenticated initiator name based on the 641 element in the assertion it successfully validated. The name is 642 constructed as a UTF-8 string in the following form: 644 name = element-value "!" Format "!" NameQualifier 645 "!" SPNameQualifier "!" SPProvidedID 647 The "element-value" token refers to the content of the 648 element. The other tokens refer to the identically named XML 649 attributes defined for use with the element. If an attribute is not 650 present, which is common, it is omitted (i.e., replaced with the 651 empty string). The Format value is never omitted; if not present, 652 the SAML-equivalent value of 653 "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used. 655 Not all SAML assertions contain a element. In the 656 event that no such element is present, including the exceptional 657 cases of a element or a element that 658 cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used 659 for the initiator name. 661 As noted in the previous section, it is expected that most 662 applications able to rely on SAML authentication would make use of 663 naming extensions to obtain additional information about the user 664 based on the assertion. This is particularly true in the anonymous 665 case, or in cases in which the SAML name is pseudonymous or transient 666 in nature. The ability to express the SAML name in 667 GSS_C_NT_USER_NAME form is intended for compatibility with 668 applications that cannot make use of additional information. 670 5.4.2. Service Naming Considerations 672 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 673 on a host; it is textually represented as "service@host". This name 674 form is required by most SASL profiles and is used by many existing 675 applications that use the Kerberos GSS-API mechanism. Such a name is 676 used directly by this mechanism as the effective 677 AssertionConsumerService of the server. 679 This value is used in the construction of the responseConsumerURL and 680 AssertionConsumerServiceURL attributes, and for eventual comparison 681 and validation by the client before completing the exchange. The 682 value MUST be securely associated with the SAML entityID claimed by 683 the server by the identity provider, such as through the use of SAML 684 metadata [OASIS.saml-metadata-2.0-os]. 686 6. Example 688 Suppose the user has an identity at the SAML IdP saml.example.org and 689 a Jabber Identifier (jid) "somenode@example.com", and wishes to 690 authenticate his XMPP connection to xmpp.example.com (and example.com 691 and example.org have established a SAML-capable trust relationship). 692 The authentication on the wire would then look something like the 693 following: 695 Step 1: Client initiates stream to server: 697 701 Step 2: Server responds with a stream tag sent to client: 703 707 Step 3: Server informs client of available authentication mechanisms: 709 710 711 DIGEST-MD5 712 PLAIN 713 SAML20EC 714 715 717 Step 4: Client selects an authentication mechanism and sends the 718 initial client response (it is base64 encoded as specified by the 719 XMPP SASL protocol profile): 721 722 biwsLA== 723 725 The initial response is "n,," which signals that channel binding is 726 not used, there is no authorization identity, and the client does not 727 support key-based confirmation or want mutual authentication. 729 Step 5: Server sends a challenge to client in the form of a SOAP 730 envelope containing its SAML : 732 733 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 734 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 735 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 736 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 737 bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 738 ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 739 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u 740 c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj 741 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg 742 ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB 743 TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h 744 cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k 745 PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft 746 bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 747 L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB 748 dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 749 ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n 750 PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz 751 c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N 752 CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 753 TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg 754 ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl 755 YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu 756 MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB 757 dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u 758 dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj 759 bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu 760 Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ 761 IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w 762 ZT4NCg== 763 765 The Base64 [RFC4648] decoded envelope: 767 771 772 777 781 https://xmpp.example.com 782 783 784 785 789 790 https://xmpp.example.com 791 792 794 795 796 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 797 798 799 800 801 803 Step 5 (alt): Server returns error to client: 805 806 807 808 810 Step 6: Client relays the request to IdP in a SOAP message 811 transmitted over HTTP (over TLS). HTTP portion not shown, use of 812 Basic Authentication is assumed. The body of the SOAP envelope is 813 exactly the same as received in the previous step. 815 819 820 821 822 823 824 826 Step 7: IdP responds to client with a SOAP response containing a SAML 827 containing a short-lived SSO assertion (shown as an 828 encrypted variant in the example). 830 834 835 838 839 840 843 https://saml.example.org 844 845 847 848 849 850 851 852 853 855 Step 8: Client sends SOAP envelope containing the SAML as 856 a response to the SASL server's challenge: 858 859 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 860 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 861 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 862 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug 863 eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i 864 aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt 865 dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 866 L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 867 cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy 868 LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz 869 dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 870 ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s 871 cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 872 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg 873 ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg 874 ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk 875 QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu 876 dmVsb3BlPg0K 877 879 The Base64 [RFC4648] decoded envelope: 881 885 886 889 890 891 894 https://saml.example.org 895 896 898 899 900 901 902 903 904 906 Step 9: Server informs client of successful authentication: 908 910 Step 9 (alt): Server informs client of failed authentication: 912 913 914 915 917 Step 10: Client initiates a new stream to server: 919 922 Step 11: Server responds by sending a stream header to client along 923 with any additional features (or an empty features element): 925 928 929 930 931 933 Step 12: Client binds a resource: 935 936 937 someresource 938 939 941 Step 13: Server informs client of successful resource binding: 943 944 945 somenode@example.com/someresource 946 947 949 Please note: line breaks were added to the base64 for clarity. 951 7. Security Considerations 953 This section will address only security considerations associated 954 with the use of SAML with SASL applications. For considerations 955 relating to SAML in general, the reader is referred to the SAML 956 specification and to other literature. Similarly, for general SASL 957 Security Considerations, the reader is referred to that 958 specification. 960 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 961 optional support for channel binding and use of "Holder of Key" 962 subject confirmation. The former is strongly recommended for use 963 with this mechanism to detect "Man in the Middle" attacks between the 964 client and the RP without relying on flawed commercial TLS 965 infrastructure. The latter may be impractical in many cases, but is 966 a valuable way of strengthening client authentication, protecting 967 against phishing, and improving the overall mechanism. 969 7.1. Risks Left Unaddressed 971 The adaptation of a web-based profile that is largely designed around 972 security-oblivious clients and a bearer model for security token 973 validation results in a number of basic security exposures that 974 should be weighed against the compatibility and client simplification 975 benefits of this mechanism. 977 When channel binding is not used, protection against "Man in the 978 Middle" attacks is left to lower layer protocols such as TLS, and the 979 development of user interfaces able to implement that has not been 980 effectively demonstrated. Failure to detect a MITM can result in 981 phishing of the user's credentials if the attacker is between the 982 client and IdP, or the theft and misuse of a short-lived credential 983 (the SAML assertion) if the attacker is able to impersonate a RP. 984 SAML allows for source address checking as a minor mitigation to the 985 latter threat, but this is often impractical. IdPs can mitigate to 986 some extent the exposure of personal information to RP attackers by 987 encrypting assertions with authenticated keys. 989 7.2. User Privacy 991 The IdP is aware of each RP that a user logs into. There is nothing 992 in the protocol to hide this information from the IdP. It is not a 993 requirement to track the activity, but there is nothing technically 994 that prohibits the collection of this information. SASL servers 995 should be aware that SAML IdPs will track - to some extent - user 996 access to their services. 998 It is also out of scope of the mechanism to determine under what 999 conditions an IdP will release particular information to a relying 1000 party, and it is generally unclear in what fashion user consent could 1001 be established in real time for the release of particular 1002 information. The SOAP exchange with the IdP does not preclude such 1003 interaction, but neither does it define that interoperably. 1005 7.3. Collusion between RPs 1007 Depending on the information supplied by the IdP, it may be possible 1008 for RPs to correlate data that they have collected. By using the 1009 same identifier to log into every RP, collusion between RPs is 1010 possible. SAML supports the notion of pairwise, or targeted/ 1011 directed, identity. This allows the IdP to manage opaque, pairwise 1012 identifiers for each user that are specific to each RP. However, 1013 correlation is often possible based on other attributes supplied, and 1014 is generally a topic that is beyond the scope of this mechanism. It 1015 is sufficient to say that this mechanism does not introduce new 1016 correlation opportunities over and above the use of SAML in web-based 1017 use cases. 1019 8. IANA Considerations 1021 The IANA is requested to assign a new entry for this GSS mechanism in 1022 the sub-registry for SMI Security for Mechanism Codes, whose prefix 1023 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 1024 reference this specification in the registry. 1026 The IANA is requested to register the following SASL profile: 1028 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 1030 Security Considerations: See this document 1032 Published Specification: See this document 1034 For further information: Contact the authors of this document. 1036 Owner/Change controller: the IETF 1038 Note: None 1040 The IANA is requested to assign a new entry of "EXPORTER_SAML20EC" in 1041 the TLS Parameters Exporter Label Registry. 1043 The IANA is requested to assign two URIs to identify the key 1044 derivation algorithms described in this document for TLS-exported, 1045 and client-generated session keys. 1047 9. References 1049 9.1. Normative References 1051 [OASIS.saml-bindings-2.0-os] 1052 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1053 Maler, "Bindings for the OASIS Security Assertion Markup 1054 Language (SAML) V2.0", OASIS 1055 Standard saml-bindings-2.0-os, March 2005. 1057 [OASIS.saml-core-2.0-os] 1058 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1059 "Assertions and Protocol for the OASIS Security Assertion 1060 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1061 2.0-os, March 2005. 1063 [OASIS.saml-profiles-2.0-os] 1064 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1065 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1066 Security Assertion Markup Language (SAML) V2.0", OASIS 1067 Standard OASIS.saml-profiles-2.0-os, March 2005. 1069 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1070 Requirement Levels", BCP 14, RFC 2119, March 1997. 1072 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1073 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1074 Authentication: Basic and Digest Access Authentication", 1075 RFC 2617, June 1999. 1077 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1078 Security Layer (SASL)", RFC 4422, June 2006. 1080 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1081 "Generic Security Service Application Program Interface 1082 (GSS-API) Authentication and Key Exchange for the Secure 1083 Shell (SSH) Protocol", RFC 4462, May 2006. 1085 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1086 Encodings", RFC 4648, October 2006. 1088 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1089 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1091 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1092 Verification of Domain-Based Application Service Identity 1093 within Internet Public Key Infrastructure Using X.509 1094 (PKIX) Certificates in the Context of Transport Layer 1095 Security (TLS)", RFC 6125, March 2011. 1097 [SAMLECP20] 1098 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1099 Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp- 1100 v2.0-wd05, July 2012. 1102 [W3C.soap11] 1103 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1104 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1105 "Simple Object Access Protocol (SOAP) 1.1", W3C 1106 Note soap11, May 2000, . 1108 9.2. Normative References for GSS-API Implementers 1110 [I-D.ietf-abfab-gss-eap-naming] 1111 Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1112 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-04 1113 (work in progress), August 2012. 1115 [I-D.ietf-kitten-gssapi-naming-exts] 1116 Williams, N., Johansson, L., Hartman, S., and S. 1117 Josefsson, "GSS-API Naming Extensions", 1118 draft-ietf-kitten-gssapi-naming-exts-15 (work in 1119 progress), May 2012. 1121 [RFC2743] Linn, J., "Generic Security Service Application Program 1122 Interface Version 2, Update 1", RFC 2743, January 2000. 1124 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1125 Kerberos 5", RFC 3961, February 2005. 1127 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1128 Encryption for Kerberos 5", RFC 3962, February 2005. 1130 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1131 Version 5 Generic Security Service Application Program 1132 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1133 July 2005. 1135 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1136 Extension for the Generic Security Service Application 1137 Program Interface (GSS-API)", RFC 4401, February 2006. 1139 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1140 Kerberos V Generic Security Service Application Program 1141 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1143 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1144 Layer Security (TLS)", RFC 5705, March 2010. 1146 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1147 Service Application Program Interface (GSS-API) Mechanisms 1148 in Simple Authentication and Security Layer (SASL): The 1149 GS2 Mechanism Family", RFC 5801, July 2010. 1151 [XMLENC11] 1152 Hirsch, F. and T. Roessler, "XML Encryption Syntax and 1153 Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- 1154 core-11-ed, August 2012. 1156 9.3. Informative References 1158 [OASIS.saml-metadata-2.0-os] 1159 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1160 "Metadata for the Security Assertion Markup Language 1161 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1162 March 2005. 1164 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1165 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1166 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1168 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1169 Protocol (XMPP): Core", RFC 3920, October 2004. 1171 Appendix A. Acknowledgments 1173 The authors would like to thank Klaas Wierenga, Sam Hartman, Nico 1174 Williams, and Jim Basney for their contributions. 1176 Appendix B. Changes 1178 This section to be removed prior to publication. 1180 o 03, added TLS key export as a session key option, revised GSS 1181 naming material based on list discussion 1183 o 02, major revision of GSS-API material and updated references 1185 o 01, SSH language added, noted non-assumption of HTTP error 1186 handling, added guidance on life of security context. 1188 o 00, Initial Revision, first WG-adopted draft. Removed support for 1189 unsolicited SAML responses. 1191 Authors' Addresses 1193 Scott Cantor 1194 Shibboleth Consortium 1195 2740 Airport Drive 1196 Columbus, Ohio 43219 1197 United States 1199 Phone: +1 614 247 6147 1200 Email: cantor.2@osu.edu 1202 Simon Josefsson 1203 SJD AB 1204 Hagagatan 24 1205 Stockholm 113 47 1206 SE 1208 Email: simon@josefsson.org 1209 URI: http://josefsson.org/