idnits 2.17.1 draft-ietf-kitten-sasl-saml-ec-02.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 (August 13, 2012) is 4274 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 1062, but not defined == Missing Reference: 'RFC5801' is mentioned on line 1084, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1071, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1068, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1065, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1076, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1080, 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 1056, but not defined == Missing Reference: 'I-D.ietf-abfab-gss-eap-naming' is mentioned on line 1051, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC11' -- 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 (~~), 11 warnings (==), 5 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: February 14, 2013 SJD AB 6 August 13, 2012 8 SAML Enhanced Client SASL and GSS-API Mechanisms 9 draft-ietf-kitten-sasl-saml-ec-02.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 February 14, 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. Bearer Assertion Session Keys . . . . . . . . . . . . 13 73 5.1.2. Holder of Key Session Keys . . . . . . . . . . . . . . 14 74 5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 75 5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 14 76 5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 77 5.4.1. Support for User Name Form . . . . . . . . . . . . . . 15 78 5.4.2. Support for Host-Based Service Name Form . . . . . . . 16 79 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 24 82 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 83 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 25 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 87 9.2. Normative References for GSS-API Implementers . . . . . . 28 88 9.3. Informative References . . . . . . . . . . . . . . . . . . 29 89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 90 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 31 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 Security Assertion Markup Language (SAML) 2.0 96 [OASIS.saml-core-2.0-os] is a modular specification that provides 97 various means for a user to be identified to a relying party (RP) 98 through the exchange of (typically signed) assertions issued by an 99 identity provider (IdP). It includes a number of protocols, protocol 100 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 101 [OASIS.saml-profiles-2.0-os] designed for different use cases. 102 Additional profiles and extensions are also routinely developed and 103 published. 105 Simple Authentication and Security Layer (SASL) [RFC4422] is a 106 generalized mechanism for identifying and authenticating a user and 107 for optionally negotiating a security layer for subsequent protocol 108 interactions. SASL is used by application protocols like IMAP, POP 109 and XMPP [RFC3920]. The effect is to make authentication modular, so 110 that newer authentication mechanisms can be added as needed. 112 The Generic Security Service Application Program Interface (GSS-API) 113 [RFC2743] provides a framework for applications to support multiple 114 authentication mechanisms through a unified programming interface. 115 This document defines a pure SASL mechanism for SAML, but it conforms 116 to the bridge between SASL and the GSS-API called GS2 [RFC5801]. 117 This means that this document defines both a SASL mechanism and a 118 GSS-API mechanism. The GSS-API interface is optional for SASL 119 implementers, and the GSS-API considerations can be avoided in 120 environments that uses SASL directly without GSS-API. 122 The mechanisms specified in this document allow a SASL- or GSS-API- 123 enabled server to act as a SAML relying party, or service provider 124 (SP), by advertising this mechanism as an option for SASL or GSS-API 125 clients that support the use of SAML to communicate identity and 126 attribute information. Clients supporting this mechanism are termed 127 "enhanced clients" in SAML terminology because they understand the 128 federated authentication model and have specific knowledge of the 129 IdP(s) associated with the user. This knowledge, and the ability to 130 act on it, addresses a significant problem with browser-based SAML 131 profiles known as the "discovery", or "where are you from?" (WAYF) 132 problem. Obviating the need for the RP to interact with the client 133 to determine the right IdP (and its network location) is both a user 134 interface and security improvement. 136 The SAML mechanism described in this document is an adaptation of an 137 existing SAML profile, the Enhanced Client or Proxy (ECP) Profile 138 (V2.0) [SAMLECP20], and therefore does not establish a separate 139 authentication, integrity and confidentiality mechanism. It is 140 anticipated that existing security layers, such as Transport Layer 141 Security (TLS) or Secure Shell (SSH), will continued to be used. 143 Figure 1 describes the interworking between SAML and SASL: this 144 document requires enhancements to the RP and to the client (as the 145 two SASL communication endpoints) but no changes to the SAML IdP are 146 assumed apart from its support for the applicable SAML profile. To 147 accomplish this, a SAML protocol exchange between the RP and the IdP, 148 brokered by the client, is tunneled within SASL. There is no assumed 149 communication between the RP and the IdP, but such communication may 150 occur in conjunction with additional SAML-related profiles not in 151 scope for this document. 153 +-----------+ 154 | SAML | 155 | Relying | 156 | Party | 157 | | 158 +-----------+ 159 ^ 160 +--|--+ 161 | S| | 162 S | A| | 163 A | M| | 164 S | L| | 165 L | | | 166 | | | 167 +--|--+ 168 +------------+ v 169 | | +----------+ 170 | SAML | SAML SOAP | | 171 | Identity |<--------------->| Client | 172 | Provider | Binding | | 173 +------------+ +----------+ 175 Figure 1: Interworking Architecture 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 The reader is also assumed to be familiar with the terms used in the 184 SAML 2.0 specification, and an understanding of the Enhanced Client 185 or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of 186 this mechanism explicitly reuses and references it. 188 This document can be implemented without knowledge of GSS-API since 189 the normative aspects of the GS2 protocol syntax have been duplicated 190 in this document. The document may also be implemented to provide a 191 GSS-API mechanism, and then knowledge of GSS-API is essential. To 192 faciliate these two variants, the references has been split into two 193 parts, one part that provides normative references for all readers, 194 and one part that adds additional normative references required for 195 implementers that wish to implement the GSS-API portion. 197 3. Applicability for Non-HTTP Use Cases 199 While SAML is designed to support a variety of application scenarios, 200 the profiles for authentication defined in the original standard are 201 designed around HTTP [RFC2616] applications. They are not, however, 202 limited to browsers, because it was recognized that browsers suffer 203 from a variety of functional and security deficiencies that would be 204 useful to avoid where possible. Specifically, the notion of an 205 "Enhanced Client" (or a proxy acting as one on behalf of a browser, 206 thus the term "ECP") was specified for a software component that acts 207 somewhat like a browser from an application perspective, but includes 208 limited, but sufficient, awareness of SAML to play a more conscious 209 role in the authentication exchange between the RP and the IdP. What 210 follows is an outline of the Enhanced Client or Proxy (ECP) Profile 211 (V2.0) [SAMLECP20], as applied to the web/HTTP service use case: 213 1. The Enhanced Client requests a resource of a Relying Party (RP) 214 (via an HTTP request). In doing so, it advertises its "enhanced" 215 capability using HTTP headers. 217 2. The RP, desiring SAML authentication and noting the client's 218 capabilities, responds not with an HTTP redirect or form, but 219 with a SOAP [W3C.soap11] envelope containing a SAML 220 along with some supporting headers. This request 221 identifies the RP (and may be signed), and may provide hints to 222 the client as to what IdPs the RP finds acceptable, but the 223 choice of IdP is generally left to the client. 225 3. The client is then responsible for delivering the body of the 226 SOAP message to the IdP it is instructed to use (often via 227 configuration ahead of time). The user authenticates to the IdP 228 ahead of, during, or after the delivery of this message, and 229 perhaps explicitly authorizes the response to the RP. 231 4. Whether authentication succeeds or fails, the IdP responds with 232 its own SOAP envelope, generally containing a SAML 233 message for delivery to the RP. In a successful case, the 234 message will include a SAML containing 235 authentication, and possibly attribute, information about the 236 user. Either the response or assertion alone is signed, and the 237 assertion may be encrypted to a key negotiated with or known to 238 belong to the RP. 240 5. The client then delivers the SOAP envelope containing the 241 to the RP at a location the IdP directs (which acts as 242 an additional, though limited, defense against MITM attacks). 243 This completes the SAML exchange. 245 6. The RP now has sufficient identity information to approve the 246 original HTTP request or not, and acts accordingly. Everything 247 between the original request and this response can be thought of 248 as an "interruption" of the original HTTP exchange. 250 When considering this flow in the context of an arbitrary application 251 protocol and SASL, the RP and the client both must change their code 252 to implement this SASL mechanism, but the IdP can remain untouched. 253 The existing RP/client exchange that is tunneled through HTTP maps 254 well to the tunneling of that same exchange in SASL. In the parlance 255 of SASL [RFC4422], this mechanism is "client-first" for consistency 256 with GS2. The steps are shown below: 258 1. The server MAY advertise the SAML20EC and/or SAML20EC-PLUS 259 mechanisms. 261 2. The client initiates a SASL authentication with SAML20EC or 262 SAML20EC-PLUS. 264 3. The server sends the client a challenge consisting of a SOAP 265 envelope containing its SAML . 267 4. The SASL client unpacks the SOAP message and communicates with 268 its chosen IdP to relay the SAML to it. This 269 communication, and the authentication with the IdP, proceeds 270 separately from the SASL process. 272 5. Upon completion of the exchange with the IdP, the client responds 273 to the SASL server with a SOAP envelope containing the SAML 274 it obtained, or a SOAP fault, as warranted. 276 6. The SASL Server indicates success or failure. 278 Note: The details of the SAML processing, which are consistent with 279 the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are 280 such that the client MUST interact with the IdP in order to complete 281 any SASL exchange with the RP. The assertions issued by the IdP for 282 the purposes of the profile, and by extension this SASL mechanism, 283 are short lived, and therefore cannot be cached by the client for 284 later use. 286 Encompassed in step four is the client-driven selection of the IdP, 287 authentication to it, and the acquisition of a response to provide to 288 the SASL server. These processes are all external to SASL. 290 With all of this in mind, the typical flow appears as follows: 292 SASL Serv. Client IdP 293 |>-----(1)----->| | Advertisement 294 | | | 295 |<-----(2)-----<| | Initiation 296 | | | 297 |>-----(3)----->| | SASL Server Response 298 | | | 299 | |<- - -(4)- - >| SOAP AuthnRequest + user authn 300 | | | 301 |<-----(5)-----<| | SASL Client Response 302 | | | 303 |>-----(6)----->| | Server sends Outcome 304 | | | 306 ----- = SASL 307 - - - = SOAP over HTTPS (external to SASL) 309 Figure 2: Authentication flow 311 4. SAML SASL Mechanism Specification 313 Based on the previous figures, the following operations are defined 314 by the SAML SASL mechanism: 316 4.1. Advertisement 318 To advertise that a server supports this mechanism, during 319 application session initiation, it displays the name "SAML20EC" 320 and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms 321 (depending on its support for channel binding). 323 4.2. Initiation 325 A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If 326 supported by the application protocol, the client MAY include an 327 initial response, otherwise it waits until the server has issued an 328 empty challenge (because the mechanism is client-first). 330 The format of the initial client response is as follows: 332 hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" 334 mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ 335 "WantAuthnRequestsSigned" 337 initial-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mutual] 339 The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate 340 whether the client supports channel binding. This takes the place of 341 the PAOS HTTP header extension used in [SAMLECP20] to indicate 342 channel binding support. 344 The optional "gs2-authzid" field holds the authorization identity, as 345 requested by the client. 347 The optional "hok" field is a constant that signals the client's 348 support for stronger security by means of a locally held key. This 349 takes the place of the PAOS HTTP header extension used in [SAMLECP20] 350 to indicate "holder of key" support. 352 The optional "mutual" field is a constant that signals the client's 353 desire for mutual authentication. If set, the SASL server MUST 354 digitally sign its SAML message. The URN constant 355 above is a single string; the linefeed is shown for RFC formatting 356 reasons. 358 4.3. Server Response 360 The SASL server responds with a SOAP envelope constructed in 361 accordance with section 2.3.2 of [SAMLECP20]. This includes adhering 362 to the SOAP header requirements of the SAML PAOS Binding 363 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 364 profile. Various SOAP headers are also consumed by the client in 365 exactly the same manner prescribed by that section. 367 4.4. User Authentication with Identity Provider 369 Upon receipt of the Server Response (Section 4.3), the steps 370 described in sections 2.3.3 through 2.3.6 of [SAMLECP20] are 371 performed between the client and the chosen IdP. The means by which 372 the client determines the IdP to use, and where it is located, are 373 out of scope of this mechanism. 375 The exact means of authentication to the IdP are also out of scope, 376 but clients supporting this mechanism MUST support HTTP Basic 377 Authentication as defined in [RFC2617] and TLS client authentication 378 as defined in [RFC5246]. 380 4.5. Client Response 382 Assuming a response is obtained from the IdP, the client responds to 383 the SASL server with a SOAP envelope constructed in accordance with 384 section 2.3.7 of [SAMLECP20]. This includes adhering to the SOAP 385 header requirements of the SAML PAOS Binding 386 [OASIS.saml-bindings-2.0-os], for compatibility with the existing 387 profile. If the client is unable to obtain a response from the IdP, 388 it responds to the SASL server with a SOAP envelope containing a SOAP 389 fault. 391 4.6. Outcome 393 The SAML protocol exchange having completed, the SASL server will 394 transmit the outcome to the client depending on local validation of 395 the client responses. This outcome is transmitted in accordance with 396 the application protocol in use. 398 4.7. Additional Notes 400 Because this mechanism is an adaptation of an HTTP-based profile, 401 there are a few requirements outlined in [SAMLECP20] that make 402 reference to a response URL that is normally used to regulate where 403 the client returns information to the RP. There are also security- 404 related checks built into the profile that involve this location. 406 For compatibility with existing IdP and profile behavior, and to 407 provide for mutual authentication, the SASL server MUST populate the 408 responseConsumerURL and AssertionConsumerServiceURL attributes with 409 its service name. The parties then perform the steps described in 410 [SAMLECP20] as usual. 412 Similarly, the use of HTTP status signaling between the RP and client 413 mandated by [SAMLECP20] may not be applicable. 415 5. SAML EC GSS-API Mechanism Specification 417 This section and its sub-sections and all normative references of it 418 not referenced elsewhere in this document are INFORMATIONAL for SASL 419 implementors, but they are NORMATIVE for GSS-API implementors. 421 The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism. 422 The messages are the same, but a) the GS2 header on the client's 423 first message is excluded when SAML EC is used as a GSS-API 424 mechanism, and b) the RFC2743 section 3.1 initial context token 425 header is prefixed to the client's first authentication message 426 (context token). 428 The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see 429 IANA considerations). The DER encoding of the OID is TBD. 431 The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, 432 resulting in the "mutual-auth" option set in the initial client 433 response. The security context mutual_state flag is set to TRUE only 434 if the server digitally signs its SAML message, and 435 the identity provider signals this to the client in an SOAP header block. 438 If the mutual_state flag is not requested, or is not set, then the 439 security layer managed by the application outside of the GSS-API 440 mechanism is responsible for authenticating the acceptor. In this 441 case, applications MUST match the server identity from the existing 442 security layer with the target name. For TLS, this matching MUST be 443 performed as discussed in [RFC6125]. For SSH, this matching MUST be 444 performed as discussed in [RFC4462]. 446 The lifetime of a security context established with this mechanism 447 SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if 448 any, in the of the SAML assertion received by the 449 RP. 451 SAML EC supports credential delegation through the issuance of SAML 452 assertions that the issuing identity provider will accept as proof of 453 authentication by a service on behalf of a user. Such assertions 454 MUST contain an condition element identifying 455 the identity provider, and a element that the 456 acceptor can satisy. In such a case, the security context will have 457 its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. 459 5.1. Session Key Derivation 461 Some GSS-API features (discussed in the following sections) require a 462 session key be established as a result security context 463 establishment. In the common case of a "bearer" assertion in SAML, 464 there is no secure mechanism by which such a key can be established. 465 In other cases such as assertions based on "holder of key" 466 confirmation, there may be. 468 Information defining or describing the session key, or a process for 469 deriving one, is communicated by the client to the server using an 470 SOAP header block, as defined in [SAMLECP20]. This 471 header contains a element as a generic container, and is 472 designed to support reuse of mechanisms defined by [XMLENC11] or 473 other specifications. 475 5.1.1. Bearer Assertion Session Keys 477 In the event that a client is not capable of supporting the "holder 478 of key" option (or if other infrastructure components do not do so), 479 but still wishes to make use of a session key, the client MAY 480 generate a random value of 128 bits. The octets are then base64- 481 encoded and placed in a element inside a SOAP header block in the following manner: 484 488 489 490 491 492 h1dqhs+aHxYjYNKiEwzjVg== 493 494 495 496 497 499 The derivation algorithm of TBD (IANA to assign: see IANA 500 considerations)\ signifies the client-generated approach described 501 above. 503 Applications that rely on this mechanism do so with the understanding 504 that it is not a secure approach, but merely for compatibility when 505 the risk is accepted. 507 5.1.2. Holder of Key Session Keys 509 In the event that a client is proving possession of a secret or 510 private key, the session key can be communicated in a manner that 511 proves its authenticity, or a formal key agreement algorithm may be 512 supported. For example, if the server has an elliptic curve public 513 key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11] 514 may be used. 516 If a key agreement or derivation process is not possible, then the 517 mechanism defined in the previous section can be used, with the added 518 benefit that the client's request will be strongly authenticated by a 519 key. However, if channel binding is not used, the generated key 520 SHOULD be wrapped or transported under the protection of a key 521 belonging to the server, such as an RSA public key. The element and associated key wrap and transport 523 algorithms (see [XMLENC11]) can be used for this purpose. 525 Note that this server no purpose in the bearer case, since if channel 526 binding is not used, an attacker can generate its own key, and if it 527 is used, there is no MITM to see the key. 529 5.2. Per-Message Tokens 531 The per-message tokens SHALL be the same as those for the Kerberos V 532 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections), using 533 the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962]. 535 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 536 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 537 (GSS_C_CONF_FLAG) security context flags are always set to TRUE. 539 The 128-bit session "protocol key" SHALL be a session key established 540 in a manner described in the previous section. "Specific keys" are 541 then derived as usual as described in Section 2 of [RFC4121], 542 [RFC3961], and [RFC3962]. 544 The terms "protocol key" and "specific key" are Kerberos V5 terms 545 [RFC3961]. 547 SAML20EC is PROT_READY as soon as the SAML response message has been 548 seen. 550 5.3. Pseudo-Random Function (PRF) 552 The GSS-API has been extended with a Pseudo-Random Function (PRF) 553 interface in [RFC4401]. The purpose is to enable applications to 554 derive a cryptographic key from an established GSS-API security 555 context. This section defines a GSS_Pseudo_random that is applicable 556 for the SAML20EC GSS-API mechanism. 558 The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the 559 Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor- 560 asserted sub-session key, thus GSS_C_PRF_KEY_FULL and 561 GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used 562 for the GSS_Pseudo_random() SHALL be the same as the key defined in 563 the previous section. 565 5.4. GSS-API Principal Name Types for SAML EC 567 Services that act as SAML relying parties are typically identified by 568 means of a URI called an "entityID". Clients that are named in the 569 element of a SAML assertion are typically identified by 570 means of a element, which is an extensible XML structure 571 containing, at minimum, an element value that names the subject and a 572 Format attribute. 574 In practice, a GSS-API client and server are unlikely to know the 575 name of the initiator as it will be expressed by the SAML identity 576 provider upon completion of authentication. It is also generally 577 incorrect to assume that a particular acceptor name will directly map 578 into a particular RP entityID, because there is often a layer of 579 naming indirection between particular services on hosts and the 580 identity of a relying party in SAML terms. 582 The SAML EC mechanism is compatible with the common/expected name 583 types used for acceptors and initiators, GSS_C_NT_HOSTBASED_SERVICE 584 and GSS_C_NT_USER_NAME. The mechanism provides for validation of the 585 host-based service name in conjunction with the SAML exchange. It 586 does not attempt to solve the problem of mapping between an initiator 587 "username", the user's identity while authenticating to the identity 588 provider, and the information supplied by the identity provider to 589 the acceptor. These relationships must be managed through local 590 policy at the initiator and acceptor. 592 5.4.1. Support for User Name Form 594 The GSS_C_NT_USER_NAME form represents the name of an individual 595 user. The client relies on this value to determine the appropriate 596 credentials to use in authenticating to the identity provider, and 597 supplies it to the server for use by the acceptor. 599 No SAML-specific mechanism name type is defined. SAML-based 600 information associated with the initiator SHOULD be expressed to the 601 acceptor using GSS-API naming extensions 602 [I-D.ietf-kitten-gssapi-naming-exts], in accordance with 604 [I-D.ietf-abfab-gss-eap-naming]. This information MUST be evaluated 605 by the mechanism at the server to determine whether to accept the 606 initiator name as a valid, authenticated name for the client. 607 Failure to establish this MUST result in failure of the mechanism. 609 5.4.2. Support for Host-Based Service Name Form 611 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 612 on a host; it is textually represented as "service@host". This name 613 form is required by most SASL profiles and is used by many existing 614 applications that use the Kerberos GSS-API mechanism. Such a name is 615 used directly by this mechanism as the effective 616 AssertionConsumerService of the server. 618 This value is used in the construction of the responseConsumerURL and 619 AssertionConsumerServiceURL attributes, and for eventual comparison 620 and validation by the client before completing the exchange. The 621 value MUST be securely associated with the SAML entityID claimed by 622 the server by the identity provider, such as through the use of SAML 623 metadata [OASIS.saml-metadata-2.0-os]. 625 6. Example 627 Suppose the user has an identity at the SAML IdP saml.example.org and 628 a Jabber Identifier (jid) "somenode@example.com", and wishes to 629 authenticate his XMPP connection to xmpp.example.com (and example.com 630 and example.org have established a SAML-capable trust relationship). 631 The authentication on the wire would then look something like the 632 following: 634 Step 1: Client initiates stream to server: 636 640 Step 2: Server responds with a stream tag sent to client: 642 646 Step 3: Server informs client of available authentication mechanisms: 648 649 650 DIGEST-MD5 651 PLAIN 652 SAML20EC 653 654 656 Step 4: Client selects an authentication mechanism and sends the 657 initial client response (it is base64 encoded as specified by the 658 XMPP SASL protocol profile): 660 661 biws 662 664 The initial response is "n,," which signals that channel binding is 665 not used, there is no authorization identity, and the client does not 666 support key-based confirmation. 668 Step 5: Server sends a challenge to client in the form of a SOAP 669 envelope containing its SAML : 671 672 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 673 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 674 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 675 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 676 bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 677 ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 678 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u 679 c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj 680 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg 681 ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB 682 TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h 683 cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k 684 PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft 685 bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 686 L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB 687 dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 688 ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n 689 PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz 690 c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N 691 CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 692 TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg 693 ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl 694 YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu 695 MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB 696 dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u 697 dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj 698 bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu 699 Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ 700 IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w 701 ZT4NCg== 702 704 The Base64 [RFC4648] decoded envelope: 706 710 711 716 720 https://xmpp.example.com 721 722 723 724 728 729 https://xmpp.example.com 730 731 733 734 735 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 736 737 738 739 740 742 Step 5 (alt): Server returns error to client: 744 745 746 747 749 Step 6: Client relays the request to IdP in a SOAP message 750 transmitted over HTTP (over TLS). HTTP portion not shown, use of 751 Basic Authentication is assumed. The body of the SOAP envelope is 752 exactly the same as received in the previous step. 754 758 759 760 761 762 763 765 Step 7: IdP responds to client with a SOAP response containing a SAML 766 containing a short-lived SSO assertion (shown as an 767 encrypted variant in the example). 769 773 774 777 778 779 782 https://saml.example.org 783 784 786 787 788 789 790 791 792 794 Step 8: Client sends SOAP envelope containing the SAML as 795 a response to the SASL server's challenge: 797 798 PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy 799 LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN 800 TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v 801 cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug 802 eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i 803 aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt 804 dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 805 L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 806 cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy 807 LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz 808 dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 809 ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s 810 cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 811 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg 812 ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg 813 ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk 814 QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu 815 dmVsb3BlPg0K 816 818 The Base64 [RFC4648] decoded envelope: 820 824 825 828 829 830 833 https://saml.example.org 834 835 837 838 839 840 841 842 843 845 Step 9: Server informs client of successful authentication: 847 849 Step 9 (alt): Server informs client of failed authentication: 851 852 853 854 856 Step 10: Client initiates a new stream to server: 858 861 Step 11: Server responds by sending a stream header to client along 862 with any additional features (or an empty features element): 864 867 868 869 870 872 Step 12: Client binds a resource: 874 875 876 someresource 877 878 880 Step 13: Server informs client of successful resource binding: 882 883 884 somenode@example.com/someresource 885 886 888 Please note: line breaks were added to the base64 for clarity. 890 7. Security Considerations 892 This section will address only security considerations associated 893 with the use of SAML with SASL applications. For considerations 894 relating to SAML in general, the reader is referred to the SAML 895 specification and to other literature. Similarly, for general SASL 896 Security Considerations, the reader is referred to that 897 specification. 899 Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds 900 optional support for channel binding and use of "Holder of Key" 901 subject confirmation. The former is strongly recommended for use 902 with this mechanism to detect "Man in the Middle" attacks between the 903 client and the RP without relying on flawed commercial TLS 904 infrastructure. The latter may be impractical in many cases, but is 905 a valuable way of strengthening client authentication, protecting 906 against phishing, and improving the overall mechanism. 908 7.1. Risks Left Unaddressed 910 The adaptation of a web-based profile that is largely designed around 911 security-oblivious clients and a bearer model for security token 912 validation results in a number of basic security exposures that 913 should be weighed against the compatibility and client simplification 914 benefits of this mechanism. 916 When channel binding is not used, protection against "Man in the 917 Middle" attacks is left to lower layer protocols such as TLS, and the 918 development of user interfaces able to implement that has not been 919 effectively demonstrated. Failure to detect a MITM can result in 920 phishing of the user's credentials if the attacker is between the 921 client and IdP, or the theft and misuse of a short-lived credential 922 (the SAML assertion) if the attacker is able to impersonate a RP. 923 SAML allows for source address checking as a minor mitigation to the 924 latter threat, but this is often impractical. IdPs can mitigate to 925 some extent the exposure of personal information to RP attackers by 926 encrypting assertions with authenticated keys. 928 7.2. User Privacy 930 The IdP is aware of each RP that a user logs into. There is nothing 931 in the protocol to hide this information from the IdP. It is not a 932 requirement to track the activity, but there is nothing technically 933 that prohibits the collection of this information. SASL servers 934 should be aware that SAML IdPs will track - to some extent - user 935 access to their services. 937 It is also out of scope of the mechanism to determine under what 938 conditions an IdP will release particular information to a relying 939 party, and it is generally unclear in what fashion user consent could 940 be established in real time for the release of particular 941 information. The SOAP exchange with the IdP does not preclude such 942 interaction, but neither does it define that interoperably. 944 7.3. Collusion between RPs 946 Depending on the information supplied by the IdP, it may be possible 947 for RPs to correlate data that they have collected. By using the 948 same identifier to log into every RP, collusion between RPs is 949 possible. SAML supports the notion of pairwise, or targeted/ 950 directed, identity. This allows the IdP to manage opaque, pairwise 951 identifiers for each user that are specific to each RP. However, 952 correlation is often possible based on other attributes supplied, and 953 is generally a topic that is beyond the scope of this mechanism. It 954 is sufficient to say that this mechanism does not introduce new 955 correlation opportunities over and above the use of SAML in web-based 956 use cases. 958 8. IANA Considerations 960 The IANA is requested to assign a new entry for this GSS mechanism in 961 the sub-registry for SMI Security for Mechanism Codes, whose prefix 962 is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 963 reference this specification in the registry. 965 The IANA is requested to register the following SASL profile: 967 SASL mechanism profiles: SAML20EC and SAML20EC-PLUS 969 Security Considerations: See this document 971 Published Specification: See this document 973 For further information: Contact the authors of this document. 975 Owner/Change controller: the IETF 977 Note: None 979 The IANA is requested to assign a URI to identify the key derivation 980 algorithm described in this document for client-generated session 981 keys. 983 9. References 985 9.1. Normative References 987 [OASIS.saml-bindings-2.0-os] 988 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 989 Maler, "Bindings for the OASIS Security Assertion Markup 990 Language (SAML) V2.0", OASIS 991 Standard saml-bindings-2.0-os, March 2005. 993 [OASIS.saml-core-2.0-os] 994 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 995 "Assertions and Protocol for the OASIS Security Assertion 996 Markup Language (SAML) V2.0", OASIS Standard saml-core- 997 2.0-os, March 2005. 999 [OASIS.saml-profiles-2.0-os] 1000 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1001 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1002 Security Assertion Markup Language (SAML) V2.0", OASIS 1003 Standard OASIS.saml-profiles-2.0-os, March 2005. 1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1006 Requirement Levels", BCP 14, RFC 2119, March 1997. 1008 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1009 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1010 Authentication: Basic and Digest Access Authentication", 1011 RFC 2617, June 1999. 1013 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1014 Security Layer (SASL)", RFC 4422, June 2006. 1016 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1017 "Generic Security Service Application Program Interface 1018 (GSS-API) Authentication and Key Exchange for the Secure 1019 Shell (SSH) Protocol", RFC 4462, May 2006. 1021 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1022 Encodings", RFC 4648, October 2006. 1024 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1025 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1027 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1028 Verification of Domain-Based Application Service Identity 1029 within Internet Public Key Infrastructure Using X.509 1030 (PKIX) Certificates in the Context of Transport Layer 1031 Security (TLS)", RFC 6125, March 2011. 1033 [SAMLECP20] 1034 Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile 1035 Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp- 1036 v2.0-wd05, July 2012. 1038 [W3C.soap11] 1039 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., 1040 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, 1041 "Simple Object Access Protocol (SOAP) 1.1", W3C 1042 Note soap11, May 2000, . 1044 [XMLENC11] 1045 Hirsch, F. and T. Roessler, "XML Encryption Syntax and 1046 Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- 1047 core-11-ed, July 2012. 1049 9.2. Normative References for GSS-API Implementers 1051 [I-D.ietf-abfab-gss-eap-naming] 1052 Hartman, S. and J. Howlett, "Name Attributes for the GSS- 1053 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-03 1054 (work in progress), July 2012. 1056 [I-D.ietf-kitten-gssapi-naming-exts] 1057 Williams, N., Johansson, L., Hartman, S., and S. 1058 Josefsson, "GSS-API Naming Extensions", 1059 draft-ietf-kitten-gssapi-naming-exts-15 (work in 1060 progress), May 2012. 1062 [RFC2743] Linn, J., "Generic Security Service Application Program 1063 Interface Version 2, Update 1", RFC 2743, January 2000. 1065 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1066 Kerberos 5", RFC 3961, February 2005. 1068 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1069 Encryption for Kerberos 5", RFC 3962, February 2005. 1071 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1072 Version 5 Generic Security Service Application Program 1073 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1074 July 2005. 1076 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1077 Extension for the Generic Security Service Application 1078 Program Interface (GSS-API)", RFC 4401, February 2006. 1080 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1081 Kerberos V Generic Security Service Application Program 1082 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1084 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1085 Service Application Program Interface (GSS-API) Mechanisms 1086 in Simple Authentication and Security Layer (SASL): The 1087 GS2 Mechanism Family", RFC 5801, July 2010. 1089 9.3. Informative References 1091 [OASIS.saml-metadata-2.0-os] 1092 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1093 "Metadata for the Security Assertion Markup Language 1094 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1095 March 2005. 1097 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1098 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1099 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1101 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1102 Protocol (XMPP): Core", RFC 3920, October 2004. 1104 Appendix A. Acknowledgments 1106 The authors would like to thank Klaas Wierenga, Sam Hartman, Nico 1107 Williams, and Jim Basney for their contributions. 1109 Appendix B. Changes 1111 This section to be removed prior to publication. 1113 o 02, major revision of GSS-API material and updated references 1115 o 01, SSH language added, noted non-assumption of HTTP error 1116 handling, added guidance on life of security context. 1118 o 00, Initial Revision, first WG-adopted draft. Removed support for 1119 unsolicited SAML responses. 1121 Authors' Addresses 1123 Scott Cantor 1124 Shibboleth Consortium 1125 2740 Airport Drive 1126 Columbus, Ohio 43219 1127 United States 1129 Phone: +1 614 247 6147 1130 Email: cantor.2@osu.edu 1132 Simon Josefsson 1133 SJD AB 1134 Hagagatan 24 1135 Stockholm 113 47 1136 SE 1138 Email: simon@josefsson.org 1139 URI: http://josefsson.org/