idnits 2.17.1 draft-ietf-kitten-sasl-saml-07.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 5, 2012) is 4489 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 8, 2012 Cisco Systems GmbH 6 S. Josefsson 7 SJD AB 8 January 5, 2012 10 A SASL and GSS-API Mechanism for SAML 11 draft-ietf-kitten-sasl-saml-07.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 8, 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 . . . . . . . . . . . . . . . . . . 9 64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 22 72 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 22 73 7.2. Binding SAML subject identifiers to Authorization 74 Identities . . . . . . . . . . . . . . . . . . . . . . . . 22 75 7.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 76 7.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 22 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 82 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 27 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 85 1. Introduction 87 Security Assertion Markup Language (SAML) 2.0 88 [OASIS.saml-core-2.0-os] is a modular specification that provides 89 various means for a user to be identified to a relying party (RP) 90 through the exchange of (typically signed) assertions issued by an 91 identity provider (IdP). It includes a number of protocols, protocol 92 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles 93 [OASIS.saml-profiles-2.0-os] designed for different use cases. 95 Simple Authentication and Security Layer (SASL) [RFC4422] is a 96 generalized mechanism for identifying and authenticating a user and 97 for optionally negotiating a security layer for subsequent protocol 98 interactions. SASL is used by application protocols like IMAP 99 [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make 100 modular authentication, so that newer authentication mechanisms can 101 be added as needed. This memo specifies just such a mechanism. 103 The Generic Security Service Application Program Interface (GSS-API) 104 [RFC2743] provides a framework for applications to support multiple 105 authentication mechanisms through a unified programming interface. 106 This document defines a pure SASL mechanism for SAML, but it conforms 107 to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. 108 This means that this document defines both a SASL mechanism and a 109 GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL 110 implementers, and the GSS-API considerations can be avoided in 111 environments that use SASL directly without GSS-API. 113 As currently envisioned, this mechanism is to allow the interworking 114 between SASL and SAML in order to assert identity and other 115 attributes to relying parties. As such, while servers (as relying 116 parties) will advertise SASL mechanisms (including SAML), clients 117 will select the SAML SASL mechanism as their SASL mechanism of 118 choice. 120 The SAML mechanism described in this memo aims to re-use the Web 121 Browser SSO profile defined in section 3.1 of the SAML profiles 2.0 122 specification [OASIS.saml-profiles-2.0-os] to the maximum extent and 123 therefore does not establish a separate authentication, integrity and 124 confidentiality mechanism. The mechanism assumes a security layer, 125 such as Transport Layer Security (TLS [RFC5246]), will continue to be 126 used. This specification is appropriate for use when a browser is 127 available. 129 Figure 1 describes the interworking between SAML and SASL: this 130 document requires enhancements to the Relying Party (the SASL server) 131 and to the Client, as the two SASL communication end points, but no 132 changes to the SAML Identity Provider are necessary. To accomplish 133 this goal some indirect messaging is tunneled within SASL, and some 134 use of external methods is made. 136 +-----------+ 137 | | 138 >| Relying | 139 / | Party | 140 // | | 141 // +-----------+ 142 SAML/ // ^ 143 HTTPs // +--|--+ 144 // | S| | 145 / S | A| | 146 // A | M| | 147 // S | L| | 148 // L | | | 149 // | | | 150 | Client | 155 | Provider | | | 156 +------------+ +----------+ 158 Figure 1: Interworking Architecture 160 1.1. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 The reader is assumed to be familiar with the terms used in the SAML 167 2.0 specification. 169 1.2. Applicability 171 Because this mechanism transports information that should not be 172 controlled by an attacker, the SAML mechanism MUST only be used over 173 channels protected by TLS, and the client MUST successfully validate 174 the server certificate, or similar integrity protected and 175 authenticated channels. [RFC5280][RFC6125] 176 Note: An Intranet does not constitute such an integrity protected and 177 authenticated channel! 179 2. Authentication flow 181 While SAML itself is merely a markup language, its common use case 182 these days is with HTTP [RFC2616] or HTTPs [RFC2818] and HTML 183 [W3C.REC-html401-19991224]. What follows is a typical flow: 185 1. The browser requests a resource of a Relying Party (RP) (via an 186 HTTP request). 188 2. The Relying Party redirects the browser via an HTTP redirect (as 189 described in Section 10.3 of [RFC2616]) to the Identity Provider 190 (IdP) or an IdP discovery service with as parameters an 191 authentication request that contains the name of resource being 192 requested, a browser cookie and a return URL as specified in 193 Section 3.1 of the SAML profiles 2.0 specification 194 [OASIS.saml-profiles-2.0-os]. 196 3. The user authenticates to the IdP and perhaps authorizes the 197 authentication to the service provider. 199 4. In its authentication response, the IdP redirects (via an HTTP 200 redirect) the browser back to the RP with an authentication 201 assertion (stating that the IdP vouches that the subject has 202 successfully authenticated), optionally along with some 203 additional attributes. 205 5. The Relying Party now has sufficient identity information to 206 approve access to the resource or not, and acts accordingly. The 207 authentication is concluded. 209 When considering this flow in the context of SASL, we note that while 210 the Relying Party and the client both must change their code to 211 implement this SASL mechanism, the IdP can remain untouched. The 212 Relying Party already has some sort of session (probably a TCP 213 connection) established with the client. However, it may be 214 necessary to redirect a SASL client to another application or 215 handler. This will be discussed below. The steps are shown from 216 below: 218 1. The SASL server (Relying Party) advertises support for the SASL 219 SAML20 mechanism to the client 221 2. The client initiates a SASL authentication with SAML20 and sends 222 a domain name that allows the SASL server to determine the 223 appropriate IdP 225 3. The SASL server transmits an authentication request encoded using 226 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: 264 SASL Serv. Client IdP 265 |>-----(1)----->| | Advertisement 266 | | | 267 |<-----(2)-----<| | Initiation 268 | | | 269 |>-----(3)----->| | Authentication Request 270 | | | 271 |<-----(4)-----<| | Empty Response 272 | | | 273 | |< - - - - - ->| Client<>IDP 274 | | | Authentication 275 | | | 276 |<- - - - - - - - - - - - - - -| Authentication Statement 277 | | | 278 |>-----(5)----->| | 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. 290 Recall section 5 of [RFC4422] for what needs to be described here. 292 The name of this mechanism "SAML20". The mechanism is capable of 293 transferring an authorization identity (via "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" described below. As 298 described in [RFC4422], if the application protocol does not support 299 sending a client-response together with the authentication request, 300 the server will send an empty server-challenge to let the client 301 begin. 303 The second mechanism message is from the server to the client, the 304 "authentication-request" described below. 306 The third mechanism message is from client to the server, and is the 307 fixed message consisting of "=". 309 The fourth mechanism message is from the server to the client, 310 indicating the SASL mechanism outcome described below. 312 3.1. Initial Response 314 A client initiates a "SAML20" authentication with SASL by sending the 315 GS2 header followed by the authentication identifier (message 2 in 316 Figure 2). The GS2 header carries the optional authorization 317 identity. 319 initial-response = gs2-header Idp-Identifier 320 IdP-Identifier = domain ; domain name with corresponding IdP 322 The "gs2-header" is specified in [RFC5801], and it is used as 323 follows. The "gs2-nonstd-flag" MUST NOT be present. Regarding the 324 channel binding "gs2-cb-flag" field, see Section 5. The "gs2- 325 authzid" carries the optional authorization identity. Domain name is 326 specified in [RFC1035]. 328 3.2. Authentication Request 330 The SASL Server transmits to the SASL client a URI that (re)directs 331 to the IdP (corresponding to the domain the user provided), with a 332 SAML authentication request as one of the parameters (message 3 in 333 Figure 2). 335 Note: The SASL server may have a static mapping of domain to 336 corresponding IdP or alternatively a DNS-lookup mechanism could be 337 envisioned, but that is out-of-scope for this document. 339 Note: While the SASL client MAY sanity check the URI it received, 340 ultimately it is the SAML IdP that will be validated by the SAML 341 client which is out-of-scope for this document. 343 authentication-request = URI 345 URI is specified in [RFC3986] and is encoded according to Section 3.4 346 (HTTP Redirect) of the SAML bindings 2.0 specification 347 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is 348 encoded according to Section 3.4 (Authentication Request) of the SAML 349 core 2.0 specification [OASIS.saml-core-2.0-os]. 351 The client now sends the authentication request via an HTTP GET (sent 352 over a server-authenticated TLS channel) to the IdP, as if redirected 353 to do so from an HTTP server and in accordance with the Web Browser 354 SSO profile, as described in section 3.1 of SAML profiles 2.0 355 specification [OASIS.saml-profiles-2.0-os] 357 The client handles both user authentication to the IdP and 358 confirmation or rejection of the authentiation of the RP (out-of- 359 scope for this document). 361 After all authentication has been completed by the IdP, the IdP will 362 send a redirect message to the client in the form of a URI 363 corresponding to the Relying Party as specified in the authentication 364 request ("AssertionConsumerServiceURL") and with the SAML response as 365 one of the parameters. 367 Please note: this means that the SASL server needs to implement a 368 SAML Relying Party. Also, the SASL server needs to correlate the TCP 369 session from the SASL client with the SAML authentication. 371 3.3. Outcome and parameters 373 The SASL server now validates the response it received from the 374 client via HTTP or HTTPS, as specified in the SAML specification 376 The response by the SASL server constitutes a SASL mechanism outcome, 377 and SHALL be used to set state in the server accordingly, and it 378 shall be used by the server to report that state to the SASL client 379 as described in [RFC4422] Section 3.6 (message 5 in Figure 2). 381 4. SAML GSS-API Mechanism Specification 383 This section and its sub-sections and appropriate references of it 384 not referenced elsewhere in this document are not required for SASL 385 implementors, but this section MUST be observed to implement the GSS- 386 API mechanism discussed below. 388 The SAML SASL mechanism is actually also a GSS-API mechanism. The 389 SAML user takes the role of the GSS-API Initiator and the SAML 390 Relying Party takes the role of the GSS-API Acceptor. The SAML 391 Identity Provider does not have a role in GSS-API, and is considered 392 an internal matter for the SAML mechanism.The messages are the same, 393 but 395 a) the GS2 header on the client's first message and channel binding 396 data is excluded when SAML is used as a GSS-API mechanism, and 398 b) the RFC2743 section 3.1 initial context token header is prefixed 399 to the client's first authentication message (context token). 401 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see 402 IANA considerations). 404 SAML20 security contexts MUST have the mutual_state flag 405 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential 406 delegation, therefore SAML security contexts MUST have the 407 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 409 The mutual authentication property of this mechanism relies on 410 successfully comparing the TLS server identity with the negotiated 411 target name. Since the TLS channel is managed by the application 412 outside of the GSS-API mechanism, the mechanism itself is unable to 413 confirm the name while the application is able to perform this 414 comparison for the mechanism. For this reason, applications MUST 415 match the TLS server identity with the target name, as discussed in 416 [RFC6125]. 418 The SAML mechanism does not support per-message tokens or 419 GSS_Pseudo_random. 421 4.1. GSS-API Principal Name Types for SAML 423 SAML supports standard generic name syntaxes for acceptors such as 424 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML 425 supports only a single name type for initiators: GSS_C_NT_USER_NAME. 426 GSS_C_NT_USER_NAME is the default name type for SAML. The query, 427 display, and exported name syntaxes for SAML principal names are all 428 the same. There are no SAML-specific name syntaxes -- applications 429 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and 430 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported 431 name token does, of course, conform to [RFC2743], Section 3.2. 433 5. Channel Binding 435 The "gs2-cb-flag" MUST use "n" because channel binding data cannot be 436 integrity protected by the SAML negotiation. 438 Note: In theory channel binding data could be inserted in the SAML 439 flow by the client and verified by the server, but that is currently 440 not supported in SAML. 442 6. Examples 444 6.1. XMPP 446 Suppose the user has an identity at the SAML IdP saml.example.org and 447 a Jabber Identifier (JID) "somenode@example.com", and wishes to 448 authenticate his XMPP connection to xmpp.example.com. The 449 authentication on the wire would then look something like the 450 following: 452 Step 1: Client initiates stream to server: 454 458 Step 2: Server responds with a stream tag sent to client: 460 464 Step 3: Server informs client of available authentication mechanisms: 466 467 468 DIGEST-MD5 469 PLAIN 470 SAML20 471 472 474 Step 4: Client selects an authentication mechanism and provides the 475 initial client response containing the BASE64 [RFC4648] encoded gs2- 476 header and domain: 478 479 biwsZXhhbXBsZS5vcmc 481 The decoded string is: n,,example.org 482 Step 5: Server sends a BASE64 encoded challenge to client in the form 483 of an HTTP Redirect to the SAML IdP corresponding to example.org 484 (https://saml.example.org) with the SAML Authentication Request as 485 specified in the redirection url: 487 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 488 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 489 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 490 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 491 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 492 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 493 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 494 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 495 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 496 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 497 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 498 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 499 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 500 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 501 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 502 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 503 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 504 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 505 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 506 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 507 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 508 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 509 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 510 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 511 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 512 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 513 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 514 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 515 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 516 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 517 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 518 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 519 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 520 bGMzUSs= 522 The decoded challenge is: 524 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk 525 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl 526 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT 527 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC 528 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX 529 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 530 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 531 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV 532 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX 533 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn 534 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi 535 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 536 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 537 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX 538 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On 539 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG 540 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 541 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 542 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX 543 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC 544 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm 545 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 546 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ 547 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX 548 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4= 550 Where the decoded SAMLRequest looks like: 552 559 560 https://xmpp.example.com 561 562 565 568 570 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 571 572 573 575 Note: the server can use the request ID 576 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL 577 session with the SAML authentication. 579 Step 5 (alt): Server returns error to client: 581 582 583 584 586 Step 6: Client sends the empty response to the challenge encoded as a 587 single =: 589 590 = 591 593 [ The client now sends the URL to a browser for processing. The 594 browser engages in a normal SAML authentication flow (external to 595 SASL), like redirection to the Identity Provider 596 (https://saml.example.org), the user logs into 597 https://saml.example.org, and agrees to authenticate to 598 xmpp.example.com. A redirect is passed back to the client browser 599 who sends the AuthN response to the server, containing the subject- 600 identifier as an attribute. If the AuthN response doesn't contain 601 the JID, the server maps the subject-identifier received from the IdP 602 to a JID] 604 Step 7: Server informs client of successful authentication: 606 608 Step 7 (alt): Server informs client of failed authentication: 610 611 612 613 615 Step 8: Client initiates a new stream to server: 617 621 Step 9: Server responds by sending a stream header to client along 622 with any additional features (or an empty features element): 624 627 628 629 630 632 Step 10: Client binds a resource: 634 635 636 someresource 637 638 640 Step 11: Server informs client of successful resource binding: 642 643 644 somenode@example.com/someresource 645 646 648 Please note: line breaks were added to the base64 for clarity. 650 6.2. IMAP 652 The following describes an IMAP exchange. Lines beginning with 'S:' 653 indicate data sent by the server, and lines starting with 'C:' 654 indicate data sent by the client. Long lines are wrapped for 655 readability. 657 S: * OK IMAP4rev1 658 C: . CAPABILITY 659 S: * CAPABILITY IMAP4rev1 STARTTLS 660 S: . OK CAPABILITY Completed 661 C: . STARTTLS 662 S: . OK Begin TLS negotiation now 663 C: . CAPABILITY 664 S: * CAPABILITY IMAP4rev1 AUTH=SAML20 665 S: . OK CAPABILITY Completed 666 C: . AUTHENTICATE SAML20 667 S: + 668 C: biwsZXhhbXBsZS5vcmc 669 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx 670 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz 671 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli 672 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U 673 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5 674 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5 675 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE 676 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy 677 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx 678 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56 679 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ 680 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY 681 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw 682 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6 683 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk 684 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz 685 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw 686 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3 687 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj 688 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u 689 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow 690 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5 691 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 692 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t 693 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB 694 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC 695 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj 696 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t 697 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN 698 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5 699 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 700 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX 701 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW 702 bGMzUSs= 703 C: 704 S: . OK Success (tls protection) 706 7. Security Considerations 708 This section will address only security considerations associated 709 with the use of SAML with SASL applications. For considerations 710 relating to SAML in general, the reader is referred to the SAML 711 specification and to other literature. Similarly, for general SASL 712 Security Considerations, the reader is referred to that 713 specification. 715 7.1. Man in the middle and Tunneling Attacks 717 This mechanism is vulnerable to man-in-the-middle and tunneling 718 attacks unless a client always verify the server identity before 719 proceeding with authentication (see [RFC6125]). Typically TLS is 720 used to provide a secure channel with server authentication. 722 7.2. Binding SAML subject identifiers to Authorization Identities 724 As specified in [RFC4422], the server is responsible for binding 725 credentials to a specific authorization identity. It is therefore 726 necessary that only specific trusted IdPs be allowed. This is 727 typical part of SAML trust establishment between Relying Parties and 728 IdP. 730 7.3. User Privacy 732 The IdP is aware of each Relying Party that a user logs into. There 733 is nothing in the protocol to hide this information from the IdP. It 734 is not a requirement to track the visits, but there is nothing that 735 prohibits the collection of information. SASL servers should be 736 aware that SAML IdPs will track - to some extent - user access to 737 their services. 739 7.4. Collusion between RPs 741 It is possible for Relying Parties to link data that they have 742 collected on you. By using the same identifier to log into every 743 Relying Party, collusion between Relying Parties is possible. In 744 SAML, targeted identity was introduced. Targeted identity allows the 745 IdP to transform the identifier the user typed in to an opaque 746 identifier. This way the Relying Party would never see the actual 747 user identifier, but a randomly generated identifier. This is an 748 option the user has to understand and decide to use if the IdP is 749 supporting it. 751 8. IANA Considerations 753 The IANA is requested to register the following SASL profile: 755 SASL mechanism profile: SAML20 757 Security Considerations: See this document 759 Published Specification: See this document 761 For further information: Contact the authors of this document. 763 Owner/Change controller: the IETF 765 Note: None 767 The IANA is further requested to assign an OID for this GSS mechanism 768 in the SMI numbers registry, with the prefix of 769 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 770 reference this specification in the registry. 772 9. References 774 9.1. Normative References 776 [OASIS.saml-bindings-2.0-os] 777 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 778 Maler, "Bindings for the OASIS Security Assertion Markup 779 Language (SAML) V2.0", OASIS 780 Standard saml-bindings-2.0-os, March 2005. 782 [OASIS.saml-core-2.0-os] 783 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 784 "Assertions and Protocol for the OASIS Security Assertion 785 Markup Language (SAML) V2.0", OASIS Standard saml-core- 786 2.0-os, March 2005. 788 [OASIS.saml-profiles-2.0-os] 789 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 790 P., Philpott, R., and E. Maler, "Profiles for the OASIS 791 Security Assertion Markup Language (SAML) V2.0", OASIS 792 Standard OASIS.saml-profiles-2.0-os, March 2005. 794 [RFC1035] Mockapetris, P., "Domain names - implementation and 795 specification", STD 13, RFC 1035, November 1987. 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 801 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 802 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 804 [RFC2743] Linn, J., "Generic Security Service Application Program 805 Interface Version 2, Update 1", RFC 2743, January 2000. 807 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 809 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 810 Resource Identifier (URI): Generic Syntax", STD 66, 811 RFC 3986, January 2005. 813 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 814 Security Layer (SASL)", RFC 4422, June 2006. 816 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 817 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 819 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 820 Housley, R., and W. Polk, "Internet X.509 Public Key 821 Infrastructure Certificate and Certificate Revocation List 822 (CRL) Profile", RFC 5280, May 2008. 824 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 825 Service Application Program Interface (GSS-API) Mechanisms 826 in Simple Authentication and Security Layer (SASL): The 827 GS2 Mechanism Family", RFC 5801, July 2010. 829 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 830 Verification of Domain-Based Application Service Identity 831 within Internet Public Key Infrastructure Using X.509 832 (PKIX) Certificates in the Context of Transport Layer 833 Security (TLS)", RFC 6125, March 2011. 835 [W3C.REC-html401-19991224] 836 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 837 Specification", World Wide Web Consortium 838 Recommendation REC-html401-19991224, December 1999, 839 . 841 9.2. Informative References 843 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 844 STD 53, RFC 1939, May 1996. 846 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 847 4rev1", RFC 3501, March 2003. 849 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 850 Encodings", RFC 4648, October 2006. 852 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 853 Protocol (XMPP): Core", RFC 6120, March 2011. 855 Appendix A. Acknowledgments 857 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh 858 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank 859 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their 860 review and contributions. 862 Appendix B. Changes 864 This section to be removed prior to publication. 866 o 07 Fixed text per comments Alexey Melnikov 868 o 06 Fixed text per AD comments 870 o 05 Fixed references per ID-nits 872 o 04 Added request for IANA assignment, few text clarifications 874 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov 876 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos 878 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott 879 Cantor 881 o 01 Added authorization identity, added GSS-API specifics, added 882 client supplied IdP 884 o 00 Initial Revision. 886 Authors' Addresses 888 Klaas Wierenga 889 Cisco Systems, Inc. 890 Haarlerbergweg 13-19 891 Amsterdam, Noord-Holland 1101 CH 892 Netherlands 894 Phone: +31 20 357 1752 895 Email: klaas@cisco.com 897 Eliot Lear 898 Cisco Systems GmbH 899 Richtistrasse 7 900 Wallisellen, ZH CH-8304 901 Switzerland 903 Phone: +41 44 878 9200 904 Email: lear@cisco.com 906 Simon Josefsson 907 SJD AB 908 Hagagatan 24 909 Stockholm 113 47 910 SE 912 Email: simon@josefsson.org 913 URI: http://josefsson.org/