idnits 2.17.1 draft-ietf-kitten-sasl-saml-09.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 (February 20, 2012) is 4442 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Wierenga 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track E. Lear 5 Expires: August 23, 2012 Cisco Systems GmbH 6 S. Josefsson 7 SJD AB 8 February 20, 2012 10 A SASL and GSS-API Mechanism for SAML 11 draft-ietf-kitten-sasl-saml-09.txt 13 Abstract 15 Security Assertion Markup Language (SAML) has found its usage on the 16 Internet for Web Single Sign-On. Simple Authentication and Security 17 Layer (SASL) and the Generic Security Service Application Program 18 Interface (GSS-API) are application frameworks to generalize 19 authentication. This memo specifies a SASL mechanism and a GSS-API 20 mechanism for SAML 2.0 that allows the integration of existing SAML 21 Identity Providers with applications using SASL and GSS-API. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 23, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Authentication flow . . . . . . . . . . . . . . . . . . . . . 6 61 3. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 62 3.1. Initial Response . . . . . . . . . . . . . . . . . . . . . 9 63 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 10 64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 11 65 4. SAML GSS-API Mechanism Specification . . . . . . . . . . . . . 12 66 4.1. GSS-API Principal Name Types for SAML . . . . . . . . . . 13 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 71 6.1. Man in the middle and Tunneling Attacks . . . . . . . . . 22 72 6.2. Binding SAML subject identifiers to Authorization 73 Identities . . . . . . . . . . . . . . . . . . . . . . . . 22 74 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 75 6.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 22 76 6.5. GSS-API specific security considerations . . . . . . . . . 22 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 7.1. IANA mech-profile . . . . . . . . . . . . . . . . . . . . 24 79 7.2. IANA OID . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 84 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 29 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 87 1. Introduction 89 Security Assertion Markup Language (SAML) 2.0 90 [OASIS.saml-core-2.0-os] is a set of specifications that provide 91 various means for a user to be identified to a relying party (RP) 92 through the exchange of (typically signed) assertions issued by an 93 identity provider (IdP). It includes a number of protocols, protocol 94 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 95 [OASIS.saml-profiles-2.0-os] designed for different use cases. 97 Simple Authentication and Security Layer (SASL) [RFC4422] is a 98 generalized mechanism for identifying and authenticating a user and 99 for optionally negotiating a security layer for subsequent protocol 100 interactions. SASL is used by application protocols like IMAP 101 [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make 102 modular authentication, so that newer authentication mechanisms can 103 be added as needed. This memo specifies just such a mechanism. 105 The Generic Security Service Application Program Interface (GSS-API) 106 [RFC2743] provides a framework for applications to support multiple 107 authentication mechanisms through a unified programming interface. 108 This document defines a pure SASL mechanism for SAML, but it conforms 109 to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. 110 This means that this document defines both a SASL mechanism and a 111 GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL 112 implementers, and the GSS-API considerations can be avoided in 113 environments that use SASL directly without GSS-API. 115 As currently envisioned, this mechanism enables interworking between 116 SASL and SAML in order to assert the identity of the user and other 117 attributes to relying parties. As such, while servers (as relying 118 parties) will advertise SASL mechanisms (including SAML), clients 119 will select the SAML SASL mechanism as their SASL mechanism of 120 choice. 122 The SAML mechanism described in this memo aims to re-use the Web 123 Browser SSO profile defined in section 4.1 of the SAML profiles 2.0 124 specification [OASIS.saml-profiles-2.0-os] to the maximum extent and 125 therefore does not establish a separate authentication, integrity and 126 confidentiality mechanism. The mechanism assumes a security layer, 127 such as Transport Layer Security (TLS [RFC5246]), will continue to be 128 used. This specification is appropriate for use when a browser 129 instance is available. In the absence of a browser instance, SAML 130 profiles that don't require a browser such as the Enhanced Client or 131 Proxy profile (as defined in section 4.2 of the SAML profiles 2.0 132 specification [OASIS.saml-profiles-2.0-os] may be used, but that is 133 outside the scope of this specification. 135 Figure 1 describes the interworking between SAML and SASL: this 136 document requires enhancements to the Relying Party (the SASL server) 137 and to the Client, as the two SASL communication end points, but no 138 changes to the SAML Identity Provider are necessary. To accomplish 139 this goal some indirect messaging is tunneled within SASL, and some 140 use of external methods is made. 142 +-----------+ 143 | | 144 >| Relying | 145 / | Party | 146 // | | 147 // +-----------+ 148 SAML/ // ^ 149 HTTPS // +--|--+ 150 // | S| | 151 / S | A| | 152 // A | M| | 153 // S | L| | 154 // L | | | 155 // | | | 156 | Client | 161 | Provider | | | 162 +------------+ +----------+ 164 Figure 1: Interworking Architecture 166 1.1. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 The reader is assumed to be familiar with the terms used in the SAML 173 2.0 specification [OASIS.saml-core-2.0-os]. 175 1.2. Applicability 177 Because this mechanism transports information that should not be 178 controlled by an attacker, the SAML mechanism MUST only be used over 179 channels protected by TLS, or over similar integrity protected and 180 authenticated channels. In addition, when TLS is used the client 181 MUST successfully validate the server certificate ([RFC5280], 182 [RFC6125]) 184 Note: An Intranet does not constitute such an integrity protected and 185 authenticated channel! 187 2. Authentication flow 189 While SAML itself is merely a markup language, its common use case 190 these days is with HTTP [RFC2616] or HTTPS [RFC2818] and HTML 191 [W3C.REC-html401-19991224]. What follows is a typical flow: 193 1. The browser requests a resource of a Relying Party (RP) (via an 194 HTTP request). 196 2. The Relying Party redirects the browser via an HTTP redirect (as 197 described in Section 10.3 of [RFC2616]) to the Identity Provider 198 (IdP) or an IdP discovery service. When it does so, it includes 199 the following parameters: (1) an authentication request that 200 contains the name of resource being requested, (2) a browser 201 cookie, and (3) a return URL as specified in Section 3.1 of the 202 SAML profiles 2.0 specification [OASIS.saml-profiles-2.0-os]. 204 3. The user authenticates to the IdP and perhaps authorizes the 205 release of user attributes to the Relying Party. 207 4. In its authentication response, the IdP redirects (via an HTTP 208 redirect) the browser back to the RP with an authentication 209 assertion (stating that the IdP vouches that the subject has 210 successfully authenticated), optionally along with some 211 additional attributes. 213 5. The Relying Party now has sufficient identity information to 214 approve access to the resource or not, and acts accordingly. The 215 authentication is concluded. 217 When considering this flow in the context of SASL, we note that while 218 the Relying Party and the client both must change their code to 219 implement this SASL mechanism, the IdP can remain untouched. The 220 Relying Party already has some sort of session (probably a TCP 221 connection) established with the client. However, it may be 222 necessary to redirect a SASL client to another application or 223 handler. The steps are as follows: 225 1. The SASL server (Relying Party) advertises support for the SASL 226 SAML20 mechanism to the client 228 2. The client initiates a SASL authentication with SAML20 and sends 229 a domain name that allows the SASL server to determine the 230 appropriate IdP 232 3. The SASL server transmits an authentication request encoded using 233 a Uniform Resource Identifier (URI) as described in RFC 3986 234 [RFC3986] and an HTTP redirect to the IdP corresponding to the 235 domain 237 4. The SASL client now sends an empty response, as authentication 238 continues via the normal SAML flow and the SASL server will 239 receive the answer to the challenge out-of-band from the SASL 240 conversation. 242 5. At this point the SASL client MUST construct a URL containing the 243 content received in the previous message from the SASL server. 244 This URL is transmitted to the IdP either by the SASL client 245 application or an appropriate handler, such as a browser. 247 6. Next the user authenticates to the IdP. The manner in which the 248 end user is authenticated to the IdP and any policies surrounding 249 such authentication is out of scope for SAML and hence for this 250 draft. This step happens out of band from SASL. 252 7. The IdP will convey information about the success or failure of 253 the authentication back to the the SASL server (Relying Party) in 254 the form of an Authentication Statement or failure, using a 255 indirect response via the client browser or the handler (and with 256 an external browser client control should be passed back to the 257 SASL client). This step happens out of band from SASL. 259 8. The SASL Server sends an appropriate SASL response to the client, 260 along with an optional list of attributes 262 Please note: What is described here is the case in which the client 263 has not previously authenticated. It is possible that the client 264 already holds a valid SAML authentication token so that the user does 265 not need to be involved in the process anymore, but that would still 266 be external to SASL. This is classic Web Single Sign-On, in which 267 the Web Browser client presents the authentication token (cookie) to 268 the RP without renewed user authentication at the IdP. 270 With all of this in mind, the flow appears as follows in Figure 2: 272 SASL Serv. Client IdP 273 |>-----(1)----->| | Advertisement 274 | | | 275 |<-----(2)-----<| | Initiation 276 | | | 277 |>-----(3)----->| | Authentication Request 278 | | | 279 |<-----(4)-----<| | Empty Response 280 | | | 281 | |< - -(5,6) - ->| Client<>IDP 282 | | | Authentication 283 | | | 284 |<- - - - - - - - - - -(7)- - -| Authentication Statement 285 | | | 286 |>-----(8)----->| | SASL completion with 287 | | | status 288 | | | 290 ----- = SASL 291 - - - = HTTP or HTTPS (external to SASL) 293 Figure 2: Authentication flow 295 3. SAML SASL Mechanism Specification 297 This section specifies the details of the SAML SASL mechanism. See 298 section 5 of [RFC4422] for what is described here. 300 The name of this mechanism is "SAML20". The mechanism is capable of 301 transferring an authorization identity (via the "gs2-header"). The 302 mechanism does not offer a security layer. 304 The mechanism is client-first. The first mechanism message from the 305 client to the server is the "initial-response". As described in 306 [RFC4422], if the application protocol does not support sending a 307 client-response together with the authentication request, the server 308 will send an empty server-challenge to let the client begin. The 309 second mechanism message is from the server to the client, containing 310 the SAML "authentication-request". The third mechanism message is 311 from client to the server, and is the fixed message consisting of "=" 312 (i.e., an empty response). The fourth mechanism message is from the 313 server to the client, indicating the SASL mechanism outcome. 315 3.1. Initial Response 317 A client initiates a "SAML20" authentication with SASL by sending the 318 GS2 header followed by the authentication identifier (message 2 in 319 Figure 2) and is defined as follows: 321 initial-response = gs2-header Idp-Identifier 322 IdP-Identifier = domain ; domain name with corresponding IdP 324 The "gs2-header" is used as follows: 326 - The "gs2-nonstd-flag" MUST NOT be present. 328 - The "gs2-cb-flag" MUST be set to "n" because channel binding 329 [RFC5056] data cannot be integrity protected by the SAML 330 negotiation. (Note: In theory channel binding data could be 331 inserted in the SAML flow by the client and verified by the 332 server, but that is currently not supported in SAML.) 334 - The "gs2-authzid" carries the optional authorization identity as 335 specified in [RFC5801] (not to be confused with the IdP- 336 Identifier). 338 Domain name is specified in [RFC1035]. A domain name is either a 339 "traditional domain name" as described in [RFC1035] or an 340 "internationalized domain name" as described in [RFC5890]. Clients 341 and servers MUST treat the IdP-Identifier as a domain name slot 342 [RFC5890]. They also SHOULD support internationalized domain names 343 (IDNs) in the Idp-Identifier field; if they do so, all of the domain 344 name's labels MUST be A-labels or NR-LDH labels [RFC5890], if 345 necessary internationalized labels MUST be converted from U-labels to 346 A-labels by using the Punycode encoding [RFC3492] for A-labels prior 347 to sending them to the SASL-server as described in the protocol 348 specification for Internationalized Domain Names in Applications 349 [RFC5891]. 351 3.2. Authentication Request 353 The SASL Server transmits to the SASL client a URI that redirects the 354 SAML client to the IdP (corresponding to the domain that the user 355 provided), with a SAML authentication request as one of the 356 parameters (message 3 in Figure 2) in the following way: 358 authentication-request = URI 360 URI is specified in [RFC3986] and is encoded according to Section 3.4 361 (HTTP Redirect) of the SAML bindings 2.0 specification 362 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is 363 encoded according to Section 3.4 (Authentication Request) of the SAML 364 core 2.0 specification [OASIS.saml-core-2.0-os]. Should the client 365 support Internationalized Resource Identifiers (IRIs) [RFC3987] it 366 MUST first convert the IRI to a URI before transmitting it to the 367 server [RFC5890]. 369 Note: The SASL server may have a static mapping of domain to 370 corresponding IdP or alternatively a DNS-lookup mechanism could be 371 envisioned, but that is out-of-scope for this document. 373 Note: While the SASL client MAY sanity check the URI it received, 374 ultimately it is the SAML IdP that will be validated by the SAML 375 client which is out-of-scope for this document. 377 The client then sends the authentication request via an HTTP GET 378 (sent over a server-authenticated TLS channel) to the IdP, as if 379 redirected to do so from an HTTP server and in accordance with the 380 Web Browser SSO profile, as described in section 3.1 of SAML profiles 381 2.0 specification [OASIS.saml-profiles-2.0-os] (message 5 and 6 in 382 Figure 2). 384 The client handles both user authentication to the IdP and 385 confirmation or rejection of the authentiation of the RP (out-of- 386 scope for this document). 388 After all authentication has been completed by the IdP, the IdP will 389 send a redirect message to the client in the form of a URI 390 corresponding to the Relying Party as specified in the authentication 391 request ("AssertionConsumerServiceURL") and with the SAML response as 392 one of the parameters (message 7 in Figure 2). 394 Please note: this means that the SASL server needs to implement a 395 SAML Relying Party. Also, the SASL server needs to correlate the 396 session it has with the SASL client with the appropriate SAML 397 authentication result. It can do so by comparing the ID of the SAML 398 authentication request it has issued with the one it receives in the 399 SAML authentication statement. 401 3.3. Outcome and parameters 403 The SASL server (in its capacity as a SAML Relying Party) now 404 validates the SAML authentication response it received from the SAML 405 client via HTTP or HTTPS. 407 The outcome of that validation by the SASL server constitutes a SASL 408 mechanism outcome, and therefore (as stated in [RFC4422]) SHALL be 409 used to set state in the server accordingly, and it SHALL be used by 410 the server to report that state to the SASL client as described in 411 [RFC4422] Section 3.6 (message 8 in Figure 2). 413 4. SAML GSS-API Mechanism Specification 415 This section and its sub-sections are not required for SASL 416 implementors, but this section MUST be observed to implement the GSS- 417 API mechanism discussed below. 419 This section specify a GSS-API mechanism that when used via the GS2 420 bridge to SASL behaves like the SASL mechanism defined in this 421 document. Thus, it can loosely be said that the SAML SASL mechanism 422 is also a GSS-API mechanism. The SAML user takes the role of the 423 GSS-API Initiator and the SAML Relying Party takes the role of the 424 GSS-API Acceptor. The SAML Identity Provider does not have a role in 425 GSS-API, and is considered an internal matter for the SAML mechanism. 426 The messages are the same, but 428 a) the GS2 header on the client's first message and channel binding 429 data is excluded when SAML is used as a GSS-API mechanism, and 431 b) the RFC2743 section 3.1 initial context token header is prefixed 432 to the client's first authentication message (context token). 434 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see 435 IANA considerations). 437 SAML20 security contexts MUST have the mutual_state flag 438 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential 439 delegation, therefore SAML security contexts MUST have the 440 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 442 The mutual authentication property of this mechanism relies on 443 successfully comparing the TLS server identity with the negotiated 444 target name. Since the TLS channel is managed by the application 445 outside of the GSS-API mechanism, the mechanism itself is unable to 446 confirm the name while the application is able to perform this 447 comparison for the mechanism. For this reason, applications MUST 448 match the TLS server identity with the target name, as discussed in 449 [RFC6125]. More precisely, to pass identity validation the client 450 uses the securely negotiated targ_name as the reference identifier 451 and match it to the DNS-ID of the server certificate, and MUST reject 452 the connection if there is a mismatch. For compatibility with 453 deployed certificate hierarchies, the client MAY also perform a 454 comparison with the CN-ID when there is no DNS-ID present. Wildcard 455 matching is permitted. The targ_name reference identifier is a 456 "traditional domain names" thus the comparison is made using case- 457 insensitive ASCII comparison. 459 The SAML mechanism does not support per-message tokens or 460 GSS_Pseudo_random. 462 4.1. GSS-API Principal Name Types for SAML 464 SAML supports standard generic name syntaxes for acceptors such as 465 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML 466 supports only a single name type for initiators: GSS_C_NT_USER_NAME. 467 GSS_C_NT_USER_NAME is the default name type for SAML. The query, 468 display, and exported name syntaxes for SAML principal names are all 469 the same. There are no SAML-specific name syntaxes -- applications 470 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and 471 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported 472 name token does, of course, conforms to [RFC2743], Section 3.2. 474 5. Examples 476 5.1. XMPP 478 Suppose the user has an identity at the SAML IdP saml.example.org and 479 a Jabber Identifier (JID) "somenode@example.com", and wishes to 480 authenticate his XMPP connection to xmpp.example.com. The 481 authentication on the wire would then look something like the 482 following: 484 Step 1: Client initiates stream to server: 486 490 Step 2: Server responds with a stream tag sent to client: 492 496 Step 3: Server informs client of available authentication mechanisms: 498 499 500 DIGEST-MD5 501 PLAIN 502 SAML20 503 504 506 Step 4: Client selects an authentication mechanism and provides the 507 initial client response containing the according to the definition in 508 Section 4 ofBASE64 [RFC4648] encoded gs2-header and domain: 510 511 biwsZXhhbXBsZS5vcmc 513 The decoded string is: n,,example.org 514 Step 5: Server sends a BASE64 encoded challenge to client in the form 515 of an HTTP Redirect to the SAML IdP corresponding to example.org 516 (https://saml.example.org) with the SAML Authentication Request as 517 specified in the redirection url: 519 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 520 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 521 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 522 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 523 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 524 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 525 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 526 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 527 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 528 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 529 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 530 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 531 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 532 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 533 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 534 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 535 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 536 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 537 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 538 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 539 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 540 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 541 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 542 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 543 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 544 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 545 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 546 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 547 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 548 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 549 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 550 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 551 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 552 bGMzUSs= 554 The decoded challenge is: 556 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk 557 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl 558 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT 559 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC 560 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX 561 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 562 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 563 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV 564 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX 565 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn 566 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi 567 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 568 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 569 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX 570 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On 571 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG 572 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 573 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 574 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX 575 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC 576 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm 577 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 578 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ 579 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX 580 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4= 582 Where the decoded SAMLRequest looks like: 584 591 592 https://xmpp.example.com 593 594 597 600 602 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 603 604 605 607 Note: the server can use the request ID 608 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL 609 session with the SAML authentication. 611 Step 5 (alternative): Server returns error to client if no SAML 612 Authentication Request can be constructed: 614 615 616 617 619 Step 6: Client sends the empty response to the challenge encoded as a 620 single =: 622 623 = 624 626 The following steps between brackets are out of scope for this 627 document but included to better illustrate the entire flow. 629 [The client now sends the URL to a browser instance for processing. 630 The browser engages in a normal SAML authentication flow (external to 631 SASL), like redirection to the Identity Provider 632 (https://saml.example.org), the user logs into 633 https://saml.example.org, and agrees to authenticate to 634 xmpp.example.com. A redirect is passed back to the client browser 635 who sends the AuthN response to the server, containing the subject- 636 identifier as an attribute. If the AuthN response doesn't contain 637 the JID, the server maps the subject-identifier received from the IdP 638 to a JID] 640 Step 7: Server informs client of successful authentication: 642 644 Step 7 (alt): Server informs client of failed authentication: 646 647 648 649 651 Please note: line breaks were added to the base64 for clarity. 653 5.2. IMAP 655 The following describes an IMAP exchange. Lines beginning with 'S:' 656 indicate data sent by the server, and lines starting with 'C:' 657 indicate data sent by the client. Long lines are wrapped for 658 readability. 660 S: * OK IMAP4rev1 661 C: . CAPABILITY 662 S: * CAPABILITY IMAP4rev1 STARTTLS 663 S: . OK CAPABILITY Completed 664 C: . STARTTLS 665 S: . OK Begin TLS negotiation now 666 C: . CAPABILITY 667 S: * CAPABILITY IMAP4rev1 AUTH=SAML20 668 S: . OK CAPABILITY Completed 669 C: . AUTHENTICATE SAML20 670 S: + 671 C: biwsZXhhbXBsZS5vcmc 672 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1M 673 UmVxdWVzdD1QSE5oYld4d09rRg0KMWRHaHVVbVZ4ZFdWemRDQjRiV3h1Y3pwe 674 llXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQg0KVFV3Nk1pNH 675 dPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lFbEVQU0pmWW1Wak5ESTBabUUxTVRBek5 676 ESTRPVEE1WQ0KVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQlda 677 WEp6YVc5dVBTSXlMakFpRFFvZ0lDQWdTWA0KTnpkV1ZKYm5OMFlXNTBQU0l5T 678 URBM0xURXlMVEV3VkRFeE9qTTVPak0wV2lJZ1JtOXlZMlZCZFhSb2JqMA0KaV 679 ptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpTSU5DaUFnSUN 680 CUWNtOTBiMk52YkVKcA0KYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6 681 cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVg0KRlJRTFZCUFUxUWlEU 682 W9nSUNBZ1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRME 683 tJQw0KQWdJQ0FnSUNBaWFIUjBjSE02THk5dFlXbHNMbVY0WVcxd2JHVXVZMjl 684 0TDFOQlRVd3ZRWE56WlhKMGFXOQ0KdVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0 685 TkNpQThjMkZ0YkRwSmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaQ0KZFhKdU9tO 686 WhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3T21GemMyVnlkR2x2YmlJK0 687 RRb2dJQ0FnSQ0KR2gwZEhCek9pOHZlRzF3Y0M1bGVHRnRjR3hsTG1OdmJRMEt 688 JRHd2YzJGdGJEcEpjM04xWlhJK0RRb2dQSA0KTmhiV3h3T2s1aGJXVkpSRkJ2 689 YkdsamVTQjRiV3h1Y3pwellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVg0Ke 690 k9uUmpPbE5CVFV3Nk1pNHdPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lDQkdiM0p0WV 691 hROUluVnlianB2WVhOcA0KY3pwdVlXMWxjenAwWXpwVFFVMU1Pakl1TURwdVl 692 XMWxhV1F0Wm05eWJXRjBPbkJsY25OcGMzUmxiblFpRA0KUW9nSUNBZ0lGTlFU 693 bUZ0WlZGMVlXeHBabWxsY2owaWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXe 694 HNiMw0KZERjbVZoZEdVOUluUnlkV1VpSUM4K0RRb2dQSE5oYld4d09sSmxjWF 695 ZsYzNSbFpFRjFkR2h1UTI5dWRHVg0KNGRBMEtJQ0FnSUNCNGJXeHVjenB6WVc 696 xc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09u 697 QnliM1J2WTI5c0lpQU5DaUFnSUNBZ0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoa 698 FkzUWlQZzBLSQ0KQ0E4YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGemMxSm 699 xaZzBLSUNBZ0lDQWdlRzFzYm5NNmMyRnRiRA0KMGlkWEp1T205aGMybHpPbTV 700 oYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJWeWRHbHZiaUkrRFFvZ0lDQQ0K 701 Z0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVERveUxqQTZZV002W 702 TJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6Y0c5eW 703 RBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUQ0KMnhoYzNOU1pXWSt 704 EUW9nUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lB 705 MEtQQw0KOXpZVzFzY0RwQmRYUm9ibEpsY1hWbGMzUSs= 706 C: 707 S: . OK Success (tls protection) 708 The decoded challenge is: 710 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF 711 1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB 712 TUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5Y 713 TMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSX 714 NzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdXRobj0 715 iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2NvbEJp 716 bmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIV 717 FRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPQ0KIC 718 AgICAgICAiaHR0cHM6Ly9tYWlsLmV4YW1wbGUuY29tL1NBTUwvQXNzZXJ0aW9 719 uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0i 720 dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICAgI 721 Gh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3N1ZXI+DQogPH 722 NhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWV 723 zOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYXQ9InVybjpvYXNp 724 czpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiD 725 QogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcGxlLmNvbSIgQWxsb3 726 dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV 727 4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6 728 Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvbj0iZXhhY3QiPg0KI 729 CA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KICAgICAgeG1sbnM6c2FtbD 730 0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICA 731 gICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNz 732 d29yZFByb3RlY3RlZFRyYW5zcG9ydA0KICA8L3NhbWw6QXV0aG5Db250ZXh0Q 733 2xhc3NSZWY+DQogPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+IA0KPC 734 9zYW1scDpBdXRoblJlcXVlc3Q+ 736 Where the decoded SAMLRequest looks like: 738 745 746 https://xmpp.example.com 747 748 751 754 756 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 757 758 759 761 6. Security Considerations 763 This section addresses only security considerations associated with 764 the use of SAML with SASL applications. For considerations relating 765 to SAML in general, the reader is referred to the SAML specification 766 and to other literature. Similarly, for general SASL Security 767 Considerations, the reader is referred to that specification. 769 6.1. Man in the middle and Tunneling Attacks 771 This mechanism is vulnerable to man-in-the-middle and tunneling 772 attacks unless a client always verifies the server identity before 773 proceeding with authentication (see [RFC6125]). Typically TLS is 774 used to provide a secure channel with server authentication. 776 6.2. Binding SAML subject identifiers to Authorization Identities 778 As specified in [RFC4422], the server is responsible for binding 779 credentials to a specific authorization identity. It is therefore 780 necessary that only specific trusted IdPs be allowed. This is 781 typical part of SAML trust establishment between Relying Parties and 782 IdP. 784 6.3. User Privacy 786 The IdP is aware of each Relying Party that a user logs into. There 787 is nothing in the protocol to hide this information from the IdP. It 788 is not a requirement to track the visits, but there is nothing that 789 prohibits the collection of information. SASL server implementers 790 should be aware that SAML IdPs will be able to track - to some extent 791 - user access to their services. 793 6.4. Collusion between RPs 795 It is possible for Relying Parties to link data that they have 796 collected on the users. By using the same identifier to log into 797 every Relying Party, collusion between Relying Parties is possible. 798 In SAML, targeted identity was introduced. Targeted identity allows 799 the IdP to transform the identifier the user typed in to a Relying 800 Party specific opaque identifier. This way the Relying Party would 801 never see the actual user identifier, but a randomly generated 802 identifier. 804 6.5. GSS-API specific security considerations 806 Security issues inherent in GSS-API (RFC 2743) and GS2 (RFC 5801) 807 apply to the SAML GSS-API mechanism defined in this document. 808 Further, and as discussed in section 4, proper TLS server identity 809 verification is critical to the security of the mechanism. 811 7. IANA Considerations 813 7.1. IANA mech-profile 815 The IANA is requested to register the following SASL profile: 817 SASL mechanism profile: SAML20 819 Security Considerations: See this document 821 Published Specification: See this document 823 For further information: Contact the authors of this document. 825 Owner/Change controller: the IETF 827 Intended usage: COMMON 829 Note: None 831 7.2. IANA OID 833 The IANA is further requested to assign a new entry for this GSS 834 mechanism in the sub-registry for SMI Security for Mechanism Codes, 835 whose prefix is iso.org.dod.internet.security.mechanisms 836 (1.3.6.1.5.5) and to reference this specification in the registry. 838 8. References 840 8.1. Normative References 842 [OASIS.saml-bindings-2.0-os] 843 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 844 Maler, "Bindings for the OASIS Security Assertion Markup 845 Language (SAML) V2.0", OASIS 846 Standard saml-bindings-2.0-os, March 2005. 848 [OASIS.saml-core-2.0-os] 849 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 850 "Assertions and Protocol for the OASIS Security Assertion 851 Markup Language (SAML) V2.0", OASIS Standard saml-core- 852 2.0-os, March 2005. 854 [OASIS.saml-profiles-2.0-os] 855 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 856 P., Philpott, R., and E. Maler, "Profiles for the OASIS 857 Security Assertion Markup Language (SAML) V2.0", OASIS 858 Standard OASIS.saml-profiles-2.0-os, March 2005. 860 [RFC1035] Mockapetris, P., "Domain names - implementation and 861 specification", STD 13, RFC 1035, November 1987. 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, March 1997. 866 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 867 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 868 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 870 [RFC2743] Linn, J., "Generic Security Service Application Program 871 Interface Version 2, Update 1", RFC 2743, January 2000. 873 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 875 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 876 for Internationalized Domain Names in Applications 877 (IDNA)", RFC 3492, March 2003. 879 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 880 Resource Identifier (URI): Generic Syntax", STD 66, 881 RFC 3986, January 2005. 883 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 884 Identifiers (IRIs)", RFC 3987, January 2005. 886 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 887 Security Layer (SASL)", RFC 4422, June 2006. 889 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 890 Channels", RFC 5056, November 2007. 892 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 893 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 895 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 896 Housley, R., and W. Polk, "Internet X.509 Public Key 897 Infrastructure Certificate and Certificate Revocation List 898 (CRL) Profile", RFC 5280, May 2008. 900 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 901 Service Application Program Interface (GSS-API) Mechanisms 902 in Simple Authentication and Security Layer (SASL): The 903 GS2 Mechanism Family", RFC 5801, July 2010. 905 [RFC5890] Klensin, J., "Internationalized Domain Names for 906 Applications (IDNA): Definitions and Document Framework", 907 RFC 5890, August 2010. 909 [RFC5891] Klensin, J., "Internationalized Domain Names in 910 Applications (IDNA): Protocol", RFC 5891, August 2010. 912 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 913 Verification of Domain-Based Application Service Identity 914 within Internet Public Key Infrastructure Using X.509 915 (PKIX) Certificates in the Context of Transport Layer 916 Security (TLS)", RFC 6125, March 2011. 918 [W3C.REC-html401-19991224] 919 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 920 Specification", World Wide Web Consortium 921 Recommendation REC-html401-19991224, December 1999, 922 . 924 8.2. Informative References 926 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 927 STD 53, RFC 1939, May 1996. 929 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 930 4rev1", RFC 3501, March 2003. 932 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 933 Encodings", RFC 4648, October 2006. 935 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 936 Protocol (XMPP): Core", RFC 6120, March 2011. 938 Appendix A. Acknowledgments 940 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh 941 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank 942 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their 943 review and contributions. 945 Appendix B. Changes 947 This section to be removed prior to publication. 949 o 09 Fixed text per IESG review 951 o 08 Fixed text per Gen-Art review 953 o 07 Fixed text per comments Alexey Melnikov 955 o 06 Fixed text per AD comments 957 o 05 Fixed references per ID-nits 959 o 04 Added request for IANA assignment, few text clarifications 961 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov 963 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos 965 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott 966 Cantor 968 o 01 Added authorization identity, added GSS-API specifics, added 969 client supplied IdP 971 o 00 Initial Revision. 973 Authors' Addresses 975 Klaas Wierenga 976 Cisco Systems, Inc. 977 Haarlerbergweg 13-19 978 Amsterdam, Noord-Holland 1101 CH 979 Netherlands 981 Phone: +31 20 357 1752 982 Email: klaas@cisco.com 984 Eliot Lear 985 Cisco Systems GmbH 986 Richtistrasse 7 987 Wallisellen, ZH CH-8304 988 Switzerland 990 Phone: +41 44 878 9200 991 Email: lear@cisco.com 993 Simon Josefsson 994 SJD AB 995 Hagagatan 24 996 Stockholm 113 47 997 SE 999 Email: simon@josefsson.org 1000 URI: http://josefsson.org/