idnits 2.17.1 draft-ietf-kitten-sasl-openid-01.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 : ---------------------------------------------------------------------------- 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 (January 31, 2011) is 4806 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: 2 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: August 4, 2011 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 S. Josefsson 9 SJD AB 10 January 31, 2011 12 A SASL & GSS-API Mechanism for OpenID 13 draft-ietf-kitten-sasl-openid-01 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 August 4, 2011. 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. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10 69 3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 11 70 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 12 71 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12 72 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 15 75 6.2. RP redirected by malicious URL to take an improper 76 action . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 15 78 6.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 16 80 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 83 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 84 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 OpenID [OpenID] is a three-party protocol that provides a means for a 90 user to offer identity assertions and other attributes to a web 91 server (Relying Party) via the help of an identity provider. The 92 purpose of this system is to provide a way to verify that an end user 93 controls an identifier. 95 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 96 used by application protocols such IMAP, POP and XMPP, with the goal 97 of modularizing authentication and security layers, so that newer 98 mechanisms can be added as needed. This memo specifies just such a 99 mechanism. 101 The Generic Security Service Application Program Interface (GSS-API) 102 [RFC2743] provides a framework for applications to support multiple 103 authentication mechanisms through a unified interface. This document 104 defines a pure SASL mechanism for OpenID, but it conforms to the new 105 bridge between SASL and the GSS-API called GS2 [I-D.ietf-sasl-gs2]. 106 This means that this document defines both a SASL mechanism and a 107 GSS-API mechanism. We want to point out that the GSS-API interface 108 is optional for SASL implementers, and the GSS-API considerations can 109 be avoided in environments that uses SASL directly without GSS-API. 111 As currently envisioned, this mechanism is to allow the interworking 112 between SASL and OpenID in order to assert identity and other 113 attributes to relying parties. As such, while servers (as relying 114 parties) will advertise SASL mechanisms, clients will select the 115 OpenID mechanism. 117 The OpenID mechanism described in this memo aims to re-use the 118 available OpenID specification to a maximum extent and therefore does 119 not establish a separate authentication, integrity and 120 confidentiality mechanism. It is anticipated that existing security 121 layers, such as Transport Layer Security (TLS), will continued to be 122 used. 124 Figure 1 describes the interworking between OpenID and SASL. This 125 document requires enhancements to the Relying Party and to the Client 126 (as the two SASL communication end points) but no changes to the 127 OpenID Provider (OP) are necessary. To accomplish this goal indirect 128 messaging required by the OpenID specification is tunneled within 129 SASL. 131 +-----------+ 132 | | 133 >| Relying | 134 / | Party | 135 // | | 136 // +-----------+ 137 // ^ 138 OpenID // +--|--+ 139 // | O| | 140 / S | p| | 141 // A | e| | 142 // S | n| | 143 // L | I| | 144 // | D| | 145 | Client | 150 | | | | 151 +------------+ +----------+ 153 Figure 1: Interworking Architecture 155 1.1. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 The reader is assumed to be familiar with the terms used in the 162 OpenID 2.0 specification. 164 1.2. Applicability 166 Because this mechanism transports information that should not be 167 controlled by an attacker, the OpenID mechanism MUST only be used 168 over channels protected by TLS [RFC5246], and the client MUST 169 successfully validate the server certificate, or similar integrity 170 protected and authenticated channels. 172 2. Applicability for non-HTTP Use Cases 174 OpenID was originally envisioned for HTTP/HTML based communications, 175 and with the associated semantic, the idea being that the user would 176 be redirected by the Relying Party to an identity provider who 177 authenticates the user, and then sends identity information and other 178 attributes (either directly or indirectly) to the Relying Party. The 179 identity provider in the OpenID specifications is referred to as an 180 OpenID Provider (OP). The actual protocol flow, as copied from the 181 OpenID 2.0 specification, is as follows: 183 1. The end user initiates authentication by presenting a User- 184 Supplied Identifier to the Relying Party via their User-Agent 185 (e.g., http://user.example.com). 187 2. After normalizing the User-Supplied Identifier, the Relying Party 188 performs discovery on it and establishes the OP Endpoint URL that 189 the end user uses for authentication. It should be noted that 190 the User-Supplied Identifier may be an OP Identifier, which 191 allows selection of a Claimed Identifier at the OP or for the 192 protocol to proceed without a Claimed Identifier if something 193 else useful is being done via an extension. 195 3. The Relying Party and the OP optionally establish an association 196 -- a shared secret established using Diffie-Hellman Key Exchange. 197 The OP uses an association to sign subsequent messages and the 198 Relying Party to verify those messages; this removes the need for 199 subsequent direct requests to verify the signature after each 200 authentication request/response. 202 4. The Relying Party redirects the end user's User-Agent to the OP 203 with an OpenID Authentication request. This occurs as stated in 204 Section 10.3 of [RFC2616]. 206 5. The OP authenticates the end user and establishes whether the end 207 user will authenticate to, and share specific attributes with, 208 the Relying Party. For instance, the OP often asks the user what 209 to do. The manner in which the end user authenticates to their 210 OP and any policies surrounding such authentication is out of 211 scope of OpenID. 213 6. The OP redirects the end user's User-Agent back to the Relying 214 Party with either an assertion that authentication is approved or 215 a message that authentication failed. 217 7. The Relying Party verifies the information received from the OP 218 including checking the Return URL, verifying the discovered 219 information, checking the nonce, and verifying the signature by 220 using either the shared key established during the association or 221 by sending a direct request to the OP. 223 When considering this flow in the context of SASL, we note that while 224 the RP and the client both must change their code to implement this 225 SASL mechanism, it is a design constraint that the OP behavior remain 226 untouched, in order for implementations to interoperate with existing 227 IdPs. Hence, an analog flow that interfaces the three parties needs 228 to be created. In the analog, we note that unlike a web server, the 229 SASL server already has some sort of session (probably a TCP 230 connection) established with the client. However, it may be 231 necessary to redirect a SASL client to another application. This 232 will be discussed below. By doing so, we externalize much of the 233 authentiction from SASL. 235 The steps are shown from below: 237 1. The Relying Party or SASL server advertises support for the SASL 238 OpenID mechanism to the client. 240 2. The client initiates a SASL authentiation and transmits the 241 User-Supplied Identifier as well as an optional return_to 242 parameter. 244 3. After normalizing the User-Supplied Identifier, the Relying 245 Party performs discovery on it and establishes the OP Endpoint 246 URL that the end user uses for authentication. 248 4. The Relying Party and the OP optionally establish an association 249 -- a shared secret established using Diffie-Hellman Key 250 Exchange. The OP uses an association to sign subsequent 251 messages and the Relying Party to verify those messages; this 252 removes the need for subsequent direct requests to verify the 253 signature after each authentication request/response. 255 5. The Relying Party transmits an authentication request to the OP 256 to obtain an assertion in the form of an indirect request. 257 These messages are passed through the client rather than 258 directly between the RP and the OP. OpenID defines two methods 259 for indirect communication, namely HTTP redirects and HTML form 260 submission. Both mechanisms are not directly applicable for 261 usage with SASL. To ensure that a standard OpenID 2.0 capable 262 OP can be used a new method is defined in this document that 263 requires the OpenID message content to be encoded using a 264 Universal Resource Idenitifier (URI). [RFC3986] 266 6. The SASL client now sends an empty response, as authentication 267 continues via the normal OpenID flow. 269 7. At this point the client application MUST construct a URL 270 containing the content received in the previous message from the 271 RP. This URL is transmitted to the OP either by the SASL client 272 application or an appropriate handler, such as a browser. 274 8. Next the client optionally authenticates to the OP and then 275 approves or disapproves authentication to the Relying Party. 276 The manner in which the end user is authenticated to their 277 respective OP and any policies surrounding such authentication 278 is out of scope of OpenID and and hence also out of scope for 279 this specification. This step happens out of band from SASL. 281 9. The OP will convey information about the success or failure of 282 the authentication phase back to the RP, again using an indirect 283 response via the client browser or handler. The client 284 transmits over HTTP the redirect of the OP result to the RP. 285 This step happens out of band from SASL. 287 10. The RP MAY send an OpenID check_authentication request directly 288 to the OP, if no association has been established, and the OP 289 should be expected to respond. Again this step happens out of 290 band from SASL. 292 11. The SASL server sends an appropriate SASL response to the 293 client, with optional Open Simple Registry (SREG) attributes. 295 SASL Serv. Client OP 296 |>-----(1)----->| | Advertisement 297 | | | 298 |<-----(2)-----<| | Initiation 299 | | | 300 |> - - (3) - - - - - - - - - ->| Discovery 301 | | 302 |>- - -(4)- - - - - - - - - - >| Association 303 |<- - -(4)- - - - - - - - - - <| 304 | | | 305 |>-----(5)----->| | Indirect Auth Request 306 | | | 307 |<-----(6)-----<| | Client Empty Response 308 | | | 309 | |>- - (7)- - ->| Client GET to the OP (ext) 310 | | | 311 | |<- - (8)- - ->| Client / OP Auth. (ext.) 312 | | | 313 |<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res 314 | | | 315 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 316 | | | 317 |>-----(11)---->| | SASL completion with status 319 ----- = SASL 320 - - - = HTTP or SSL 322 Note the directionality in SASL is such that the client MUST send an 323 empty response. Specifically, it processes the redirect and then 324 awaits a final SASL decision, while the rest of the OpenID 325 authentication process continues. 327 2.1. Binding SASL to OpenID in the Relying Party 329 To ensure that a specific request is bound, and in particular to ease 330 interprocess communication, it may be necessary for the relying party 331 to encode some sort of nonce in the URIs it transmits through the 332 client for success or failure. This can be done in any number of 333 ways. Examples would include making changes to the base URI or 334 otherwise including an additional fragment. 336 2.2. Discussion 338 As mentioned above OpenID is primarily designed to interact with web- 339 based applications. Portions of the authentication stream are only 340 defined in the crudest sense. That is, when one is prompted to 341 approve or disapprove an authentication, anything that one might find 342 on a browser is allowed, including JavaScript, fancy style-sheets, 343 etc. Because of this lack of structure, implementations will need to 344 invoke a fairly rich browser in order to insure that the 345 authentication can be completed. 347 Once there is an outcome, the SASL server needs to know about it. 348 The astute will hopefully by now have noticed an empty client SASL 349 challenge. This is not to say that nothing is happening, but rather 350 that authentication flow has shifted from SASL to OpenID, and will 351 return when the server has an outcome to hand to the client. The 352 alternative to this flow is some signal from the HTML browser to the 353 SASL client of the results that is in turn passed to the SASL server. 354 The IPC issue this raises is substantial. Better, we conclude, to 355 externalize the authentication to the browser, and have an empty 356 client challenge. 358 OpenID is also meant to be used in serial within the web. As such, 359 there are no transaction-ids within the protocol. A transaction id, 360 can be included by the RP by appending it to the return_to URL. 362 3. OpenID SASL Mechanism Specification 364 Based on the previous figure, the following operations are performed 365 with the OpenId SASL mechanism: 367 3.1. Advertisement 369 To advertise that a server supports OpenID, during application 370 session initiation, it displays the name "OPENID20" in the list of 371 supported SASL mechanisms. 373 3.2. Initiation 375 A client initiates an OpenID authentication with SASL by sending the 376 GS2 header followed by the XRI or URI, as specified in the OpenID 377 specification. The GS2 header carries the optional authorization 378 identity. 380 initial-response = gs2-header Auth-Identifier 381 Auth-Identifier = Identifier ; authentication identifier 382 Identifier = URI | XRI ; Identifer is specified in 383 ; Sec. 7.2 of the OpenID 2.0 spec. 385 The "gs2-header" is specified in [I-D.ietf-sasl-gs2], and it is used 386 as follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- 387 flag" MUST be "n" because channel binding is not supported by this 388 mechanism. The "gs2-authzid" carries the optional authorization 389 identity. 391 The XRI syntax is defined in [XRI2.0]. URI is specified in 392 [RFC3986]. 394 3.3. Authentication Request 396 The SASL Server sends an OpenID message that contains an openid.mode 397 of either "checkid_immediate" or "checkid_setup", as specified in 398 Section 9.1 of the OpenID 2.0 specification. 400 As part of this request, the SASL server MUST append a unique 401 transaction id to the "e;return_to" portion of the request. The 402 form of this transaction is left to the RP to decide, but SHOULD be 403 large enough to be resistant to being guessed or attacked. 405 The client now sends that request via an HTTP GET to the OP, as if 406 redirected to do so from an HTTP server. 408 The client MUST handle both user authentication to the OP and 409 confirmation or rejection of the authentiation of the RP. 411 After all authentication has been completed by the OP, and after the 412 response has been sent to the client, the client will relay the 413 response to the Relying Party via HTTP or SSL. 415 3.4. Server Response 417 The Relying Party now validates the response it received from the 418 client via HTTP or SSL, as specified in the OpenID specification. 420 The response by the Relying Party consists of an application specific 421 response code indicating success or failure of authentication. In 422 the additional data, the server MAY include OpenID Simple Registry 423 (SREG) attributes that are listed in Section 4 of [SREG1.0]. They 424 are encoded as follows: 426 1. Strip "openid.sreg." from each attribute name. 428 2. Treat the concatentation of results as URI parameters that are 429 separated by an ambersand (&) and encode as one would a URI, 430 absent the scheme, authority, and the question mark. 432 For example: email=lear@example.com&fullname=Eliot%20Lear 434 More formally: 436 outcome_data = [ sreg_avp *( "," sreg_avp ) ] 437 sreg_avp = sreg_attr "=" sreg_val 438 sreg_attr = sreg_word 439 sreg_val = sreg_word 440 sreg_word = 1* ( unreserved / pct-encoded ) 441 ; pct-encoded from Section 2.1 of RFC 3896 442 ; unreserved from Section 2.3 of RFC 3896 444 If the application protocol allows, openid.error and 445 openid.error_code and any other useful diagnostic information SHOULD 446 be included in authentication failures. 448 4. OpenID GSS-API Mechanism Specification 450 This section and its sub-sections and all normative references of it 451 not referenced elsewhere in this document are INFORMATIONAL for SASL 452 implementors, but they are NORMATIVE for GSS-API implementors. 454 The OpenID SASL mechanism is actually also a GSS-API mechanism. The 455 messages are the same, but a) the GS2 header on the client's first 456 message and channel binding data is excluded when OpenID is used as a 457 GSS-API mechanism, and b) the RFC2743 section 3.1 initial context 458 token header is prefixed to the client's first authentication message 459 (context token). 461 The GSS-API mechanism OID for OpenID is 1.3.6.1.4.1.11591.4.5. 463 OpenID security contexts always have the mutual_state flag 464 (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 465 delegation, therefore OpenID security contexts alway have the 466 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 468 The OpenID mechanism does not support per-message tokens or 469 GSS_Pseudo_random. 471 4.1. GSS-API Principal Name Types for OpenID 473 OpenID supports standard generic name syntaxes for acceptors such as 474 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). 476 OpenID supports only a single name type for initiators: 477 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 478 OpenID. 480 OpenID name normalization is covered by the OpenID specification, see 481 [OpenID] section 7.2. 483 The query, display, and exported name syntaxes for OpenID principal 484 names are all the same. There are no OpenID-specific name syntaxes 485 -- applications should use generic GSS-API name types such as 486 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 487 Section 4). The exported name token does, of course, conform to 488 [RFC2743], Section 3.2, but the "NAME" part of the token should be 489 treated as a potential input string to the OpenID name normalization 490 rules. 492 GSS-API name attributes may be defined in the future to hold the 493 normalized OpenID Identifier. 495 5. Example 497 Suppose one has an OpenID of http://openid.example, and wishes to 498 authenticate his IMAP connection to mail.example (where .example is 499 the top level domain specified in [RFC2606]). The user would input 500 his Openid into his mail user agent, when he configures the account. 501 In this case, no association is attempted between the OpenID Consumer 502 and the OP. The client will make use of the return_to attribute to 503 capture results of the authentication to be redirected to the server. 504 The authentication on the wire would then look something like the 505 following: 507 (S = IMAP server; C = IMAP client) 509 C: < connects to IMAP port> 510 S: * OK 511 C: C1 CAPABILITY 512 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 513 S: C1 OK Capability Completed 514 C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw== 515 [ This is the base64 encoding of "n,,http://openid.example/". 516 Server performs discovery on http://openid.example/ ] 517 S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z 518 PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p 519 ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt 520 ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w 521 ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v 522 cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls 523 LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA== 524 [ This is the base64 encoding of "http://openid.example/openid/ 525 ?openid.ns=http://specs.openid.net/auth/2.0 526 &openid.return_to=https://mail.example/consumer/1ef888c 527 &openid.claimed_id=https://openid.example/ 528 &openid.identity=https://openid.example/ 529 &openid.realm=imap://mail.example 530 &openid.mode=checkid_setup" 531 with line breaks and spaces added here for readibility. 532 ] 533 C: 534 [ The client now sends the URL it received to a browser for 535 processing. The user logs into http://openid.example, and 536 agrees to authenticate imap://mail.example. A redirect is 537 passed back to the client browser who then connects to 538 https://imap.example/consumer via SSL with the results. 539 From an IMAP perspective, however, the client sends an empty 540 response, and awaits mail.example. 541 Server mail.example would now contact openid.example with an 542 openid.check_authenticate message. After that... 543 ] 544 S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp 545 b3QlMjBMZWFy 546 [ Here the IMAP server has returned an SREG attribute of 547 email=lear@mail.example,fullname=Eliot%20Lear. 548 Line break added in this example for clarity. ] 549 C: 550 [ In IMAP client must send a blank response to receive data 551 that is included in a success response. ] 552 S: C2 OK 554 6. Security Considerations 556 This section will address only security considerations associated 557 with the use of OpenID with SASL applications. For considerations 558 relating to OpenID in general, the reader is referred to the OpenID 559 specification and to other literature. Similarly, for general SASL 560 Security Considerations, the reader is referred to that 561 specification. 563 6.1. Binding OpenIDs to Authorization Identities 565 As specified in [RFC4422], the server is responsible for binding 566 credentials to a specific authorization identity. It is therefore 567 necessary that either some sort of registration process takes place 568 to register specific OpenIDs, or that only specific trusted OpenID 569 Providers be allowed. Some out of band knowledge may help this 570 process along. For instance, users of a particular domain may 571 utilize a particular OP that enforces a mapping. 573 6.2. RP redirected by malicious URL to take an improper action 575 In the initial SASL client response a user or host can transmit a 576 malicious response to the RP for purposes of taking advantage of 577 weaknesses in the RP's OpenID implementation. It is possible to add 578 port numbers to the URL so that the outcome is the RP does a port 579 scan of the site. The URL could send the connection to an internal 580 host or even the local host, which the attacker would not normally 581 have access to. The URL could contain a protocol other than http or 582 https, such as file or ftp. 584 To mitigate this attack, implementations should carefully analyze 585 URLs received, eliminating any that would in some way be privileged. 586 A log of those sites that fail SHOULD be kept, and limitations on 587 queries from clients should be imposed, just as with any other 588 authentication attempt. 590 6.3. Session Swapping (Cross-Site Request Forgery) 592 There is no defined mechanism in the OpenID protocol to bind the 593 OpenID session to the user's browser. An attacker may forge a cross- 594 site request in the log-in form, which has the user logging into a 595 proper RP as the attacker. The user would not recognize they are 596 logged into the site as the attacker, and so may reveal information 597 at the RP. Cross-site request forgery is a widely exploited 598 vulnerability at web sites. This is only concern in the context SASL 599 in as much as the client is not configured with the Relying Party 600 (e.g., SASL server) in a safe manner. 602 6.4. User Privacy 604 The OP is aware of each RP that a user logs into. There is nothing 605 in the protocol to hide this information from the OP. It is not a 606 requirement to track the visits, but there is nothing that prohibits 607 the collection of information. SASL servers should be aware that 608 OpenID Providers will be track - to some extent - user access to 609 their services and any additional information that OP provides. 611 6.5. Collusion between RPs 613 It is possible for RPs to link data that they have collected on you. 614 By using the same identifier to log into every RP, collusion between 615 RPs is possible. In OpenID 2.0, directed identity was introduced. 616 Directed identity allows the OP to transform the identifier the user 617 typed in to another identifier. This way the RP would never see the 618 actual user identifier, but a randomly generated identifier. This is 619 an option the user has to understand and decide to use if the OP is 620 supporting it. 622 7. Room for Improvement 624 We note one area where there is possible room for improvement over 625 existing OpenID implementations. Because SASL is often implemented 626 atop protocols that have required some amount of provisioning, it may 627 be possible for the SASL client to signal the browser that it should 628 increase scrutiny of invalid credentials. How this would be done is 629 beyond the scope of this specification, but may be the subject of 630 future updates. For instance, the browser may wish to fail the 631 request entirely if the certificate is invalid and has not been 632 accessed prior to this point. One thing that this would require 633 would be the exposure of a "return_to" URL by the SASL server in case 634 of such failures, so that the authentication is not left hanging. 636 8. IANA Considerations 638 The IANA is requested to register the following SASL profile: 640 SASL mechanism profile: OPENID20 642 Security Considerations: See this document 644 Published Specification: See this document 646 For further information: Contact the authors of this document. 648 Owner/Change controller: the IETF 650 Note: None 652 9. Acknowledgments 654 The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark 655 Crispin, Chris Newman, Leif Johansson, and Klaas Wierenga for their 656 review and contributions. 658 10. Normative References 660 [I-D.ietf-sasl-gs2] 661 Josefsson, S. and N. Williams, "Using GSS-API Mechanisms 662 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-20 663 (work in progress), January 2010. 665 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 666 December 2007. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 672 Names", BCP 32, RFC 2606, June 1999. 674 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 675 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 676 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 678 [RFC2743] Linn, J., "Generic Security Service Application Program 679 Interface Version 2, Update 1", RFC 2743, January 2000. 681 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 682 Resource Identifier (URI): Generic Syntax", STD 66, 683 RFC 3986, January 2005. 685 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 686 Security Layer (SASL)", RFC 4422, June 2006. 688 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 689 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 691 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 692 version 1.0", June 2006. 694 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 695 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 696 September 2005. 698 Appendix A. Changes 700 This section to be removed prior to publication. 702 o 01 Specific text around possible improvements for OOB browser 703 control in security considerations. Also talk about transaction 704 id. 706 o 00 WG -00 draft. Slight wording modifications abou design 707 constraints per Alexey. 709 o 02 Correct single (significant) error on mechanism name. 711 o 01 Add nonce discussion, add authorized identity, explain a 712 definition. Add gs2 support. 714 o 00 Initial Revision. 716 Authors' Addresses 718 Eliot Lear 719 Cisco Systems GmbH 720 Richtistrasse 7 721 Wallisellen, ZH CH-8304 722 Switzerland 724 Phone: +41 44 878 9200 725 Email: lear@cisco.com 727 Hannes Tschofenig 728 Nokia Siemens Networks 729 Linnoitustie 6 730 Espoo 02600 731 Finland 733 Phone: +358 (50) 4871445 734 Email: Hannes.Tschofenig@gmx.net 735 URI: http://www.tschofenig.priv.at 737 Henry Mauldin 738 Cisco Systems, Inc. 739 170 West Tasman Drive 740 San Jose, CA 95134 741 USA 743 Phone: +1 (800) 553-6387 744 Email: hmauldin@cisco.com 746 Simon Josefsson 747 SJD AB 748 Hagagatan 24 749 Stockholm 113 47 750 SE 752 Email: simon@josefsson.org 753 URI: http://josefsson.org/