idnits 2.17.1 draft-ietf-kitten-sasl-openid-04.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 (July 11, 2011) is 4667 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** 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) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 12, 2012 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 S. Josefsson 9 SJD AB 10 July 11, 2011 12 A SASL & GSS-API Mechanism for OpenID 13 draft-ietf-kitten-sasl-openid-04 15 Abstract 17 OpenID has found its usage on the Internet for Web Single Sign-On. 18 Simple Authentication and Security Layer (SASL) and the Generic 19 Security Service Application Program Interface (GSS-API) are 20 application frameworks to generalize authentication. This memo 21 specifies a SASL and GSS-API mechanism for OpenID that allows the 22 integration of existing OpenID Identity Providers with applications 23 using SASL and GSS-API. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 12, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 63 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8 64 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 66 3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 11 68 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 69 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 70 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 13 71 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 13 72 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 18 75 6.2. RP redirected by malicious URL to take an improper 76 action . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 18 78 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 19 79 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 19 80 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 20 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 86 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 OpenID [OpenID] is a web-based three-party protocol that provides a 92 means for a user to offer identity assertions and other attributes to 93 a web server (Relying Party) via the help of an identity provider. 94 The purpose of this system is to provide a way to verify that an end 95 user controls an identifier. 97 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 98 used by application protocols such IMAP [RFC3501], POP [RFC1939] and 99 XMPP [RFC3920], with the goal of modularizing authentication and 100 security layers, so that newer mechanisms can be added as needed. 101 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 interface. This document 106 defines a pure SASL mechanism for OpenID, but it conforms to the new 107 bridge between SASL and the GSS-API called GS2 [RFC5801]. This means 108 that this document defines both a SASL mechanism and a GSS-API 109 mechanism. We want to point out that the GSS-API interface is 110 optional for SASL implementers, and the GSS-API considerations can be 111 avoided in environments that uses SASL directly without GSS-API. 113 As currently envisioned, this mechanism is to allow the interworking 114 between SASL and OpenID in order to assert identity and other 115 attributes to relying parties. As such, while servers (as relying 116 parties) will advertise SASL mechanisms, clients will select the 117 OpenID mechanism. 119 The OpenID mechanism described in this memo aims to re-use the OpenID 120 mechanism to the maximum extent and therefore does not establish a 121 separate authentication, integrity and confidentiality mechanism. It 122 is anticipated that existing security layers, such as Transport Layer 123 Security (TLS) [RFC5246], will continued to be used. This 124 specification is appropriate for use when a browser is available. 126 Figure 1 describes the interworking between OpenID and SASL. This 127 document requires enhancements to the Relying Party and to the Client 128 (as the two SASL communication end points) but no changes to the 129 OpenID Provider (OP) are necessary. To accomplish this goal indirect 130 messaging required by the OpenID specification is tunneled through 131 the SASL/GSS-API mechanism. 133 +-----------+ 134 | | 135 >| Relying | 136 / | Party | 137 // | | 138 // +-----------+ 139 // ^ 140 OpenID // +--|--+ 141 // | O| | G 142 / S | p| | S 143 // A | e| | S 144 // S | n| | A 145 // L | I| | P 146 // | D| | I 147 | Client | 152 | | | | 153 +------------+ +----------+ 155 Figure 1: Interworking Architecture 157 1.1. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 The reader is assumed to be familiar with the terms used in the 164 OpenID 2.0 specification. 166 1.2. Applicability 168 Because this mechanism transports information that should not be 169 controlled by an attacker, the OpenID mechanism MUST only be used 170 over channels protected by TLS, and the client MUST successfully 171 validate the server certificate, or similar integrity protected and 172 authenticated channels. [RFC5280][RFC6125] 174 2. Applicability for non-HTTP Use Cases 176 OpenID was originally envisioned for HTTP [RFC2616] and HTML 177 [W3C.REC-html401-19991224] based communications, and with the 178 associated semantic, the idea being that the user would be redirected 179 by the Relying Party to an identity provider who authenticates the 180 user, and then sends identity information and other attributes 181 (either directly or indirectly) to the Relying Party. The identity 182 provider in the OpenID specifications is referred to as an OpenID 183 Provider (OP). The actual protocol flow, as copied from the OpenID 184 2.0 specification, is as follows: 186 1. The end user initiates authentication by presenting a User- 187 Supplied Identifier to the Relying Party via their User-Agent 188 (e.g., http://user.example.com). 190 2. After normalizing the User-Supplied Identifier as described in 191 Section 7.2 of [OpenID], the Relying Party performs discovery on 192 it and establishes the OP Endpoint URL that the end user uses for 193 authentication. It should be noted that the User-Supplied 194 Identifier may be an OP Identifier, which allows selection of a 195 Claimed Identifier at the OP or for the protocol to proceed 196 without a Claimed Identifier if something else useful is being 197 done via an extension. 199 3. The Relying Party and the OP optionally establish an association 200 -- a shared secret established using Diffie-Hellman Key Exchange. 201 The OP uses an association to sign subsequent messages and the 202 Relying Party to verify those messages; this removes the need for 203 subsequent direct requests to verify the signature after each 204 authentication request/response. This process is desccribed in 205 Section 8 of [OpenID]. 207 4. The Relying Party redirects the end user's User-Agent to the OP 208 with an OpenID Authentication request. This occurs as stated in 209 Section 10.3 of [RFC2616]. 211 5. The OP authenticates the end user and establishes whether the end 212 user will authenticate to, and share specific attributes with, 213 the Relying Party. For instance, the OP often asks the user what 214 to do. The manner in which the end user authenticates to their 215 OP and any policies surrounding such authentication is out of 216 scope of OpenID. 218 6. The OP redirects the end user's User-Agent back to the Relying 219 Party with either an assertion that authentication is approved or 220 a message that authentication failed. 222 7. The Relying Party verifies the information received from the OP 223 including checking the Return URL, verifying the discovered 224 information, checking the nonce, and verifying the signature by 225 using either the shared key established during the association or 226 by sending a direct request to the OP. 228 When considering this flow in the context of SASL, we note that while 229 the RP and the client both must change their code to implement this 230 SASL mechanism, it is a design constraint that the OP behavior remain 231 untouched, in order for implementations to interoperate with existing 232 IdPs. Hence, an analog flow that interfaces the three parties needs 233 to be created. In the analog, we note that unlike a web server, the 234 SASL server already has some sort of session (probably a TCP 235 connection) established with the client. However, it may be 236 necessary to redirect a SASL client to another application. This 237 will be discussed below. By doing so, we externalize much of the 238 authentiction from SASL. 240 The steps are shown from below: 242 1. The Relying Party or SASL server advertises support for the SASL 243 OpenID mechanism to the client. 245 2. The client initiates a SASL authentication and transmits the 246 User-Supplied Identifier as its first response. The SASL 247 mechanism is client-first, and as explained in [RFC4422] the 248 server will send an empty challenge if needed. 250 3. After normalizing the User-Supplied Identifier as discussed in 251 [OpenID], the Relying Party performs discovery on it and 252 establishes the OP Endpoint URL that the end user uses for 253 authentication. 255 4. The Relying Party and the OP optionally establish an association 256 -- a shared secret established using Diffie-Hellman Key 257 Exchange. The OP uses an association to sign subsequent 258 messages and the Relying Party to verify those messages; this 259 removes the need for subsequent direct requests to verify the 260 signature after each authentication request/response. 262 5. The Relying Party transmits an authentication request to the OP 263 to obtain an assertion in the form of an indirect request. 264 These messages are passed through the client rather than 265 directly between the RP and the OP. OpenID defines two methods 266 for indirect communication, namely HTTP redirects and HTML form 267 submission. Both mechanisms are not directly applicable for 268 usage with SASL. To ensure that a standard OpenID 2.0 capable 269 OP can be used a new method is defined in this document that 270 requires the OpenID message content to be encoded using a 271 Universal Resource Idenitifier (URI). [RFC3986] 273 6. The SASL client now sends an response consisting of "=", to 274 indicate that authentication continues via the normal OpenID 275 flow. 277 7. At this point the client application MUST construct a URL 278 containing the content received in the previous message from the 279 RP. This URL is transmitted to the OP either by the SASL client 280 application or an appropriate handler, such as a browser. 282 8. Next the client optionally authenticates to the OP and then 283 approves or disapproves authentication to the Relying Party. 284 The manner in which the end user is authenticated to their 285 respective OP and any policies surrounding such authentication 286 is out of scope of OpenID and and hence also out of scope for 287 this specification. This step happens out of band from SASL. 289 9. The OP will convey information about the success or failure of 290 the authentication phase back to the RP, again using an indirect 291 response via the client browser or handler. The client 292 transmits over HTTP the redirect of the OP result to the RP. 293 This step happens out of band from SASL. 295 10. The RP MAY send an OpenID check_authentication request directly 296 to the OP, if no association has been established, and the OP 297 should be expected to respond. Again this step happens out of 298 band from SASL. 300 11. The SASL server sends an appropriate SASL response to the 301 client, with optional Open Simple Registry (SREG) attributes. 303 SASL Serv. Client OP 304 |>-----(1)----->| | Advertisement 305 | | | 306 |<-----(2)-----<| | Initiation 307 | | | 308 |> - - (3) - - - - - - - - - ->| Discovery 309 | | 310 |>- - -(4)- - - - - - - - - - >| Association 311 |<- - -(4)- - - - - - - - - - <| 312 | | | 313 |>-----(5)----->| | Indirect Auth Request 314 | | | 315 |<-----(6)-----<| | Client "=" Response 316 | | | 317 | |>- - (7)- - ->| Client GET to the OP (ext) 318 | | | 319 | |<- - (8)- - ->| Client / OP Auth. (ext.) 320 | | | 321 |<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res 322 | | | 323 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 324 | | | 325 |>-----(11)---->| | SASL completion with status 327 ----- = SASL 328 - - - = HTTP or HTTPS 330 Note the directionality in SASL is such that the client MUST send the 331 "=" response. Specifically, it processes the redirect and then 332 awaits a final SASL decision, while the rest of the OpenID 333 authentication process continues. 335 2.1. Binding SASL to OpenID in the Relying Party 337 To ensure that a specific request is bound, and in particular to ease 338 interprocess communication, it may be necessary for the relying party 339 to encode some sort of nonce in the URIs it transmits through the 340 client for success or failure. This can be done in any number of 341 ways. Examples would include making changes to the base URI or 342 otherwise including an additional fragment. 344 2.2. Discussion 346 As mentioned above OpenID is primarily designed to interact with web- 347 based applications. Portions of the authentication stream are only 348 defined in the crudest sense. That is, when one is prompted to 349 approve or disapprove an authentication, anything that one might find 350 on a browser is allowed, including JavaScript, fancy style-sheets, 351 etc. Because of this lack of structure, implementations will need to 352 invoke a fairly rich browser in order to insure that the 353 authentication can be completed. 355 Once there is an outcome, the SASL server needs to know about it. 356 The astute will hopefully by now have noticed an "=" client SASL 357 response. This is not to say that nothing is happening, but rather 358 that authentication flow has shifted from SASL to OpenID, and will 359 return when the server has an outcome to hand to the client. The 360 alternative to this flow is some signal from the HTML browser to the 361 SASL client of the results that is in turn passed to the SASL server. 362 The IPC issue this raises is substantial. Better, we conclude, to 363 externalize the authentication to the browser, and have an "=" client 364 response. 366 OpenID is also meant to be used in serial within the web. As such, 367 there are no transaction-ids within the protocol. A transaction id, 368 can be included by the RP by appending it to the return_to URL. 370 3. OpenID SASL Mechanism Specification 372 This section specifies the details of the OpenID SASL mechanism. 373 Recall section 5 of [RFC4422] for what needs to be described here. 375 The name of this mechanism "OPENID20". The mechanism is capable of 376 transferring an authorization identity (via "gs2-header"). The 377 mechanism does not offer a security layer. 379 The mechanism is client-first. The first mechanism message from the 380 client to the server is the "initial-response" described below. As 381 described in [RFC4422], if the application protocol does not support 382 sending a client-response together with the authentication request, 383 the server will send an empty server-challenge to let the client 384 begin. 386 The second mechanism message is from the server to the client, the 387 "authentication_request" described below. 389 The third mechanism message is from client to the server, and is the 390 fixed message consisting of "=". 392 The fourth mechanism message is from the server to the client, 393 described below as "outcome_data" (with SREG attributes), sent as 394 additional data when indicating a successful outcome. 396 3.1. Initiation 398 A client initiates an OpenID authentication with SASL by sending the 399 GS2 header followed by the XRI or URI, as specified in the OpenID 400 specification. The GS2 header carries the optional authorization 401 identity. 403 initial-response = gs2-header Auth-Identifier 404 Auth-Identifier = Identifier ; authentication identifier 405 Identifier = URI / XRI ; Identifier is specified in 406 ; Sec. 7.2 of the OpenID 2.0 spec. 408 The "gs2-header" is specified in [RFC5801], and it is used as 409 follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- 410 flag" MUST be "n" because channel binding is not supported by this 411 mechanism. The "gs2-authzid" carries the optional authorization 412 identity. 414 The XRI syntax is defined in [XRI2.0]. URI is specified in 415 [RFC3986]. 417 3.2. Authentication Request 419 The SASL Server sends the URL resulting from the OpenID 420 authentication request, containing an "openid.mode" of either 421 "checkid_immediate" or "checkid_setup", as specified in Section 9.1 422 of the OpenID 2.0 specification. 424 authentication-request = URI 426 As part of this request, the SASL server MUST append a unique 427 transaction id to the "return_to" portion of the request. The form 428 of this transaction is left to the RP to decide, but SHOULD be large 429 enough to be resistant to being guessed or attacked. 431 The client now sends that request via an HTTP GET to the OP, as if 432 redirected to do so from an HTTP server. 434 The client MUST handle both user authentication to the OP and 435 confirmation or rejection of the authentiation of the RP. 437 After all authentication has been completed by the OP, and after the 438 response has been sent to the client, the client will relay the 439 response to the Relying Party via HTTP(S), as specified previously in 440 the transaction ("return_to"). 442 3.3. Server Response 444 The Relying Party now validates the response it received from the 445 client via HTTP or HTTPS, as specified in the OpenID specification, 446 using the "return_to" URI given previsiously in the transaction. 448 The response by the Relying Party constitutes a SASL mechanism 449 outcome, and SHALL be used to set state in the server accordingly, 450 and it shall be used by the server to report that state to the SASL 451 client as described in [RFC4422] Section 3.6. In the additional 452 data, the server MAY include OpenID Simple Registry (SREG) attributes 453 that are listed in Section 4 of [SREG1.0]. They are encoded as 454 follows: 456 1. Strip "openid.sreg." from each attribute name. 458 2. Treat the concatentation of results as URI parameters that are 459 separated by an ambersand (&) and encode as one would a URI, 460 absent the scheme, authority, and the question mark. 462 For example: email=lear@example.com&fullname=Eliot%20Lear 464 More formally: 466 outcome-data = [ sreg-avp *( "," sreg-avp ) ] 467 sreg-avp = sreg-attr "=" sreg-val 468 sreg-attr = sreg-word 469 sreg-val = sreg-word 470 sreg-word = 1*( unreserved / pct-encoded ) 471 ; pct-encoded from Section 2.1 of RFC 3986 472 ; unreserved from Section 2.3 of RFC 3986 474 In the case of failures, the response MUST follow this syntax: 476 outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp ) 478 3.4. Error Handling 480 [RFC4422] Section 3.6 explicitly prohibits additional information in 481 an unsuccessful authentication outcome. Therefore, the openid.error 482 and openid.error_code are to be sent as an additional challenge in 483 the event of an unsuccessful outcome. In this case, as the protocol 484 is lock step, the client will follow with an additional exchange 485 containing "=", after which the server will respond with an 486 application-level outcome. 488 4. OpenID GSS-API Mechanism Specification 490 This section and its sub-sections and all normative references of it 491 not referenced elsewhere in this document are INFORMATIONAL for SASL 492 implementors, but they are NORMATIVE for GSS-API implementors. 494 The OpenID SASL mechanism is actually also a GSS-API mechanism. The 495 OpenID user takes the role of the GSS-API Initiator and the OpenID 496 Relying Party takes the role of the GSS-API Acceptor. The OpenId 497 Provider does not have a role in GSS-API, and is considered an 498 internal matter for the OpenID mechanism. The messages are the same, 499 but a) the GS2 header on the client's first message and channel 500 binding data is excluded when OpenID is used as a GSS-API mechanism, 501 and b) the RFC2743 section 3.1 initial context token header is 502 prefixed to the client's first authentication message (context 503 token). 505 The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see 506 IANA considerations). 508 OpenID security contexts always have the mutual_state flag 509 (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 510 delegation, therefore OpenID security contexts alway have the 511 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 513 The mutual authentication property of this mechanism relies on 514 successfully comparing the TLS server identity with the negotiated 515 target name. Since the TLS channel is managed by the application 516 outside of the GSS-API mechanism, the mechanism itself is unable to 517 confirm the name while the application is able to perform this 518 comparison for the mechanism. For this reason, applications MUST 519 match the TLS server identity with the target name, as discussed in 520 [RFC6125]. 522 The OpenID mechanism does not support per-message tokens or 523 GSS_Pseudo_random. 525 The [RFC5587] mechanism attributes for this mechanism are 526 GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT. 528 4.1. GSS-API Principal Name Types for OpenID 530 OpenID supports standard generic name syntaxes for acceptors such as 531 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). 533 OpenID supports only a single name type for initiators: 534 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 535 OpenID. 537 OpenID name normalization is covered by the OpenID specification, see 538 [OpenID] section 7.2. 540 The query, display, and exported name syntaxes for OpenID principal 541 names are all the same. There are no OpenID-specific name syntaxes 542 -- applications should use generic GSS-API name types such as 543 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 544 Section 4). The exported name token does, of course, conform to 545 [RFC2743], Section 3.2, but the "NAME" part of the token should be 546 treated as a potential input string to the OpenID name normalization 547 rules. 549 GSS-API name attributes may be defined in the future to hold the 550 normalized OpenID Identifier. 552 5. Example 554 Suppose one has an OpenID of http://openid.example, and wishes to 555 authenticate his IMAP connection to mail.example (where .example is 556 the top level domain specified in [RFC2606]). The user would input 557 his Openid into his mail user agent, when he configures the account. 558 In this case, no association is attempted between the OpenID Consumer 559 and the OP. The client will make use of the return_to attribute to 560 capture results of the authentication to be redirected to the server. 561 Note the use of [RFC4959] for initial response. The authentication 562 on the wire would then look something like the following: 564 (S = IMAP server; C = IMAP client) 566 C: < connects to IMAP port> 567 S: * OK 568 C: C1 CAPABILITY 569 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 570 S: C1 OK Capability Completed 571 C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw== 572 [ This is the base64 encoding of "n,,http://openid.example/". 573 Server performs discovery on http://openid.example/ ] 574 S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z 575 PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p 576 ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt 577 ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w 578 ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v 579 cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls 580 LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA== 581 [ This is the base64 encoding of "http://openid.example/openid/ 582 ?openid.ns=http://specs.openid.net/auth/2.0 583 &openid.return_to=https://mail.example/consumer/1ef888c 584 &openid.claimed_id=https://openid.example/ 585 &openid.identity=https://openid.example/ 586 &openid.realm=imap://mail.example 587 &openid.mode=checkid_setup" 588 with line breaks and spaces added here for readibility. 589 ] 590 C: PQ== 591 [ The client now sends the URL it received to a browser for 592 processing. The user logs into http://openid.example, and 593 agrees to authenticate imap://mail.example. A redirect is 594 passed back to the client browser who then connects to 595 https://imap.example/consumer via SSL with the results. 596 From an IMAP perspective, however, the client sends the "=" 597 response, and awaits mail.example. 598 Server mail.example would now contact openid.example with an 599 openid.check_authenticate message. After that... 600 ] 601 S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp 602 b3QlMjBMZWFy 603 [ Here the IMAP server has returned an SREG attribute of 604 email=lear@mail.example,fullname=Eliot%20Lear. 605 Line break added in this example for clarity. ] 606 C: 607 [ In IMAP client must send a blank response to receive data 608 that is included in a success response. ] 609 S: C2 OK 611 In this example, the SASL server / RP has made use of a transaction 612 id 1ef888c. 614 6. Security Considerations 616 This section will address only security considerations associated 617 with the use of OpenID with SASL and GSS-API. For considerations 618 relating to OpenID in general, the reader is referred to the OpenID 619 specification and to other literature. Similarly, for general SASL 620 and GSS-API Security Considerations, the reader is referred to those 621 specifications. 623 6.1. Binding OpenIDs to Authorization Identities 625 As specified in [RFC4422], the server is responsible for binding 626 credentials to a specific authorization identity. It is therefore 627 necessary that either some sort of registration process takes place 628 to register specific OpenIDs, or that only specific trusted OpenID 629 Providers be allowed. Some out of band knowledge may help this 630 process along. For instance, users of a particular domain may 631 utilize a particular OP that enforces a mapping. 633 6.2. RP redirected by malicious URL to take an improper action 635 In the initial SASL client response a user or host can transmit a 636 malicious response to the RP for purposes of taking advantage of 637 weaknesses in the RP's OpenID implementation. It is possible to add 638 port numbers to the URL so that the outcome is the RP does a port 639 scan of the site. The URL could send the connection to an internal 640 host or even the local host, which the attacker would not normally 641 have access to. The URL could contain a protocol other than http or 642 https, such as file or ftp. 644 To mitigate this attack, implementations should carefully analyze 645 URLs received, eliminating any that would in some way be privileged. 646 A log of those sites that fail SHOULD be kept, and limitations on 647 queries from clients should be imposed, just as with any other 648 authentication attempt. It is RECOMMENDED that only http or https 649 schemas be accepted. 651 6.3. Session Swapping (Cross-Site Request Forgery) 653 There is no defined mechanism in the OpenID protocol to bind the 654 OpenID session to the user's browser. An attacker may forge a cross- 655 site request in the log-in form, which has the user logging into a 656 proper RP as the attacker. The user would not recognize they are 657 logged into the site as the attacker, and so may reveal information 658 at the RP. Cross-site request forgery is a widely exploited 659 vulnerability at web sites. This is only concern in the context SASL 660 in as much as the client is not configured with the Relying Party 661 (e.g., SASL server) in a safe manner. 663 6.4. User Privacy 665 The OP is aware of each RP that a user logs into. There is nothing 666 in the protocol to hide this information from the OP. It is not a 667 requirement to track the visits, but there is nothing that prohibits 668 the collection of information. SASL servers should be aware that 669 OpenID Providers will be track - to some extent - user access to 670 their services and any additional information that OP provides. 672 6.5. Collusion between RPs 674 It is possible for RPs to link data that they have collected on you. 675 By using the same identifier to log into every RP, collusion between 676 RPs is possible. In OpenID 2.0, directed identity was introduced. 677 Directed identity allows the OP to transform the identifier the user 678 typed in to another identifier. This way the RP would never see the 679 actual user identifier, but a randomly generated identifier. This is 680 an option the user has to understand and decide to use if the OP is 681 supporting it. 683 7. Room for Improvement 685 We note one area where there is possible room for improvement over 686 existing OpenID implementations. Because SASL is often implemented 687 atop protocols that have required some amount of provisioning, it may 688 be possible for the SASL client to signal the browser that the given 689 URL is the beginning of a sensitive transaction, and that increased 690 scrutiny should be given. A signal of some form would need to come 691 from an appropriately authorized agent that the sensitive transaction 692 is complete. An example behavior during this sensitive period might 693 be increased scrutiny of broken trust chains in certificates, or 694 perhaps disallowing such trust chains altogether. 696 8. IANA Considerations 698 The IANA is requested to update the SASL Mechanism Registry using the 699 following template, as described in [RFC4422]. 701 SASL mechanism name: OPENID20 703 Security Considerations: See this document 705 Published specification: See this document 707 Person & email address to contact for further information: Authors of 708 this document 710 Intended usage: COMMON 712 Owner/Change controller: IETF 714 Note: None 716 The IANA is further requested to assign an OID for this GSS mechanism 717 in the SMI numbers registry, with the prefix of 718 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 719 reference this specification in the registry. 721 9. Acknowledgments 723 The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark 724 Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, 725 and Klaas Wierenga for their review and contributions. 727 10. References 729 10.1. Normative References 731 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 732 December 2007. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 738 Names", BCP 32, RFC 2606, June 1999. 740 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 741 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 742 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 744 [RFC2743] Linn, J., "Generic Security Service Application Program 745 Interface Version 2, Update 1", RFC 2743, January 2000. 747 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 748 Resource Identifier (URI): Generic Syntax", STD 66, 749 RFC 3986, January 2005. 751 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 752 Security Layer (SASL)", RFC 4422, June 2006. 754 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 755 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 757 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 758 Housley, R., and W. Polk, "Internet X.509 Public Key 759 Infrastructure Certificate and Certificate Revocation List 760 (CRL) Profile", RFC 5280, May 2008. 762 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 763 Inquiry APIs", RFC 5587, July 2009. 765 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 766 Service Application Program Interface (GSS-API) Mechanisms 767 in Simple Authentication and Security Layer (SASL): The 768 GS2 Mechanism Family", RFC 5801, July 2010. 770 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 771 Verification of Domain-Based Application Service Identity 772 within Internet Public Key Infrastructure Using X.509 773 (PKIX) Certificates in the Context of Transport Layer 774 Security (TLS)", RFC 6125, March 2011. 776 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 777 version 1.0", June 2006. 779 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 780 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 781 September 2005. 783 10.2. Informative References 785 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 786 STD 53, RFC 1939, May 1996. 788 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 789 4rev1", RFC 3501, March 2003. 791 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 792 Protocol (XMPP): Core", RFC 3920, October 2004. 794 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 795 Simple Authentication and Security Layer (SASL) Initial 796 Client Response", RFC 4959, September 2007. 798 [W3C.REC-html401-19991224] 799 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 800 Specification", World Wide Web Consortium 801 Recommendation REC-html401-19991224, December 1999, 802 . 804 Appendix A. Changes 806 This section to be removed prior to publication. 808 o 03 Clarifies messages and ordering, and replace the empty message 809 with a "=" message. 811 o 02 Address all WGLC comments. 813 o 01 Specific text around possible improvements for OOB browser 814 control in security considerations. Also talk about transaction 815 id. 817 o 00 WG -00 draft. Slight wording modifications abou design 818 constraints per Alexey. 820 o 02 Correct single (significant) error on mechanism name. 822 o 01 Add nonce discussion, add authorized identity, explain a 823 definition. Add gs2 support. 825 o 00 Initial Revision. 827 Authors' Addresses 829 Eliot Lear 830 Cisco Systems GmbH 831 Richtistrasse 7 832 Wallisellen, ZH CH-8304 833 Switzerland 835 Phone: +41 44 878 9200 836 Email: lear@cisco.com 838 Hannes Tschofenig 839 Nokia Siemens Networks 840 Linnoitustie 6 841 Espoo 02600 842 Finland 844 Phone: +358 (50) 4871445 845 Email: Hannes.Tschofenig@gmx.net 846 URI: http://www.tschofenig.priv.at 848 Henry Mauldin 849 Cisco Systems, Inc. 850 170 West Tasman Drive 851 San Jose, CA 95134 852 USA 854 Phone: +1 (800) 553-6387 855 Email: hmauldin@cisco.com 857 Simon Josefsson 858 SJD AB 859 Hagagatan 24 860 Stockholm 113 47 861 SE 863 Email: simon@josefsson.org 864 URI: http://josefsson.org/