idnits 2.17.1 draft-lear-ietf-sasl-openid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2010) is 5033 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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 10, 2011 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 S. Josefsson 9 SJD AB 10 July 9, 2010 12 A SASL & GSS-API Mechanism for OpenID 13 draft-lear-ietf-sasl-openid-02 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 to IETF 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on January 10, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 68 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 8 69 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 71 3.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 72 3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10 74 3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11 75 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 76 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 77 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15 80 6.2. RP redirected by malicious URL to take an improper 81 action . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15 83 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 88 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 OpenID [OpenID] is a three-party protocol that provides a means for a 94 user to offer identity assertions and other attributes to a web 95 server (Relying Party) via the help of an identity provider. The 96 purpose of this system is to provide a way to verify that an end user 97 controls an identifier. 99 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 100 used by application protocols such IMAP, POP and XMPP, with the goal 101 of modularizing authentication and security layers, so that newer 102 mechanisms can be added as needed. This memo specifies just such a 103 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 interface. This document 108 defines a pure SASL mechanism for OpenID, but it conforms to the new 109 bridge between SASL and the GSS-API called GS2 [I-D.ietf-sasl-gs2]. 110 This means that this document defines both a SASL mechanism and a 111 GSS-API mechanism. We want to point out that the GSS-API interface 112 is optional for SASL implementers, and the GSS-API considerations can 113 be avoided in environments that uses SASL directly without GSS-API. 115 As currently envisioned, this mechanism is to allow the interworking 116 between SASL and OpenID in order to assert identity and other 117 attributes to relying parties. As such, while servers (as relying 118 parties) will advertise SASL mechanisms, clients will select the 119 OpenID mechanism. 121 The OpenID mechanism described in this memo aims to re-use the 122 available OpenID specification to a maximum extent and therefore does 123 not establish a separate authentication, integrity and 124 confidentiality mechanism. It is anticipated that existing security 125 layers, such as Transport Layer Security (TLS), will continued to be 126 used. 128 Figure 1 describes the interworking between OpenID and SASL. This 129 document requires enhancements to the Relying Party and to the Client 130 (as the two SASL communication end points) but no changes to the 131 OpenID Provider (OP) are necessary. To accomplish this goal indirect 132 messaging required by the OpenID specification is tunneled within 133 SASL. 135 +-----------+ 136 | | 137 >| Relying | 138 / | Party | 139 // | | 140 // +-----------+ 141 // ^ 142 OpenID // +--|--+ 143 // | O| | 144 / S | p| | 145 // A | e| | 146 // S | n| | 147 // L | I| | 148 // | D| | 149 | Client | 154 | | | | 155 +------------+ +----------+ 157 Figure 1: Interworking Architecture 159 1.1. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 The reader is assumed to be familiar with the terms used in the 166 OpenID 2.0 specification. 168 1.2. Applicability 170 Because this mechanism transports information that should not be 171 controlled by an attacker, the OpenID mechanism MUST only be used 172 over channels protected by TLS [RFC5246], and the client MUST 173 successfully validate the server certificate, or similar integrity 174 protected and authenticated channels. 176 2. Applicability for non-HTTP Use Cases 178 OpenID was originally envisioned for HTTP/HTML based communications, 179 and with the associated semantic, the idea being that the user would 180 be redirected by the Relying Party to an identity provider who 181 authenticates the user, and then sends identity information and other 182 attributes (either directly or indirectly) to the Relying Party. The 183 identity provider in the OpenID specifications is referred to as an 184 OpenID Provider (OP). The actual protocol flow, as copied from the 185 OpenID 2.0 specification, is as follows: 187 1. The end user initiates authentication by presenting a User- 188 Supplied Identifier to the Relying Party via their User-Agent 189 (e.g., http://user.example.com). 191 2. After normalizing the User-Supplied Identifier, the Relying Party 192 performs discovery on it and establishes the OP Endpoint URL that 193 the end user uses for authentication. It should be noted that 194 the User-Supplied Identifier may be an OP Identifier, which 195 allows selection of a Claimed Identifier at the OP or for the 196 protocol to proceed without a Claimed Identifier if something 197 else useful is being 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. 206 4. The Relying Party redirects the end user's User-Agent to the OP 207 with an OpenID Authentication request. This occurs as stated in 208 Section 10.3 of [RFC2616]. 210 5. The OP authenticates the end user and establishes whether the end 211 user will authenticate to, and share specific attributes with, 212 the Relying Party. For instance, the OP often asks the user what 213 to do. The manner in which the end user authenticates to their 214 OP and any policies surrounding such authentication is out of 215 scope of OpenID. 217 6. The OP redirects the end user's User-Agent back to the Relying 218 Party with either an assertion that authentication is approved or 219 a message that authentication failed. 221 7. The Relying Party verifies the information received from the OP 222 including checking the Return URL, verifying the discovered 223 information, checking the nonce, and verifying the signature by 224 using either the shared key established during the association or 225 by sending a direct request to the OP. 227 When considering this flow in the context of SASL, we note that while 228 the RP and the client both must change their code to implement this 229 SASL mechanism, the OP must remain untouched. Hence, an analog flow 230 that interfaces the three parties needs to be created. In the 231 analog, we note that unlike a web server, the SASL server already has 232 some sort of session (probably a TCP connection) established with the 233 client. However, it may be necessary to redirect a SASL client to 234 another application. This will be discussed below. By doing so, we 235 externalize much of the authentiction from SASL. 237 The steps are shown from below: 239 1. The Relying Party or SASL server advertises support for the SASL 240 OpenID mechanism to the client. 242 2. The client initiates a SASL authentiation and transmits the 243 User-Supplied Identifier as well as an optional return_to 244 parameter. 246 3. After normalizing the User-Supplied Identifier, the Relying 247 Party performs discovery on it and establishes the OP Endpoint 248 URL that the end user uses for authentication. 250 4. The Relying Party and the OP optionally establish an association 251 -- a shared secret established using Diffie-Hellman Key 252 Exchange. The OP uses an association to sign subsequent 253 messages and the Relying Party to verify those messages; this 254 removes the need for subsequent direct requests to verify the 255 signature after each authentication request/response. 257 5. The Relying Party transmits an authentication request to the OP 258 to obtain an assertion in the form of an indirect request. 259 These messages are passed through the client rather than 260 directly between the RP and the OP. OpenID defines two methods 261 for indirect communication, namely HTTP redirects and HTML form 262 submission. Both mechanisms are not directly applicable for 263 usage with SASL. To ensure that a standard OpenID 2.0 capable 264 OP can be used a new method is defined in this document that 265 requires the OpenID message content to be encoded using a 266 Universal Resource Idenitifier (URI). [RFC3986] 268 6. The SASL client now sends an empty response, as authentication 269 continues via the normal OpenID flow. 271 7. At this point the client application MUST construct a URL 272 containing the content received in the previous message from the 273 RP. This URL is transmitted to the OP either by the SASL client 274 application or an appropriate handler, such as a browser. 276 8. Next the client optionally authenticates to the OP and then 277 approves or disapproves authentication to the Relying Party. 278 The manner in which the end user is authenticated to their 279 respective OP and any policies surrounding such authentication 280 is out of scope of OpenID and and hence also out of scope for 281 this specification. This step happens out of band from SASL. 283 9. The OP will convey information about the success or failure of 284 the authentication phase back to the RP, again using an indirect 285 response via the client browser or handler. The client 286 transmits over HTTP the redirect of the OP result to the RP. 287 This step happens out of band from SASL. 289 10. The RP MAY send an OpenID check_authentication request directly 290 to the OP, if no association has been established, and the OP 291 should be expected to respond. Again this step happens out of 292 band from SASL. 294 11. The SASL server sends an appropriate SASL response to the 295 client, with optional Open Simple Registry (SREG) attributes. 297 SASL Serv. Client OP 298 |>-----(1)----->| | Advertisement 299 | | | 300 |<-----(2)-----<| | Initiation 301 | | | 302 |> - - (3) - - - - - - - - - ->| Discovery 303 | | 304 |>- - -(4)- - - - - - - - - - >| Association 305 |<- - -(4)- - - - - - - - - - <| 306 | | | 307 |>-----(5)----->| | Indirect Auth Request 308 | | | 309 |<-----(6)-----<| | Client Empty Response 310 | | | 311 | |>- - (7)- - ->| Client GET to the OP (ext) 312 | | | 313 | |<- - (8)- - ->| Client / OP Auth. (ext.) 314 | | | 315 |<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res 316 | | | 317 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 318 | | | 319 |>-----(11)---->| | SASL completion with status 321 ----- = SASL 322 - - - = HTTP or SSL 324 Note the directionality in SASL is such that the client MUST send an 325 empty response. Specifically, it processes the redirect and then 326 awaits a final SASL decision, while the rest of the OpenID 327 authentication process continues. 329 2.1. Binding SASL to OpenID in the Relying Party 331 To ensure that a specific request is bound, and in particular to ease 332 interprocess communication, it may be necessary for the relying party 333 to encode some sort of nonce in the URIs it transmits through the 334 client for success or failure. This can be done in any number of 335 ways. Examples would include making changes to the base URI or 336 otherwise including an additional fragment. 338 2.2. Discussion 340 As mentioned above OpenID is primarily designed to interact with web- 341 based applications. Portions of the authentication stream are only 342 defined in the crudest sense. That is, when one is prompted to 343 approve or disapprove an authentication, anything that one might find 344 on a browser is allowed, including JavaScript, fancy style-sheets, 345 etc. Because of this lack of structure, implementations will need to 346 invoke a fairly rich browser in order to insure that the 347 authentication can be completed. 349 Once there is an outcome, the SASL server needs to know about it. 350 The astute will hopefully by now have noticed an empty client SASL 351 challenge. This is not to say that nothing is happening, but rather 352 that authentication flow has shifted from SASL to OpenID, and will 353 return when the server has an outcome to hand to the client. The 354 alternative to this flow is some signal from the HTML browser to the 355 SASL client of the results that is in turn passed to the SASL server. 356 The IPC issue this raises is substantial. Better, we conclude, to 357 externalize the authentication to the browser, and have an empty 358 client challenge. 360 3. OpenID SASL Mechanism Specification 362 Based on the previous figure, the following operations are performed 363 with the OpenId SASL mechanism: 365 3.1. Advertisement 367 To advertise that a server supports OpenID, during application 368 session initiation, it displays the name "OPENID20" in the list of 369 supported SASL mechanisms. 371 3.2. Initiation 373 A client initiates an OpenID authentication with SASL by sending the 374 GS2 header followed by the XRI or URI, as specified in the OpenID 375 specification. The GS2 header carries the optional authorization 376 identity. 378 initial-response = gs2-header Auth-Identifier 379 Auth-Identifier = Identifier ; authentication identifier 380 Identifier = URI | XRI ; Identifer is specified in 381 ; Sec. 7.2 of the OpenID 2.0 spec. 383 The "gs2-header" is specified in [I-D.ietf-sasl-gs2], and it is used 384 as follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- 385 flag" MUST be "n" because channel binding is not supported by this 386 mechanism. The "gs2-authzid" carries the optional authorization 387 identity. 389 The XRI syntax is defined in [XRI2.0]. URI is specified in 390 [RFC3986]. 392 3.3. Authentication Request 394 The SASL Server sends an OpenID message that contains an openid.mode 395 of either "checkid_immediate" or "checkid_setup", as specified in 396 Section 9.1 of the OpenID 2.0 specification. 398 The client now sends that request via an HTTP GET to the OP, as if 399 redirected to do so from an HTTP server. 401 The client MUST handle both user authentication to the OP and 402 confirmation or rejection of the authentiation of the RP. 404 After all authentication has been completed by the OP, and after the 405 response has been sent to the client, the client will relay the 406 response to the Relying Party via HTTP or SSL. 408 3.4. Server Response 410 The Relying Party now validates the response it received from the 411 client via HTTP or SSL, as specified in the OpenID specification. 413 The response by the Relying Party consists of an application specific 414 response code indicating success or failure of authentication. In 415 the additional data, the server MAY include OpenID Simple Registry 416 (SREG) attributes that are listed in Section 4 of [SREG1.0]. They 417 are encoded as follows: 419 1. Strip "openid.sreg." from each attribute name. 421 2. Treat the concatentation of results as URI parameters that are 422 separated by an ambersand (&) and encode as one would a URI, 423 absent the scheme, authority, and the question mark. 425 For example: email=lear@example.com&fullname=Eliot%20Lear 427 More formally: 429 outcome_data = [ sreg_avp *( "," sreg_avp ) ] 430 sreg_avp = sreg_attr "=" sreg_val 431 sreg_attr = sreg_word 432 sreg_val = sreg_word 433 sreg_word = 1* ( unreserved / pct-encoded ) 434 ; pct-encoded from Section 2.1 of RFC 3896 435 ; unreserved from Section 2.3 of RFC 3896 437 If the application protocol allows, openid.error and 438 openid.error_code and any other useful diagnostic information SHOULD 439 be included in authentication failures. 441 4. OpenID GSS-API Mechanism Specification 443 This section and its sub-sections and all normative references of it 444 not referenced elsewhere in this document are INFORMATIONAL for SASL 445 implementors, but they are NORMATIVE for GSS-API implementors. 447 The OpenID SASL mechanism is actually also a GSS-API mechanism. The 448 messages are the same, but a) the GS2 header on the client's first 449 message and channel binding data is excluded when OpenID is used as a 450 GSS-API mechanism, and b) the RFC2743 section 3.1 initial context 451 token header is prefixed to the client's first authentication message 452 (context token). 454 The GSS-API mechanism OID for OpenID is 1.3.6.1.4.1.11591.4.5. 456 OpenID security contexts always have the mutual_state flag 457 (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 458 delegation, therefore OpenID security contexts alway have the 459 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 461 The OpenID mechanism does not support per-message tokens or 462 GSS_Pseudo_random. 464 4.1. GSS-API Principal Name Types for OpenID 466 OpenID supports standard generic name syntaxes for acceptors such as 467 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). 469 OpenID supports only a single name type for initiators: 470 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 471 OpenID. 473 OpenID name normalization is covered by the OpenID specification, see 474 [OpenID] section 7.2. 476 The query, display, and exported name syntaxes for OpenID principal 477 names are all the same. There are no OpenID-specific name syntaxes 478 -- applications should use generic GSS-API name types such as 479 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 480 Section 4). The exported name token does, of course, conform to 481 [RFC2743], Section 3.2, but the "NAME" part of the token should be 482 treated as a potential input string to the OpenID name normalization 483 rules. 485 GSS-API name attributes may be defined in the future to hold the 486 normalized OpenID Identifier. 488 5. Example 490 Suppose one has an OpenID of http://openid.example, and wishes to 491 authenticate his IMAP connection to mail.example (where .example is 492 the top level domain specified in [RFC2606]). The user would input 493 his Openid into his mail user agent, when he configures the account. 494 In this case, no association is attempted between the OpenID Consumer 495 and the OP. The client will make use of the return_to attribute to 496 capture results of the authentication to be redirected to the server. 497 The authentication on the wire would then look something like the 498 following: 500 (S = IMAP server; C = IMAP client) 502 C: < connects to IMAP port> 503 S: * OK 504 C: C1 CAPABILITY 505 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 506 S: C1 OK Capability Completed 507 C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw== 508 [ This is the base64 encoding of "n,,http://openid.example/". 509 Server performs discovery on http://openid.example/ ] 510 S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z 511 PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p 512 ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt 513 ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w 514 ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v 515 cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls 516 LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA== 517 [ This is the base64 encoding of "http://openid.example/openid/ 518 ?openid.ns=http://specs.openid.net/auth/2.0 519 &openid.return_to=https://mail.example/consumer/1ef888c 520 &openid.claimed_id=https://openid.example/ 521 &openid.identity=https://openid.example/ 522 &openid.realm=imap://mail.example 523 &openid.mode=checkid_setup" 524 with line breaks and spaces added here for readibility. 525 ] 526 C: 527 [ The client now sends the URL it received to a browser for 528 processing. The user logs into http://openid.example, and 529 agrees to authenticate imap://mail.example. A redirect is 530 passed back to the client browser who then connects to 531 https://imap.example/consumer via SSL with the results. 532 From an IMAP perspective, however, the client sends an empty 533 response, and awaits mail.example. 534 Server mail.example would now contact openid.example with an 535 openid.check_authenticate message. After that... 536 ] 537 S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp 538 b3QlMjBMZWFy 539 [ Here the IMAP server has returned an SREG attribute of 540 email=lear@mail.example,fullname=Eliot%20Lear. 541 Line break added in this example for clarity. ] 542 C: 543 [ In IMAP client must send a blank response to receive data 544 that is included in a success response. ] 545 S: C2 OK 547 6. Security Considerations 549 This section will address only security considerations associated 550 with the use of OpenID with SASL applications. For considerations 551 relating to OpenID in general, the reader is referred to the OpenID 552 specification and to other literature. Similarly, for general SASL 553 Security Considerations, the reader is referred to that 554 specification. 556 6.1. Binding OpenIDs to Authorization Identities 558 As specified in [RFC4422], the server is responsible for binding 559 credentials to a specific authorization identity. It is therefore 560 necessary that either some sort of registration process takes place 561 to register specific OpenIDs, or that only specific trusted OpenID 562 Providers be allowed. Some out of band knowledge may help this 563 process along. For instance, users of a particular domain may 564 utilize a particular OP that enforces a mapping. 566 6.2. RP redirected by malicious URL to take an improper action 568 In the initial SASL client response a user or host can transmit a 569 malicious response to the RP for purposes of taking advantage of 570 weaknesses in the RP's OpenID implementation. It is possible to add 571 port numbers to the URL so that the outcome is the RP does a port 572 scan of the site. The URL could send the connection to an internal 573 host or even the local host, which the attacker would not normally 574 have access to. The URL could contain a protocol other than http or 575 https, such as file or ftp. 577 To mitigate this attack, implementations should carefully analyze 578 URLs received, eliminating any that would in some way be privileged. 579 A log of those sites that fail SHOULD be kept, and limitations on 580 queries from clients should be imposed, just as with any other 581 authentication attempt. 583 6.3. Session Swapping (Cross-Site Request Forgery) 585 There is no defined mechanism in the OpenID protocol to bind the 586 OpenID session to the user's browser. An attacker may forge a cross- 587 site request in the log-in form, which has the user logging into a 588 proper RP as the attacker. The user would not recognize they are 589 logged into the site as the attacker, and so may reveal information 590 at the RP. Cross-site request forgery is a widely exploited 591 vulnerability at web sites. This is only concern in the context SASL 592 in as much as the client is not configured with the Relying Party 593 (e.g., SASL server) in a safe manner. 595 6.4. User Privacy 597 The OP is aware of each RP that a user logs into. There is nothing 598 in the protocol to hide this information from the OP. It is not a 599 requirement to track the visits, but there is nothing that prohibits 600 the collection of information. SASL servers should be aware that 601 OpenID Providers will be track - to some extent - user access to 602 their services and any additional information that OP provides. 604 6.5. Collusion between RPs 606 It is possible for RPs to link data that they have collected on you. 607 By using the same identifier to log into every RP, collusion between 608 RPs is possible. In OpenID 2.0, directed identity was introduced. 609 Directed identity allows the OP to transform the identifier the user 610 typed in to another identifier. This way the RP would never see the 611 actual user identifier, but a randomly generated identifier. This is 612 an option the user has to understand and decide to use if the OP is 613 supporting it. 615 7. IANA Considerations 617 The IANA is requested to register the following SASL profile: 619 SASL mechanism profile: OPENID20 621 Security Considerations: See this document 623 Published Specification: See this document 625 For further information: Contact the authors of this document. 627 Owner/Change controller: the IETF 629 Note: None 631 8. Acknowledgments 633 The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark 634 Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their 635 review and contributions. 637 9. Normative References 639 [I-D.ietf-sasl-gs2] 640 Josefsson, S. and N. Williams, "Using GSS-API Mechanisms 641 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20 642 (work in progress), January 2010. 644 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 645 December 2007. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 651 Names", BCP 32, RFC 2606, June 1999. 653 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 654 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 655 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 657 [RFC2743] Linn, J., "Generic Security Service Application Program 658 Interface Version 2, Update 1", RFC 2743, January 2000. 660 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 661 Resource Identifier (URI): Generic Syntax", STD 66, 662 RFC 3986, January 2005. 664 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 665 Security Layer (SASL)", RFC 4422, June 2006. 667 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 668 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 670 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 671 version 1.0", June 2006. 673 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 674 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 675 September 2005. 677 Appendix A. Changes 679 This section to be removed prior to publication. 681 o 02 Correct single (significant) error on mechanism name. 683 o 01 Add nonce discussion, add authorized identity, explain a 684 definition. Add gs2 support. 686 o 00 Initial Revision. 688 Authors' Addresses 690 Eliot Lear 691 Cisco Systems GmbH 692 Richtistrasse 7 693 Wallisellen, ZH CH-8304 694 Switzerland 696 Phone: +41 44 878 9200 697 Email: lear@cisco.com 699 Hannes Tschofenig 700 Nokia Siemens Networks 701 Linnoitustie 6 702 Espoo 02600 703 Finland 705 Phone: +358 (50) 4871445 706 Email: Hannes.Tschofenig@gmx.net 707 URI: http://www.tschofenig.priv.at 709 Henry Mauldin 710 Cisco Systems, Inc. 711 170 West Tasman Drive 712 San Jose, CA 95134 713 USA 715 Phone: +1 (800) 553-6387 716 Email: hmauldin@cisco.com 718 Simon Josefsson 719 SJD AB 720 Hagagatan 24 721 Stockholm 113 47 722 SE 724 Email: simon@josefsson.org 725 URI: http://josefsson.org/