idnits 2.17.1 draft-ietf-kitten-sasl-openid-06.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 (September 27, 2011) is 4566 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: March 30, 2012 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 S. Josefsson 9 SJD AB 10 September 27, 2011 12 A SASL & GSS-API Mechanism for OpenID 13 draft-ietf-kitten-sasl-openid-06 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 March 30, 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. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 18 78 7. Room for Improvement . . . . . . . . . . . . . . . . . . . . . 19 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 84 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 1. Introduction 89 OpenID [OpenID] is a web-based three-party protocol that provides a 90 means for a user to offer identity assertions and other attributes to 91 a web server (Relying Party) via the help of an identity provider. 92 The purpose of this system is to provide a way to verify that an end 93 user controls an identifier. 95 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 96 used by application protocols such IMAP [RFC3501], POP [RFC1939] and 97 XMPP [RFC3920], with the goal of modularizing authentication and 98 security layers, so that newer mechanisms can be added as needed. 99 This memo specifies just such a 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 [RFC5801]. This means 106 that this document defines both a SASL mechanism and a GSS-API 107 mechanism. Implementors of the SASL component MAY implement the GSS- 108 API interface as well. 110 As currently envisioned, this mechanism is to allow the interworking 111 between SASL and OpenID in order to assert identity and other 112 attributes to relying parties. As such, while servers (as relying 113 parties) will advertise SASL mechanisms, clients will select the 114 OpenID mechanism. 116 The OpenID mechanism described in this memo aims to re-use the OpenID 117 mechanism to the maximum extent and therefore does not establish a 118 separate authentication, integrity and confidentiality mechanism. It 119 is anticipated that existing security layers, such as Transport Layer 120 Security (TLS) [RFC5246], will continued to be used. This 121 specification is appropriate for use when a browser is available. 123 Figure 1 describes the interworking between OpenID and SASL. This 124 document requires enhancements to the Relying Party and to the Client 125 (as the two SASL communication end points) but no changes to the 126 OpenID Provider (OP) are necessary. To accomplish this goal indirect 127 messaging required by the OpenID specification is tunneled through 128 the SASL/GSS-API mechanism. 130 +-----------+ 131 | | 132 >| Relying | 133 / | Party | 134 // | | 135 // +-----------+ 136 // ^ 137 OpenID // +--|--+ 138 // | O| | G 139 / S | p| | S 140 // A | e| | S 141 // S | n| | A 142 // L | I| | P 143 // | D| | I 144 | Client | 149 | | | | 150 +------------+ +----------+ 152 Figure 1: Interworking Architecture 154 1.1. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 The reader is assumed to be familiar with the terms used in the 161 OpenID 2.0 specification. 163 1.2. Applicability 165 Because this mechanism transports information that should not be 166 controlled by an attacker, the OpenID mechanism MUST only be used 167 over channels protected by TLS, and the client MUST successfully 168 validate the server certificate, or similar integrity protected and 169 authenticated channels. [RFC5280][RFC6125] 171 2. Applicability for non-HTTP Use Cases 173 OpenID was originally envisioned for HTTP [RFC2616] and HTML 174 [W3C.REC-html401-19991224] based communications, and with the 175 associated semantic, the idea being that the user would be redirected 176 by the Relying Party to an identity provider who authenticates the 177 user, and then sends identity information and other attributes 178 (either directly or indirectly) to the Relying Party. The identity 179 provider in the OpenID specifications is referred to as an OpenID 180 Provider (OP). The actual protocol flow, as copied from the OpenID 181 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., https://user.example.com). 187 2. After normalizing the User-Supplied Identifier as described in 188 Section 7.2 of [OpenID], the Relying Party performs discovery on 189 the URI specified and establishes the OP Endpoint URL that the 190 end user uses for authentication. It should be noted that the 191 User-Supplied Identifier may be an OP Identifier, which allows 192 selection of a Claimed Identifier at the OP or for the protocol 193 to proceed without a Claimed Identifier if something else useful 194 is being done via an extension. 196 3. The Relying Party and the OP optionally establish an association 197 -- a shared secret established using Diffie-Hellman Key Exchange. 198 The OP uses an association to sign subsequent messages and the 199 Relying Party to verify those messages; this removes the need for 200 subsequent direct requests to verify the signature after each 201 authentication request/response. This process is desccribed in 202 Section 8 of [OpenID]. 204 4. The Relying Party redirects the end user's User-Agent to the OP 205 with an OpenID Authentication request. This occurs as stated in 206 Section 10.3 of [RFC2616]. 208 5. The OP authenticates the end user and establishes whether the end 209 user will authenticate to, and share specific attributes with, 210 the Relying Party. For instance, the OP often asks the user what 211 to do. The manner in which the end user authenticates to their 212 OP and any policies surrounding such authentication is out of 213 scope of OpenID. 215 6. The OP redirects the end user's User-Agent back to the Relying 216 Party with either an assertion that authentication is approved or 217 a message that authentication failed. 219 7. The Relying Party verifies the information received from the OP 220 including checking the Return URL, verifying the discovered 221 information, checking the nonce, and verifying the signature by 222 using either the shared key established during the association or 223 by sending a direct request to the OP. 225 When considering this flow in the context of SASL, we note that while 226 the RP and the client both need to change their code to implement 227 this SASL mechanism, it is a design constraint that the OP behavior 228 remain untouched, in order for implementations to interoperate with 229 existing IdPs. Hence, an analog flow that interfaces the three 230 parties needs to be created. In the analog, we note that unlike a 231 web server, the SASL server already has some sort of session 232 (probably a TCP connection) established with the client. However, it 233 may be necessary for a SASL client to invoke to another application. 234 This will be discussed below. By doing so, we externalize much of 235 the authentiction from SASL. 237 The steps are listed 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 authentication and transmits the 243 User-Supplied Identifier as its first response. The SASL 244 mechanism is client-first, and as explained in [RFC4422] the 245 server will send an empty challenge if needed. 247 3. After normalizing the User-Supplied Identifier as discussed in 248 [OpenID], the Relying Party performs discovery on it and 249 establishes the OP Endpoint URL that the end user uses for 250 authentication. 252 4. The Relying Party and the OP optionally establish an association 253 -- a shared secret established using Diffie-Hellman Key 254 Exchange. The OP uses an association to sign subsequent 255 messages and the Relying Party to verify those messages; this 256 removes the need for subsequent direct requests to verify the 257 signature after each authentication request/response. 259 5. The Relying Party transmits an authentication request to the OP 260 to obtain an assertion in the form of an indirect request. 261 These messages are passed through the client rather than 262 directly between the RP and the OP. OpenID defines two methods 263 for indirect communication, namely HTTP redirects and HTML form 264 submission. Both mechanisms are not directly applicable for 265 usage with SASL. To ensure that a standard OpenID 2.0 capable 266 OP can be used a new method is defined in this document that 267 requires the OpenID message content to be encoded using a 268 Universal Resource Idenitifier (URI). [RFC3986] 270 6. The SASL client now sends an response consisting of "=", to 271 indicate that authentication continues via the normal OpenID 272 flow. 274 7. At this point the client application MUST construct a URL 275 containing the content received in the previous message from the 276 RP. This URL is transmitted to the OP either by the SASL client 277 application or an appropriate handler, such as a browser. 279 8. Next the client optionally authenticates to the OP and then 280 approves or disapproves authentication to the Relying Party. 281 The manner in which the end user is authenticated to their 282 respective OP and any policies surrounding such authentication 283 is out of scope of OpenID and and hence also out of scope for 284 this specification. This step happens out of band from SASL. 286 9. The OP will convey information about the success or failure of 287 the authentication phase back to the RP, again using an indirect 288 response via the client browser or handler. The client 289 transmits over HTTP/TLS the redirect of the OP result to the RP. 290 This step happens out of band from SASL. 292 10. The RP MAY send an OpenID check_authentication request directly 293 to the OP, if no association has been established, and the OP 294 should be expected to respond. Again this step happens out of 295 band from SASL. 297 11. The SASL server sends an appropriate SASL response to the 298 client, with optional Open Simple Registry (SREG) attributes. 300 SASL Serv. Client OP 301 |>-----(1)----->| | Advertisement 302 | | | 303 |<-----(2)-----<| | Initiation 304 | | | 305 |> - - (3) - - - - - - - - - ->| Discovery 306 | | 307 |>- - -(4)- - - - - - - - - - >| Association 308 |<- - -(4)- - - - - - - - - - <| 309 | | | 310 |>-----(5)----->| | Indirect Auth Request 311 | | | 312 |<-----(6)-----<| | Client "=" Response 313 | | | 314 | |>- - (7)- - ->| Client GET to the OP (ext) 315 | | | 316 | |<- - (8)- - ->| Client / OP Auth. (ext.) 317 | | | 318 |<- - -(9)- - - + - - - - - - <| HTTPs Indirect id_res 319 | | | 320 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 321 | | | 322 |>-----(11)---->| | SASL completion with status 324 ----- = SASL 325 - - - = HTTPS 327 Note the directionality in SASL is such that the client MUST send the 328 "=" response. Specifically, the SASL client processes the redirect 329 and then awaits a final SASL decision, while the rest of the OpenID 330 authentication process continues. 332 2.1. Binding SASL to OpenID in the Relying Party 334 To ensure that a specific request is bound, and in particular to ease 335 interprocess communication, it may be necessary for the relying party 336 to encode some sort of nonce or transaction-id in the URIs it 337 transmits through the client for success or failure. This can be 338 done in any number of ways. Examples would include making changes to 339 the base URI or otherwise including an additional fragment. 341 2.2. Discussion 343 As mentioned above OpenID is primarily designed to interact with web- 344 based applications. Portions of the authentication stream are only 345 defined in the crudest sense. That is, when one is prompted to 346 approve or disapprove an authentication, anything that one might find 347 on a browser is allowed, including JavaScript, fancy style-sheets, 348 etc. Because of this lack of structure, implementations will need to 349 invoke a fairly rich browser in order to ensure that the 350 authentication can be completed. 352 Once there is an outcome, the SASL server needs to know about it. 353 The astute will hopefully by now have noticed an "=" client SASL 354 response. This is not to say that nothing is happening, but rather 355 that authentication flow has shifted from SASL to OpenID, and will 356 return when the server has an outcome to hand to the client. The 357 alternative to this flow is some signal from the HTML browser to the 358 SASL client of the results that is in turn passed to the SASL server. 359 The IPC issue this raises is substantial. Better, we conclude, to 360 externalize the authentication to the browser, and have an "=" client 361 response. 363 OpenID is also meant to be used in serial within the web. As such, 364 there are no transaction-ids within the protocol. A transaction id, 365 MUST be included by the RP by appending it to the return_to URL. 367 3. OpenID SASL Mechanism Specification 369 This section specifies the details of the OpenID SASL mechanism. 370 Recall section 5 of [RFC4422] for what needs to be described here. 372 The name of this mechanism "OPENID20". The mechanism is capable of 373 transferring an authorization identity (via "gs2-header"). The 374 mechanism does not offer a security layer. 376 The mechanism is client-first. The first mechanism message from the 377 client to the server is the "initial-response" described below. As 378 described in [RFC4422], if the application protocol does not support 379 sending a client-response together with the authentication request, 380 the server will send an empty server-challenge to let the client 381 begin. 383 The second mechanism message is from the server to the client, the 384 "authentication_request" described below. 386 The third mechanism message is from client to the server, and is the 387 fixed message consisting of "=". 389 The fourth mechanism message is from the server to the client, 390 described below as "outcome_data" (with SREG attributes), sent as 391 additional data when indicating a successful outcome. 393 3.1. Initiation 395 A client initiates an OpenID authentication with SASL by sending the 396 GS2 header followed by the URI, as specified in the OpenID 397 specification. The GS2 header carries the optional authorization 398 identity. 400 initial-response = gs2-header Auth-Identifier 401 Auth-Identifier = Identifier ; authentication identifier 402 Identifier = URI ; Identifier is specified in 403 ; Sec. 7.2 of the OpenID 2.0 spec. 405 The "gs2-header" is specified in [RFC5801], and it is used as 406 follows. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- 407 flag" MUST be "n" because channel binding is not supported by this 408 mechanism. The "gs2-authzid" carries the optional authorization 409 identity. 411 URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0] 413 3.2. Authentication Request 415 The SASL Server sends the URL resulting from the OpenID 416 authentication request, containing an "openid.mode" of either 417 "checkid_immediate" or "checkid_setup", as specified in Section 9.1 418 of the OpenID 2.0 specification. 420 authentication-request = URI 422 As part of this request, the SASL server MUST append a unique 423 transaction id to the "return_to" portion of the request. The form 424 of this transaction is left to the RP to decide, but SHOULD be large 425 enough to be resistant to being guessed or attacked. 427 The client now sends that request via an HTTP GET to the OP, as if 428 redirected to do so from an HTTP server. 430 The client MUST handle both user authentication to the OP and 431 confirmation or rejection of the authentiation by the RP via this 432 SASL mechanism. 434 After all authentication has been completed by the OP, and after the 435 response has been sent to the client, the client will relay the 436 response to the Relying Party via HTTP/TLS, as specified previously 437 in the transaction ("return_to"). 439 3.3. Server Response 441 The Relying Party now validates the response it received from the 442 client via HTTP/TLS, as specified in the OpenID specification, using 443 the "return_to" URI given previsiously in the transaction. 445 The response by the Relying Party constitutes a SASL mechanism 446 outcome, and SHALL be used to set state in the server accordingly, 447 and it SHALL be used by the server to report that state to the SASL 448 client as described in [RFC4422] Section 3.6. In the additional 449 data, the server MAY include OpenID Simple Registry (SREG) attributes 450 that are listed in Section 4 of [SREG1.0]. They are encoded as 451 follows: 453 1. Strip "openid.sreg." from each attribute name. 455 2. Treat the concatentation of results as URI parameters that are 456 separated by an ampersand (&) and encode as one would a URI, 457 absent the scheme, authority, and the question mark. 459 For example: email=lear@example.com&fullname=Eliot%20Lear 460 More formally: 462 outcome-data = [ sreg-avp *( "," sreg-avp ) ] 463 sreg-avp = sreg-attr "=" sreg-val 464 sreg-attr = sreg-word 465 sreg-val = sreg-word 466 sreg-word = 1*( unreserved / pct-encoded ) 467 ; pct-encoded from Section 2.1 of RFC 3986 468 ; unreserved from Section 2.3 of RFC 3986 470 A client who does not support SREG MUST ignore SREG attributes sent 471 by the server. Similarly, a client MUST ignore unknown attributes. 473 In the case of failures, the response MUST follow this syntax: 475 outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp ) 477 3.4. Error Handling 479 [RFC4422] Section 3.6 explicitly prohibits additional information in 480 an unsuccessful authentication outcome. Therefore, the openid.error 481 and openid.error_code are to be sent as an additional challenge in 482 the event of an unsuccessful outcome. In this case, as the protocol 483 is lock step, the client will follow with an additional exchange 484 containing "=", after which the server will respond with an 485 application-level outcome. 487 4. OpenID GSS-API Mechanism Specification 489 This section and its sub-sections and appropriate references of it 490 not referenced elsewhere in this document are not required for SASL 491 implementors, but this section MUST be observed to implement the GSS- 492 API mechanism discussed below. 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 MUST have the mutual_state flag 509 (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 510 delegation, therefore OpenID security contexts MUST 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. For example, the OpenID identifier "https://openid.example/" 548 will have a GSS_C_NT_USER_NAME value of "https://openid.example/". 550 GSS-API name attributes may be defined in the future to hold the 551 normalized OpenID Identifier. 553 5. Example 555 Suppose one has an OpenID of https://openid.example, and wishes to 556 authenticate his IMAP connection to mail.example (where .example is 557 the top level domain specified in [RFC2606]). The user would input 558 his Openid into his mail user agent, when he configures the account. 559 In this case, no association is attempted between the OpenID Consumer 560 and the OP. The client will make use of the return_to attribute to 561 capture results of the authentication to be redirected to the server. 562 Note the use of [RFC4959] for initial response. The authentication 563 on the wire would then look something like the following: 565 (S = IMAP server; C = IMAP client) 567 C: < connects to IMAP port> 568 S: * OK 569 C: C1 CAPABILITY 570 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 571 S: C1 OK Capability Completed 572 C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8= 573 [ This is the base64 encoding of "n,,https://openid.example/". 574 Server performs discovery on http://openid.example/ ] 575 S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1 576 odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm 577 V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ 578 jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh 579 bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1 580 wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW 581 5pZC5tb2RlPWNoZWNraWRfc2V0dXA= 583 [ This is the base64 encoding of "https://openid.example/openid/ 584 ?openid.ns=http://specs.openid.net/auth/2.0 585 &openid.return_to=https://mail.example/consumer/1ef888c 586 &openid.claimed_id=https://openid.example/ 587 &openid.identity=https://openid.example/ 588 &openid.realm=imap://mail.example 589 &openid.mode=checkid_setup" 590 with line breaks and spaces added here for readibility. 591 ] 592 C: PQ== 593 [ The client now sends the URL it received to a browser for 594 processing. The user logs into https://openid.example, and 595 agrees to authenticate imap://mail.example. A redirect is 596 passed back to the client browser who then connects to 597 https://imap.example/consumer via SSL with the results. 598 From an IMAP perspective, however, the client sends the "=" 599 response, and awaits mail.example. 600 Server mail.example would now contact openid.example with an 601 openid.check_authenticate message. After that... 602 ] 603 S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp 604 b3QlMjBMZWFy 605 [ Here the IMAP server has returned an SREG attribute of 606 email=lear@mail.example,fullname=Eliot%20Lear. 607 Line break in response added in this example for clarity. ] 608 C: 609 [ In IMAP client must send a blank response to receive data 610 that is included in a success response. ] 611 S: C2 OK 613 In this example, the SASL server / RP has made use of a transaction 614 id 1ef888c. 616 6. Security Considerations 618 This section will address only security considerations associated 619 with the use of OpenID with SASL and GSS-API. For considerations 620 relating to OpenID in general, the reader is referred to the OpenID 621 specification and to other literature 622 . Similarly, 623 for general SASL [RFC4422] and GSS-API [RFC5801] Security 624 Considerations, the reader is referred to those specifications. 626 6.1. Binding OpenIDs to Authorization Identities 628 As specified in [RFC4422], the server is responsible for binding 629 credentials to a specific authorization identity. It is therefore 630 necessary that either some sort of registration process takes place 631 to register specific OpenIDs, or that only specific trusted OpenID 632 Providers be allowed. Some out of band knowledge may help this 633 process along. For instance, users of a particular domain may 634 utilize a particular OP that enforces a mapping. 636 6.2. RP redirected by malicious URL to take an improper action 638 In the initial SASL client response a user or host can transmit a 639 malicious response to the RP for purposes of taking advantage of 640 weaknesses in the RP's OpenID implementation. It is possible to add 641 port numbers to the URL so that the outcome is the RP does a port 642 scan of the site. The URL could send the connection to an internal 643 host or even the local host, which the attacker would not normally 644 have access to. The URL could contain a protocol other than http or 645 https, such as file or ftp. 647 To mitigate this attack, implementations should carefully analyze 648 URLs received, eliminating any that would in some way be privileged. 649 A log of those sites that fail SHOULD be kept, and limitations on 650 queries from clients SHOULD be imposed, just as with any other 651 authentication attempt. It is RECOMMENDED that only http or https 652 schemes be accepted. 654 6.3. User Privacy 656 The OP is aware of each RP that a user logs into. There is nothing 657 in the protocol to hide this information from the OP. It is not a 658 requirement to track the visits, but there is nothing that prohibits 659 the collection of information. SASL servers should be aware that 660 OpenID Providers will be able to track - to some extent - user access 661 to their services and any additional information that OP provides. 663 7. Room for Improvement 665 We note one area where there is possible room for improvement over 666 existing OpenID implementations. Because SASL is often implemented 667 atop protocols that have required some amount of provisioning, it may 668 be possible for the SASL client to signal the browser that the given 669 URL is the beginning of a sensitive transaction, and that increased 670 scrutiny should be given. A signal of some form would need to come 671 from an appropriately authorized agent that the sensitive transaction 672 is complete. An example behavior during this sensitive period might 673 be increased scrutiny of broken trust chains in certificates, or 674 perhaps disallowing such trust chains altogether. 676 8. IANA Considerations 678 The IANA is requested to update the SASL Mechanism Registry using the 679 following template, as described in [RFC4422]. 681 SASL mechanism name: OPENID20 683 Security Considerations: See this document 685 Published specification: See this document 687 Person & email address to contact for further information: Authors of 688 this document 690 Intended usage: COMMON 692 Owner/Change controller: IETF 694 Note: None 696 The IANA is further requested to assign an OID for this GSS mechanism 697 in the SMI numbers registry, with the prefix of 698 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 699 reference this specification in the registry. 701 9. Acknowledgments 703 The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark 704 Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, 705 and Klaas Wierenga for their review and contributions. 707 10. References 709 10.1. Normative References 711 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 712 December 2007. 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 718 Names", BCP 32, RFC 2606, June 1999. 720 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 721 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 722 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 724 [RFC2743] Linn, J., "Generic Security Service Application Program 725 Interface Version 2, Update 1", RFC 2743, January 2000. 727 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 728 Resource Identifier (URI): Generic Syntax", STD 66, 729 RFC 3986, January 2005. 731 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 732 Security Layer (SASL)", RFC 4422, June 2006. 734 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 735 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 737 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 738 Housley, R., and W. Polk, "Internet X.509 Public Key 739 Infrastructure Certificate and Certificate Revocation List 740 (CRL) Profile", RFC 5280, May 2008. 742 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 743 Inquiry APIs", RFC 5587, July 2009. 745 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 746 Service Application Program Interface (GSS-API) Mechanisms 747 in Simple Authentication and Security Layer (SASL): The 748 GS2 Mechanism Family", RFC 5801, July 2010. 750 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 751 Verification of Domain-Based Application Service Identity 752 within Internet Public Key Infrastructure Using X.509 753 (PKIX) Certificates in the Context of Transport Layer 754 Security (TLS)", RFC 6125, March 2011. 756 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 757 version 1.0", June 2006. 759 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 760 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 761 September 2005. 763 10.2. Informative References 765 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 766 STD 53, RFC 1939, May 1996. 768 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 769 4rev1", RFC 3501, March 2003. 771 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 772 Protocol (XMPP): Core", RFC 3920, October 2004. 774 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 775 Simple Authentication and Security Layer (SASL) Initial 776 Client Response", RFC 4959, September 2007. 778 [W3C.REC-html401-19991224] 779 Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 780 Specification", World Wide Web Consortium 781 Recommendation REC-html401-19991224, December 1999, 782 . 784 Appendix A. Changes 786 This section to be removed prior to publication. 788 o 03 Clarifies messages and ordering, and replace the empty message 789 with a "=" message. 791 o 02 Address all WGLC comments. 793 o 01 Specific text around possible improvements for OOB browser 794 control in security considerations. Also talk about transaction 795 id. 797 o 00 WG -00 draft. Slight wording modifications abou design 798 constraints per Alexey. 800 o 02 Correct single (significant) error on mechanism name. 802 o 01 Add nonce discussion, add authorized identity, explain a 803 definition. Add gs2 support. 805 o 00 Initial Revision. 807 Authors' Addresses 809 Eliot Lear 810 Cisco Systems GmbH 811 Richtistrasse 7 812 Wallisellen, ZH CH-8304 813 Switzerland 815 Phone: +41 44 878 9200 816 Email: lear@cisco.com 818 Hannes Tschofenig 819 Nokia Siemens Networks 820 Linnoitustie 6 821 Espoo 02600 822 Finland 824 Phone: +358 (50) 4871445 825 Email: Hannes.Tschofenig@gmx.net 826 URI: http://www.tschofenig.priv.at 828 Henry Mauldin 829 Cisco Systems, Inc. 830 170 West Tasman Drive 831 San Jose, CA 95134 832 USA 834 Phone: +1 (800) 553-6387 835 Email: hmauldin@cisco.com 837 Simon Josefsson 838 SJD AB 839 Hagagatan 24 840 Stockholm 113 47 841 SE 843 Email: simon@josefsson.org 844 URI: http://josefsson.org/