idnits 2.17.1 draft-ietf-kitten-sasl-saml-08.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 (January 11, 2012) is 4487 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: July 14, 2012 Cisco Systems GmbH 6 S. Josefsson 7 SJD AB 8 January 11, 2012 10 A SASL and GSS-API Mechanism for SAML 11 draft-ietf-kitten-sasl-saml-08.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 July 14, 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 . . . . . . . . . . 12 67 5. Channel Binding . . . . . . . . . . . . . . . . . . . . . . . 14 68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 72 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 24 73 7.2. Binding SAML subject identifiers to Authorization 74 Identities . . . . . . . . . . . . . . . . . . . . . . . . 24 75 7.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 76 7.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 24 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 78 8.1. IANA mech-profile . . . . . . . . . . . . . . . . . . . . 25 79 8.2. IANA OID . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 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 modular specification that provides 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 is to allow the interworking 116 between SASL and SAML in order to assert identity 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 3.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 is 129 available. 131 Figure 1 describes the interworking between SAML and SASL: this 132 document requires enhancements to the Relying Party (the SASL server) 133 and to the Client, as the two SASL communication end points, but no 134 changes to the SAML Identity Provider are necessary. To accomplish 135 this goal some indirect messaging is tunneled within SASL, and some 136 use of external methods is made. 138 +-----------+ 139 | | 140 >| Relying | 141 / | Party | 142 // | | 143 // +-----------+ 144 SAML/ // ^ 145 HTTPs // +--|--+ 146 // | S| | 147 / S | A| | 148 // A | M| | 149 // S | L| | 150 // L | | | 151 // | | | 152 | Client | 157 | Provider | | | 158 +------------+ +----------+ 160 Figure 1: Interworking Architecture 162 1.1. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 The reader is assumed to be familiar with the terms used in the SAML 169 2.0 specification [OASIS.saml-core-2.0-os]. 171 1.2. Applicability 173 Because this mechanism transports information that should not be 174 controlled by an attacker, the SAML mechanism MUST only be used over 175 channels protected by TLS, and the client MUST successfully validate 176 the server certificate, or over similar integrity protected and 177 authenticated channels. [RFC5280][RFC6125] 178 Note: An Intranet does not constitute such an integrity protected and 179 authenticated channel! 181 2. Authentication flow 183 While SAML itself is merely a markup language, its common use case 184 these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML 185 [W3C.REC-html401-19991224]. What follows is a typical flow: 187 1. The browser requests a resource of a Relying Party (RP) (via an 188 HTTP request). 190 2. The Relying Party redirects the browser via an HTTP redirect (as 191 described in Section 10.3 of [RFC2616]) to the Identity Provider 192 (IdP) or an IdP discovery service with as parameters an 193 authentication request that contains the name of resource being 194 requested, a browser cookie and a return URL as specified in 195 Section 3.1 of the SAML profiles 2.0 specification 196 [OASIS.saml-profiles-2.0-os]. 198 3. The user authenticates to the IdP and perhaps authorizes the 199 authentication to the Relying Party. 201 4. In its authentication response, the IdP redirects (via an HTTP 202 redirect) the browser back to the RP with an authentication 203 assertion (stating that the IdP vouches that the subject has 204 successfully authenticated), optionally along with some 205 additional attributes. 207 5. The Relying Party now has sufficient identity information to 208 approve access to the resource or not, and acts accordingly. The 209 authentication is concluded. 211 When considering this flow in the context of SASL, we note that while 212 the Relying Party and the client both must change their code to 213 implement this SASL mechanism, the IdP can remain untouched. The 214 Relying Party already has some sort of session (probably a TCP 215 connection) established with the client. However, it may be 216 necessary to redirect a SASL client to another application or 217 handler. The steps are as follows: 219 1. The SASL server (Relying Party) advertises support for the SASL 220 SAML20 mechanism to the client 222 2. The client initiates a SASL authentication with SAML20 and sends 223 a domain name that allows the SASL server to determine the 224 appropriate IdP 226 3. The SASL server transmits an authentication request encoded using 227 a Universal Resource Identifier (URI) as described in RFC 3986 228 [RFC3986] and an HTTP redirect to the IdP corresponding to the 229 domain 231 4. The SASL client now sends an empty response, as authentication 232 continues via the normal SAML flow. 234 5. At this point the SASL client MUST construct a URL containing the 235 content received in the previous message from the SASL server. 236 This URL is transmitted to the IdP either by the SASL client 237 application or an appropriate handler, such as a browser. 239 6. Next the client authenticates to the IdP. The manner in which 240 the end user is authenticated to the IdP and any policies 241 surrounding such authentication is out of scope for SAML and 242 hence for this draft. This step happens out of band from SASL. 244 7. The IdP will convey information about the success or failure of 245 the authentication back to the the SASL server (Relying Party) in 246 the form of an Authentication Statement or failure, using a 247 indirect response via the client browser or the handler (and with 248 an external browser client control should be passed back to the 249 SASL client). This step happens out of band from SASL. 251 8. The SASL Server sends an appropriate SASL response to the client, 252 along with an optional list of attributes 254 Please note: What is described here is the case in which the client 255 has not previously authenticated. It is possible that the client 256 already holds a valid SAML authentication token so that the user does 257 not need to be involved in the process anymore, but that would still 258 be external to SASL. This is classic Web Single Sign-On, in which 259 the Web Browser client presents the authentication token (cookie) to 260 the RP without renewed user authentication at the IdP. 262 With all of this in mind, the flow appears as follows in Figure 2: 264 SASL Serv. Client IdP 265 |>-----(1)----->| | Advertisement 266 | | | 267 |<-----(2)-----<| | Initiation 268 | | | 269 |>-----(3)----->| | Authentication Request 270 | | | 271 |<-----(4)-----<| | Empty Response 272 | | | 273 | |< - -(5,6) - ->| Client<>IDP 274 | | | Authentication (5,6) 275 | | | 276 |<- - - - - - - - - - -(7)- - -| Authentication Statement 277 | | | 278 |>-----(8)----->| | SASL completion with 279 | | | status 280 | | | 282 ----- = SASL 283 - - - = HTTP or HTTPs (external to SASL) 285 Figure 2: Authentication flow 287 3. SAML SASL Mechanism Specification 289 This section specifies the details of the SAML SASL mechanism. See 290 section 5 of [RFC4422] for what needs to be described here. 292 The name of this mechanism is "SAML20". The mechanism is capable of 293 transferring an authorization identity (via the "gs2-header"). The 294 mechanism does not offer a security layer. 296 The mechanism is client-first. The first mechanism message from the 297 client to the server is the "initial-response". As described in 298 [RFC4422], if the application protocol does not support sending a 299 client-response together with the authentication request, the server 300 will send an empty server-challenge to let the client begin. 302 The second mechanism message is from the server to the client, 303 containing the SAML "authentication-request". 305 The third mechanism message is from client to the server, and is the 306 fixed message consisting of "=". 308 The fourth mechanism message is from the server to the client, 309 indicating the SASL mechanism outcome. 311 3.1. Initial Response 313 A client initiates a "SAML20" authentication with SASL by sending the 314 GS2 header followed by the authentication identifier (message 2 in 315 Figure 2) and is defined as follows: 317 initial-response = gs2-header Idp-Identifier 318 IdP-Identifier = domain ; domain name with corresponding IdP 320 The "gs2-header" carries the optional authorization identity as 321 specified in [RFC5801], and it is used as follows: 323 - The "gs2-nonstd-flag" MUST NOT be present. 325 - See Section 5 for the channel binding "gs2-cb-flag" field. 327 - The "gs2-authzid" carries the optional authorization identity. 329 Domain name is specified in [RFC1035]. 331 3.2. Authentication Request 333 The SASL Server transmits to the SASL client a URI that redirects the 334 SAML client to the IdP (corresponding to the domain the user 335 provided), with a SAML authentication request as one of the 336 parameters (message 3 in Figure 2) in the following way: 338 authentication-request = URI 340 URI is specified in [RFC3986] and is encoded according to Section 3.4 341 (HTTP Redirect) of the SAML bindings 2.0 specification 342 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is 343 encoded according to Section 3.4 (Authentication Request) of the SAML 344 core 2.0 specification [OASIS.saml-core-2.0-os]. 346 Note: The SASL server may have a static mapping of domain to 347 corresponding IdP or alternatively a DNS-lookup mechanism could be 348 envisioned, but that is out-of-scope for this document. 350 Note: While the SASL client MAY sanity check the URI it received, 351 ultimately it is the SAML IdP that will be validated by the SAML 352 client which is out-of-scope for this document. 354 The client then sends the authentication request via an HTTP GET 355 (sent over a server-authenticated TLS channel) to the IdP, as if 356 redirected to do so from an HTTP server and in accordance with the 357 Web Browser SSO profile, as described in section 3.1 of SAML profiles 358 2.0 specification [OASIS.saml-profiles-2.0-os] (message 5 and 6 in 359 Figure 2). 361 The client handles both user authentication to the IdP and 362 confirmation or rejection of the authentiation of the RP (out-of- 363 scope for this document). 365 After all authentication has been completed by the IdP, the IdP will 366 send a redirect message to the client in the form of a URI 367 corresponding to the Relying Party as specified in the authentication 368 request ("AssertionConsumerServiceURL") and with the SAML response as 369 one of the parameters (message 7 in Figure 2). 371 Please note: this means that the SASL server needs to implement a 372 SAML Relying Party. Also, the SASL server needs to correlate the TCP 373 session from the SASL client with the SAML authentication by 374 comparing the ID of the SAML request with that in the response. 376 3.3. Outcome and parameters 378 The SASL server now validates the response it received from the 379 client via HTTP or HTTPS, as specified in the SAML specification 381 The response by the SASL server constitutes a SASL mechanism outcome, 382 and MUST be used to set state in the server accordingly, and it MUST 383 be used by the server to report that state to the SASL client as 384 described in [RFC4422] Section 3.6 (message 8 in Figure 2). 386 4. SAML GSS-API Mechanism Specification 388 This section, its sub-sections and appropriate references of it not 389 referenced elsewhere in this document, are not required for SASL 390 implementors, but this section MUST be observed to implement the GSS- 391 API mechanism discussed below. 393 The SAML SASL mechanism is actually also a GSS-API mechanism. The 394 SAML user takes the role of the GSS-API Initiator and the SAML 395 Relying Party takes the role of the GSS-API Acceptor. The SAML 396 Identity Provider does not have a role in GSS-API, and is considered 397 an internal matter for the SAML mechanism. The messages are the 398 same, but 400 a) the GS2 header on the client's first message and channel binding 401 data is excluded when SAML is used as a GSS-API mechanism, and 403 b) the RFC2743 section 3.1 initial context token header is prefixed 404 to the client's first authentication message (context token). 406 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see 407 IANA considerations). 409 SAML20 security contexts MUST have the mutual_state flag 410 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential 411 delegation, therefore SAML security contexts MUST have the 412 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 414 The mutual authentication property of this mechanism relies on 415 successfully comparing the TLS server identity with the negotiated 416 target name. Since the TLS channel is managed by the application 417 outside of the GSS-API mechanism, the mechanism itself is unable to 418 confirm the name while the application is able to perform this 419 comparison for the mechanism. For this reason, applications MUST 420 match the TLS server identity with the target name, as discussed in 421 [RFC6125]. 423 The SAML mechanism does not support per-message tokens or 424 GSS_Pseudo_random. 426 4.1. GSS-API Principal Name Types for SAML 428 SAML supports standard generic name syntaxes for acceptors such as 429 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML 430 supports only a single name type for initiators: GSS_C_NT_USER_NAME. 431 GSS_C_NT_USER_NAME is the default name type for SAML. The query, 432 display, and exported name syntaxes for SAML principal names are all 433 the same. There are no SAML-specific name syntaxes -- applications 434 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and 435 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported 436 name token does, of course, conform to [RFC2743], Section 3.2. 438 5. Channel Binding 440 The "gs2-cb-flag" MUST be set to "n" because channel binding data 441 cannot be integrity protected by the SAML negotiation. 443 Note: In theory channel binding data could be inserted in the SAML 444 flow by the client and verified by the server, but that is currently 445 not supported in SAML. 447 6. Examples 449 6.1. XMPP 451 Suppose the user has an identity at the SAML IdP saml.example.org and 452 a Jabber Identifier (JID) "somenode@example.com", and wishes to 453 authenticate his XMPP connection to xmpp.example.com. The 454 authentication on the wire would then look something like the 455 following: 457 Step 1: Client initiates stream to server: 459 463 Step 2: Server responds with a stream tag sent to client: 465 469 Step 3: Server informs client of available authentication mechanisms: 471 472 473 DIGEST-MD5 474 PLAIN 475 SAML20 476 477 479 Step 4: Client selects an authentication mechanism and provides the 480 initial client response containing the BASE64 [RFC4648] encoded gs2- 481 header and domain: 483 484 biwsZXhhbXBsZS5vcmc 486 The decoded string is: n,,example.org 487 Step 5: Server sends a BASE64 encoded challenge to client in the form 488 of an HTTP Redirect to the SAML IdP corresponding to example.org 489 (https://saml.example.org) with the SAML Authentication Request as 490 specified in the redirection url: 492 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 493 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 494 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 495 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 496 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 497 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 498 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 499 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 500 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 501 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 502 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 503 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 504 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 505 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 506 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 507 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 508 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 509 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 510 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 511 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 512 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 513 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 514 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 515 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 516 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 517 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 518 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 519 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 520 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 521 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 522 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 523 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 524 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 525 bGMzUSs= 527 The decoded challenge is: 529 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk 530 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl 531 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT 532 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC 533 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX 534 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 535 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 536 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV 537 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX 538 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn 539 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi 540 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 541 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 542 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX 543 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On 544 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG 545 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 546 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 547 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX 548 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC 549 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm 550 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 551 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ 552 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX 553 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4= 555 Where the decoded SAMLRequest looks like: 557 564 565 https://xmpp.example.com 566 567 570 573 575 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 576 577 578 580 Note: the server can use the request ID 581 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL 582 session with the SAML authentication. 584 Step 5 (alternative): Server returns error to client if no SAML 585 Authentication Request can be constructed: 587 588 589 590 592 Step 6: Client sends the empty response to the challenge encoded as a 593 single =: 595 596 = 597 599 [ The client now sends the URL to a browser instance for processing. 601 The browser engages in a normal SAML authentication flow (external to 602 SASL), like redirection to the Identity Provider 603 (https://saml.example.org), the user logs into 604 https://saml.example.org, and agrees to authenticate to 605 xmpp.example.com. A redirect is passed back to the client browser 606 who sends the AuthN response to the server, containing the subject- 607 identifier as an attribute. If the AuthN response doesn't contain 608 the JID, the server maps the subject-identifier received from the IdP 609 to a JID] 611 Step 7: Server informs client of successful authentication: 613 615 Step 7 (alt): Server informs client of failed authentication: 617 618 619 620 622 Step 8: Client initiates a new stream to server: 624 628 Step 9: Server responds by sending a stream header to client along 629 with any additional features (or an empty features element): 631 634 635 636 637 639 Step 10: Client binds a resource: 641 642 643 someresource 644 645 647 Step 11: Server informs client of successful resource binding: 649 650 651 somenode@example.com/someresource 652 653 655 Please note: line breaks were added to the base64 for clarity. 657 6.2. IMAP 659 The following describes an IMAP exchange. Lines beginning with 'S:' 660 indicate data sent by the server, and lines starting with 'C:' 661 indicate data sent by the client. Long lines are wrapped for 662 readability. 664 S: * OK IMAP4rev1 665 C: . CAPABILITY 666 S: * CAPABILITY IMAP4rev1 STARTTLS 667 S: . OK CAPABILITY Completed 668 C: . STARTTLS 669 S: . OK Begin TLS negotiation now 670 C: . CAPABILITY 671 S: * CAPABILITY IMAP4rev1 AUTH=SAML20 672 S: . OK CAPABILITY Completed 673 C: . AUTHENTICATE SAML20 674 S: + 675 C: biwsZXhhbXBsZS5vcmc 676 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 677 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 678 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 679 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 680 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 681 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 682 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 683 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 684 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 685 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 686 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 687 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 688 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 689 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 690 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 691 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 692 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 693 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 694 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 695 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 696 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 697 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 698 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 699 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 700 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 701 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 702 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 703 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 704 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 705 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 706 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 707 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 708 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 709 bGMzUSs= 710 C: 711 S: . OK Success (tls protection) 712 The decoded challenge is: 714 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk 715 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl 716 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT 717 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC 718 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX 719 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 720 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 721 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV 722 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX 723 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn 724 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi 725 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 726 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 727 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX 728 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On 729 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG 730 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 731 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 732 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX 733 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC 734 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm 735 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 736 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ 737 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX 738 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4= 740 Where the decoded SAMLRequest looks like: 742 749 750 https://xmpp.example.com 751 752 755 758 760 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 761 762 763 765 7. Security Considerations 767 This section addresses only security considerations associated with 768 the use of SAML with SASL applications. For considerations relating 769 to SAML in general, the reader is referred to the SAML specification 770 and to other literature. Similarly, for general SASL Security 771 Considerations, the reader is referred to that specification. 773 7.1. Man in the middle and Tunneling Attacks 775 This mechanism is vulnerable to man-in-the-middle and tunneling 776 attacks unless a client always verifies the server identity before 777 proceeding with authentication (see [RFC6125]). Typically TLS is 778 used to provide a secure channel with server authentication. 780 7.2. Binding SAML subject identifiers to Authorization Identities 782 As specified in [RFC4422], the server is responsible for binding 783 credentials to a specific authorization identity. It is therefore 784 necessary that only specific trusted IdPs be allowed. This is 785 typical part of SAML trust establishment between Relying Parties and 786 IdP. 788 7.3. User Privacy 790 The IdP is aware of each Relying Party that a user logs into. There 791 is nothing in the protocol to hide this information from the IdP. It 792 is not a requirement to track the visits, but there is nothing that 793 prohibits the collection of information. SASL server implementers 794 should be aware that SAML IdPs will be able to track - to some extent 795 - user access to their services. 797 7.4. Collusion between RPs 799 It is possible for Relying Parties to link data that they have 800 collected on the users. By using the same identifier to log into 801 every Relying Party, collusion between Relying Parties is possible. 802 In SAML, targeted identity was introduced. Targeted identity allows 803 the IdP to transform the identifier the user typed in to an opaque 804 identifier. This way the Relying Party would never see the actual 805 user identifier, but a randomly generated identifier. 807 8. IANA Considerations 809 8.1. IANA mech-profile 811 The IANA is requested to register the following SASL profile: 813 SASL mechanism profile: SAML20 815 Security Considerations: See this document 817 Published Specification: See this document 819 For further information: Contact the authors of this document. 821 Owner/Change controller: the IETF 823 Note: None 825 8.2. IANA OID 827 The IANA is further requested to assign an OID for this GSS mechanism 828 in the SMI numbers registry, with the prefix of 829 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 830 reference this specification in the registry. 832 9. References 834 9.1. Normative References 836 [OASIS.saml-bindings-2.0-os] 837 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 838 Maler, "Bindings for the OASIS Security Assertion Markup 839 Language (SAML) V2.0", OASIS 840 Standard saml-bindings-2.0-os, March 2005. 842 [OASIS.saml-core-2.0-os] 843 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 844 "Assertions and Protocol for the OASIS Security Assertion 845 Markup Language (SAML) V2.0", OASIS Standard saml-core- 846 2.0-os, March 2005. 848 [OASIS.saml-profiles-2.0-os] 849 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 850 P., Philpott, R., and E. Maler, "Profiles for the OASIS 851 Security Assertion Markup Language (SAML) V2.0", OASIS 852 Standard OASIS.saml-profiles-2.0-os, March 2005. 854 [RFC1035] Mockapetris, P., "Domain names - implementation and 855 specification", STD 13, RFC 1035, November 1987. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 861 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 862 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 864 [RFC2743] Linn, J., "Generic Security Service Application Program 865 Interface Version 2, Update 1", RFC 2743, January 2000. 867 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 869 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 870 Resource Identifier (URI): Generic Syntax", STD 66, 871 RFC 3986, January 2005. 873 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 874 Security Layer (SASL)", RFC 4422, June 2006. 876 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 877 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 879 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 880 Housley, R., and W. Polk, "Internet X.509 Public Key 881 Infrastructure Certificate and Certificate Revocation List 882 (CRL) Profile", RFC 5280, May 2008. 884 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 885 Service Application Program Interface (GSS-API) Mechanisms 886 in Simple Authentication and Security Layer (SASL): The 887 GS2 Mechanism Family", RFC 5801, July 2010. 889 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 890 Verification of Domain-Based Application Service Identity 891 within Internet Public Key Infrastructure Using X.509 892 (PKIX) Certificates in the Context of Transport Layer 893 Security (TLS)", RFC 6125, March 2011. 895 [W3C.REC-html401-19991224] 896 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 897 Specification", World Wide Web Consortium 898 Recommendation REC-html401-19991224, December 1999, 899 . 901 9.2. Informative References 903 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 904 STD 53, RFC 1939, May 1996. 906 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 907 4rev1", RFC 3501, March 2003. 909 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 910 Encodings", RFC 4648, October 2006. 912 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 913 Protocol (XMPP): Core", RFC 6120, March 2011. 915 Appendix A. Acknowledgments 917 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh 918 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank 919 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their 920 review and contributions. 922 Appendix B. Changes 924 This section to be removed prior to publication. 926 o 08 Fixed text per Gen-Art review 928 o 07 Fixed text per comments Alexey Melnikov 930 o 06 Fixed text per AD comments 932 o 05 Fixed references per ID-nits 934 o 04 Added request for IANA assignment, few text clarifications 936 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov 938 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos 940 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott 941 Cantor 943 o 01 Added authorization identity, added GSS-API specifics, added 944 client supplied IdP 946 o 00 Initial Revision. 948 Authors' Addresses 950 Klaas Wierenga 951 Cisco Systems, Inc. 952 Haarlerbergweg 13-19 953 Amsterdam, Noord-Holland 1101 CH 954 Netherlands 956 Phone: +31 20 357 1752 957 Email: klaas@cisco.com 959 Eliot Lear 960 Cisco Systems GmbH 961 Richtistrasse 7 962 Wallisellen, ZH CH-8304 963 Switzerland 965 Phone: +41 44 878 9200 966 Email: lear@cisco.com 968 Simon Josefsson 969 SJD AB 970 Hagagatan 24 971 Stockholm 113 47 972 SE 974 Email: simon@josefsson.org 975 URI: http://josefsson.org/