idnits 2.17.1 draft-ietf-kitten-sasl-openid-08.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 (February 24, 2012) is 4445 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) -- Looks like a reference, but probably isn't: '1' on line 578 -- 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) 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: August 25, 2012 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 S. Josefsson 9 SJD AB 10 February 24, 2012 12 A SASL & GSS-API Mechanism for OpenID 13 draft-ietf-kitten-sasl-openid-08 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 25, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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 (http://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Applicability for application protocols other than HTTP . 4 62 2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7 63 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8 65 3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9 67 3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 68 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 69 4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 10 70 4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 11 71 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14 74 6.2. RP redirected by malicious URL to take an improper action 14 75 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 OpenID [OpenID] is a web-based three-party protocol that provides a 87 means for a user to offer identity assertions and other attributes to 88 a web server (Relying Party) via the help of an identity provider. 89 The purpose of this system is to provide a way to verify that an end 90 user controls an identifier. 92 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 93 used by application protocols such IMAP [RFC3501], POP [RFC1939] and 94 XMPP [RFC6120], with the goal of modularizing authentication and 95 security layers, so that newer mechanisms can be added as needed. 96 This memo specifies just such a mechanism. 98 The Generic Security Service Application Program Interface (GSS-API) 99 [RFC2743] provides a framework for applications to support multiple 100 authentication mechanisms through a unified interface. This document 101 defines a pure SASL mechanism for OpenID, but it conforms to the new 102 bridge between SASL and the GSS-API called GS2 [RFC5801]. This means 103 that this document defines both a SASL mechanism and a GSS-API 104 mechanism. Implementors of the SASL component MAY implement the GSS- 105 API interface as well. 107 This mechanism specifies interworking between SASL and OpenID in 108 order to assert identity and other attributes to relying parties. As 109 such, while SASL servers (as relying parties) will advertise SASL 110 mechanisms, clients will select the OpenID mechanism. 112 The OpenID mechanism described in this memo aims to re-use the OpenID 113 mechanism to the maximum extent and therefore does not establish a 114 separate authentication, integrity and confidentiality mechanism. It 115 is anticipated that existing security layers, such as Transport Layer 116 Security (TLS) [RFC5246], continue to be used. Minimal changes are 117 required to non-web applications, as most of the transaction occurs 118 through a normal web browser. Hence, this specification is only 119 appropriate for use when such a browser is available. 121 Figure 1 describes the interworking between OpenID and SASL. This 122 document requires enhancements to the Relying Party and to the Client 123 (as the two SASL communication end points) but no changes to the 124 OpenID Provider (OP) are necessary. To accomplish this goal indirect 125 messaging required by the OpenID specification is tunneled through 126 the SASL/GSS-API mechanism. 128 +-----------+ 129 | Relying | 130 >| Party / | 131 / | SASL | 132 // | Server | 133 // +-----------+ 134 // ^ 135 OpenID // +--|--+ 136 // | O| | G 137 / S | p| | S 138 // A | e| | S 139 // S | n| | A 140 // L | I| | P 141 // | D| | I 142 | Client | 147 | | | | 148 +------------+ +----------+ 150 1.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 The reader is assumed to be familiar with the terms used in the 157 OpenID 2.0 specification. 159 1.2. Applicability 161 Because this mechanism transports information that should not be 162 controlled by an attacker, the OpenID mechanism MUST only be used 163 over channels protected by TLS, and the client MUST successfully 164 validate the server certificate. [RFC5280][RFC6125] 166 2. Applicability for application protocols other than HTTP 168 OpenID was originally envisioned for HTTP [RFC2616] and HTML [W3C 169 .REC-html401-19991224] based communications, and with the associated 170 semantic, the idea being that the user would be redirected by the 171 Relying Party to an identity provider who authenticates the user, and 172 then sends identity information and other attributes (either directly 173 or indirectly) to the Relying Party. The identity provider in the 174 OpenID specifications is referred to as an OpenID Provider (OP). The 175 actual protocol flow can be found in Section 3 of the OpenID 2.0 176 specification [OpenID]. The reader is strongly encouraged to be 177 familiar with the specification before continuing. 179 When considering that flow in the context of SASL, we note that while 180 the RP and the client both need to change their code to implement 181 this SASL mechanism, it is a design constraint that the OP behavior 182 remain untouched, in order for implementations to interoperate with 183 existing IdPs. Hence, an analog flow that interfaces the three 184 parties needs to be created. In the analog, we note that unlike a 185 web server, the SASL server already has some sort of session 186 (probably a TCP connection) established with the client. However, it 187 may be necessary for a SASL client to invoke to another application. 188 This will be discussed below. By doing so, we externalize much of 189 the authentiction from SASL. 191 The steps are listed below: 193 1. The SASL server advertises support for the SASL OpenID mechanism 194 to the client. 196 2. The client initiates a SASL authentication and transmits the 197 User-Supplied Identifier as its first response. The SASL 198 mechanism is client-first, and as explained in [RFC4422] the 199 server will send an empty challenge if needed. 201 3. After normalizing the User-Supplied Identifier as discussed in 202 [OpenID], the Relying Party performs discovery on it and 203 establishes the OP Endpoint URL that the end user uses for 204 authentication. 206 4. The Relying Party and the OP optionally establish an association 207 -- a shared secret established using Diffie-Hellman Key Exchange. 208 The OP uses an association to validate those messages through the 209 use of an HMAC; this removes the need for subsequent direct 210 requests to verify the signature after each authentication 211 request/response. 213 5. The Relying Party transmits an authentication request to the OP 214 to obtain an assertion in the form of an indirect request. These 215 messages are passed through the client rather than directly 216 between the RP and the OP. OpenID defines two methods for 217 indirect communication, namely HTTP redirects and HTML form 218 submission. Both mechanisms are not directly applicable for 219 usage with SASL. To ensure that a standard OpenID 2.0 capable OP 220 can be used a new method is defined in this document that 221 requires the OpenID message content to be encoded using a 222 Universal Resource Idenitifier (URI). [RFC3986] Note that any 223 Internationalized Resource Identifiers (IRIs) must be normalized 224 to URIs by the SASL client, as specified in [RFC3987], prior to 225 transmitting them to the SASL server. 227 6. The SASL client now sends an response consisting of "=", to 228 indicate that authentication continues via the normal OpenID 229 flow. 231 7. At this point the client application MUST construct a URL 232 containing the content received in the previous message from the 233 RP. This URL is transmitted to the OP either by the SASL client 234 application or an appropriate handler, such as a browser. 236 8. Next the client optionally authenticates to the OP and then 237 approves or disapproves authentication to the Relying Party. For 238 reasons of its own the OP has the option of not authenticating a 239 request. The manner in which the end user is authenticated to 240 their respective OP and any policies surrounding such 241 authentication is out of scope of OpenID and and hence also out 242 of scope for this specification. This step happens out of band 243 from SASL. 245 9. The OP will convey information about the success or failure of 246 the authentication phase back to the RP, again using an indirect 247 response via the client browser or handler. The client transmits 248 over HTTP/TLS the redirect of the OP result to the RP. This step 249 happens out of band from SASL. 251 10. The RP MAY send an OpenID check_authentication request directly 252 to the OP, if no association has been established, and the OP 253 should respond. Again this step happens out of band from SASL. 255 11. The SASL server sends an appropriate SASL response to the 256 client, with optional Open Simple Registry (SREG) attributes. 258 SASL Serv. RP/Client OP 259 |>-----(1)----->| | Advertisement 260 | | | 261 |<-----(2)-----<| | Initiation 262 | | | 263 |> - - (3) - - - - - - - - - ->| Discovery 264 | | 265 |>- - -(4)- - - - - - - - - - >| Association 266 |<- - -(4)- - - - - - - - - - <| 267 | | | 268 |>-----(5)----->| | Indirect Auth Request 269 | | | 270 |<-----(6)-----<| | Client "=" Response 271 | | | 272 | |>- - (7)- - ->| Client GET to the OP (ext) 273 | | | 274 | |<- - (8)- - ->| Client / OP Auth. (ext.) 275 | | | 276 |<- - -(9)- - - + - - - - - - <| HTTPs Indirect id_res 277 | | | 278 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 279 | | | 280 |>-----(11)---->| | SASL completion with status 282 ----- = SASL 283 - - - = HTTPS 285 Note the directionality in SASL is such that the client MUST send the 286 "=" response. Specifically, the SASL client processes the redirect 287 and then awaits a final SASL decision, while the rest of the OpenID 288 authentication process continues. 290 2.1. Binding SASL to OpenID in the Relying Party 292 OpenID is meant to be used in serial within the web, where browser 293 cookies are easily accessible. As such, there are no transaction-ids 294 within the protocol. To ensure that a specific request is bound, and 295 in particular to ease interprocess communication, the relying party 296 MUST encode a nonce or transaction-id in the URIs it transmits 297 through the client for success or failure, either as a base URI or 298 fragment component to the "return_to" URI. This value is to be used 299 to uniquely identify each authentication transaction. The nonce 300 value MUST be at least 2^32 large and large enough to handle well in 301 excess of the number of concurrent transactions a SASL server shall 302 see. 304 2.2. Discussion 305 As mentioned above OpenID is primarily designed to interact with web- 306 based applications. Portions of the authentication stream are only 307 defined in the crudest sense. That is, when one is prompted to 308 approve or disapprove an authentication, anything that one might find 309 on a browser is allowed, including JavaScript, fancy style-sheets, 310 etc. Because of this lack of structure, implementations will need to 311 invoke a fairly rich browser in order to ensure that the 312 authentication can be completed. 314 Once there is an outcome, the SASL server needs to know about it. 315 The astute will hopefully by now have noticed an "=" client SASL 316 response. This is not to say that nothing is happening, but rather 317 that authentication flow has shifted from SASL and the client 318 application to OpenID within the browser, and will return to the 319 client application when the server has an outcome to hand to the 320 client. The alternative to this flow would be some sort of signal 321 from the HTML browser to the SASL client of the results that would in 322 turn be passed to the SASL server. The inter-process communication 323 issue this raises is substantial. Better, we conclude, to 324 externalize the authentication to the browser, and have an "=" client 325 response. 327 3. OpenID SASL Mechanism Specification 329 This section specifies the details of the OpenID SASL mechanism. 330 Recall section 5 of [RFC4422] for what needs to be described here. 332 The name of this mechanism "OPENID20". The mechanism is capable of 333 transferring an authorization identity (via "gs2-header"). The 334 mechanism does not offer a security layer. 336 The mechanism is client-first. The first mechanism message from the 337 client to the server is the "initial-response" described below. As 338 described in [RFC4422], if the application protocol does not support 339 sending a client-response together with the authentication request, 340 the server will send an empty server-challenge to let the client 341 begin. 343 The second mechanism message is from the server to the client, the 344 "authentication_request" described below. 346 The third mechanism message is from client to the server, and is the 347 fixed message consisting of "=". 349 The fourth mechanism message is from the server to the client, 350 described below as "outcome_data" (with SREG attributes), sent as 351 additional data when indicating a successful outcome. 353 3.1. Initiation 355 A client initiates an OpenID authentication with SASL by sending the 356 GS2 header followed by the URI, as specified in the OpenID 357 specification. 359 initial-response = gs2-header Auth-Identifier 360 Auth-Identifier = Identifier ; authentication identifier 361 Identifier = URI ; Identifier is specified in 362 ; Sec. 7.2 of the OpenID 2.0 spec. 364 The syntax and semantics of the "gs2-header" are specified in 365 [RFC5801], and we use it here with the following limitations: The 366 "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n" 367 because channel binding is not supported by this mechanism. 369 URI is specified in [RFC3986]. XRIs MUST NOT be used. [XRI2.0] 371 3.2. Authentication Request 373 The SASL Server sends the URL resulting from the OpenID 374 authentication request, containing an "openid.mode" of either 375 "checkid_immediate" or "checkid_setup", as specified in Section 9.1 376 of the OpenID 2.0 specification. 378 authentication-request = URI 380 As part of this request, the SASL server MUST append a unique 381 transaction id to the "return_to" portion of the request. The form 382 of this transaction is left to the RP to decide, but SHOULD be large 383 enough to be resistant to being guessed or attacked. 385 The client now sends that request via an HTTP GET to the OP, as if 386 redirected to do so from an HTTP server. 388 The client MUST handle both user authentication to the OP and 389 confirmation or rejection of the authentiation by the RP via this 390 SASL mechanism. 392 After all authentication has been completed by the OP, and after the 393 response has been sent to the client, the client will relay the 394 response to the Relying Party via HTTP/TLS, as specified previously 395 in the transaction ("return_to"). 397 3.3. Server Response 399 The Relying Party now validates the response it received from the 400 client via HTTP/TLS, as specified in the OpenID specification, using 401 the "return_to" URI given previsiously in the transaction. 403 The response by the Relying Party constitutes a SASL mechanism 404 outcome, and SHALL be used to set state in the server accordingly, 405 and it SHALL be used by the server to report that state to the SASL 406 client as described in [RFC4422] Section 3.6. In the additional 407 data, the server MAY include OpenID Simple Registry (SREG) attributes 408 that are listed in Section 4 of [SREG1.0].SREG attributes are encoded 409 as follows: 411 1. Strip "openid.sreg." from each attribute name. 413 2. Treat the concatentation of results as URI parameters that are 414 separated by an ampersand (&) and encode as one would a URI, 415 absent the scheme, authority, and the question mark. 417 For example: email=lear@example.com&fullname=Eliot%20Lear 419 More formally: 421 outcome-data = [ sreg-avp *( "," sreg-avp ) ] 422 sreg-avp = sreg-attr "=" sreg-val 423 sreg-attr = sreg-word 424 sreg-val = sreg-word 425 sreg-word = 1*( unreserved / pct-encoded ) 426 ; pct-encoded from Section 2.1 of RFC 3986 427 ; unreserved from Section 2.3 of RFC 3986 429 A client who does not support SREG MUST ignore SREG attributes sent 430 by the server. Similarly, a client MUST ignore unknown attributes. 432 In the case of failures, the response MUST follow this syntax: 434 outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp ) 436 3.4. Error Handling 438 [RFC4422] Section 3.6 explicitly prohibits additional information in 439 an unsuccessful authentication outcome. Therefore, the openid.error 440 and openid.error_code are to be sent as an additional challenge in 441 the event of an unsuccessful outcome. In this case, as the protocol 442 is lock step, the client will follow with an additional exchange 443 containing "=", after which the server will respond with an 444 application-level outcome. 446 4. OpenID GSS-API Mechanism Specification 447 This section and its sub-sections and appropriate references of it 448 not referenced elsewhere in this document are not required for SASL 449 implementors, but this section MUST be observed to implement the GSS- 450 API mechanism discussed below. 452 The OpenID SASL mechanism is actually also a GSS-API mechanism. The 453 OpenID user takes the role of the GSS-API Initiator and the OpenID 454 Relying Party takes the role of the GSS-API Acceptor. The OpenId 455 Provider does not have a role in GSS-API, and is considered an 456 internal matter for the OpenID mechanism. The messages are the same, 457 but a) the GS2 header on the client's first message and channel 458 binding data is excluded when OpenID is used as a GSS-API mechanism, 459 and b) the RFC2743 section 3.1 initial context token header is 460 prefixed to the client's first authentication message (context 461 token). 463 The GSS-API mechanism OID for OpenID is OID-TBD (IANA to assign: see 464 IANA considerations). 466 OpenID security contexts MUST have the mutual_state flag 467 (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential 468 delegation, therefore OpenID security contexts MUST have the 469 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 471 The mutual authentication property of this mechanism relies on 472 successfully comparing the TLS server identity with the negotiated 473 target name. Since the TLS channel is managed by the application 474 outside of the GSS-API mechanism, the mechanism itself is unable to 475 confirm the name while the application is able to perform this 476 comparison for the mechanism. For this reason, applications MUST 477 match the TLS server identity with the target name, as discussed in 478 [RFC6125]. 480 The OpenID mechanism does not support per-message tokens or 481 GSS_Pseudo_random. 483 The [RFC5587] mechanism attributes for this mechanism are 484 GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT. 486 4.1. GSS-API Principal Name Types for OpenID 488 OpenID supports standard generic name syntaxes for acceptors such as 489 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). 491 OpenID supports only a single name type for initiators: 492 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 493 OpenID. 495 OpenID name normalization is covered by the OpenID specification, see 496 [OpenID] section 7.2. 498 The query, display, and exported name syntaxes for OpenID principal 499 names are all the same. There are no OpenID-specific name syntaxes 500 -- applications should use generic GSS-API name types such as 501 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], 502 Section 4). The exported name token does, of course, conform to 503 [RFC2743], Section 3.2, but the "NAME" part of the token should be 504 treated as a potential input string to the OpenID name normalization 505 rules. For example, the OpenID identifier "https://openid.example/" 506 will have a GSS_C_NT_USER_NAME value of "https://openid.example/". 508 GSS-API name attributes may be defined in the future to hold the 509 normalized OpenID Identifier. 511 5. Example 513 Suppose one has an OpenID of https://openid.example, and wishes to 514 authenticate his IMAP connection to mail.example (where .example is 515 the top level domain specified in [RFC2606]). The user would input 516 his Openid into his mail user agent, when he configures the account. 517 In this case, no association is attempted between the OpenID RP and 518 the OP. The client will make use of the return_to attribute to 519 capture results of the authentication to be redirected to the server. 520 Note the use of [RFC4959] for initial response. The authentication 521 on the wire would then look something like the following: 523 (S = IMAP server; C = IMAP client) 525 C: < connects to IMAP port> 526 S: * OK 527 C: C1 CAPABILITY 528 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20 529 S: C1 OK Capability Completed 530 C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8= 531 [ This is the base64 encoding of "n,,https://openid.example/". 532 Server performs discovery on http://openid.example/ ] 533 S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1 534 odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm 535 V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ 536 jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh 537 bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1 538 wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW 539 5pZC5tb2RlPWNoZWNraWRfc2V0dXA= 541 [ This is the base64 encoding of "https://openid.example/openid/ 542 ?openid.ns=http://specs.openid.net/auth/2.0 543 &openid.return_to=https://mail.example/consumer/1ef888c 544 &openid.claimed_id=https://openid.example/ 545 &openid.identity=https://openid.example/ 546 &openid.realm=imap://mail.example 547 &openid.mode=checkid_setup" 548 with line breaks and spaces added here for readibility. 549 ] 550 C: PQ== 551 [ The client now sends the URL it received to a browser for 552 processing. The user logs into https://openid.example, and 553 agrees to authenticate imap://mail.example. A redirect is 554 passed back to the client browser who then connects to 555 https://imap.example/consumer via SSL with the results. 556 From an IMAP perspective, however, the client sends the "=" 557 response, and awaits mail.example. 558 Server mail.example would now contact openid.example with an 559 openid.check_authenticate message. After that... 560 ] 561 S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp 562 b3QlMjBMZWFy 563 [ Here the IMAP server has returned an SREG attribute of 564 email=lear@mail.example,fullname=Eliot%20Lear. 565 Line break in response added in this example for clarity. ] 566 C: 567 [ In IMAP client must send a blank response after receiving the 568 SREG data. ] 569 S: C2 OK 571 In this example, the SASL server / RP has made use of a transaction 572 id 1ef888c. 574 6. Security Considerations 575 This section will address only security considerations associated 576 with the use of OpenID with SASL and GSS-API. For considerations 577 relating to OpenID in general, the reader is referred to the OpenID 578 specification and to other literature [1]. Similarly, for general 579 SASL [RFC4422] and GSS-API [RFC5801] Security Considerations, the 580 reader is referred to those specifications. 582 6.1. Binding OpenIDs to Authorization Identities 584 As specified in [RFC4422], the server is responsible for binding 585 credentials to a specific authorization identity. It is therefore 586 necessary that a registration process takes place in advance that 587 binds specific OpenIDs to specific authorization identities, or that 588 only specific trusted OpenID Providers be allowed, where a mapping is 589 predefined. For example, it could be pre-arranged between an IdP and 590 RP that "https://example.com/user" maps to "user" for purposes of 591 authorization. 593 6.2. RP redirected by malicious URL to take an improper action 595 In the initial SASL client response a user or host can transmit a 596 malicious response to the RP for purposes of taking advantage of 597 weaknesses in the RP's OpenID implementation. It is possible to add 598 port numbers to the URL so that the outcome is the RP does a port 599 scan of the site. The URL could contain an unauthorized host or even 600 the local host. The URL could contain a protocol other than http or 601 https, such as file or ftp. 603 One mitigation would be for RPs to have a list of authorized URI 604 bases. OPs SHOULD only redirect to RPs with the same domain 605 component of the base URI. RPs MUST NOT automatically retry on 606 failed attempts. A log of those sites that fail SHOULD be kept, and 607 limitations on queries from clients SHOULD be imposed, just as with 608 any other authentication attempt. Applications SHOULD NOT invoke 609 browsers to communicate with OPs that they are not themselves 610 configured with. 612 6.3. User Privacy 614 The OP is aware of each RP that a user logs into. There is nothing 615 in the protocol to hide this information from the OP. It is not a 616 requirement to track the visits, but there is nothing that prohibits 617 the collection of information. SASL servers should be aware that 618 OpenID Providers will be able to track - to some extent - user access 619 to their services and any additional information that OP provides. 621 7. IANA Considerations 623 The IANA is requested to update the SASL Mechanism Registry using the 624 following template, as described in [RFC4422]. 626 SASL mechanism name: OPENID20 627 Security Considerations: See this document 629 Published specification: See this document 631 Person & email address to contact for further information: Authors of 632 this document 634 Intended usage: COMMON 636 Owner/Change controller: IETF 638 Note: None 640 The IANA is further requested to assign an OID for this GSS mechanism 641 in the SMI numbers registry, with the prefix of 642 iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to 643 reference this specification in the registry. 645 8. Acknowledgments 647 The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark 648 Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, 649 Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review 650 and contributions. 652 9. References 654 9.1. Normative References 656 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 657 December 2007. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC2606] Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS 663 Names", BCP 32, RFC 2606, June 1999. 665 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 666 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 667 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 669 [RFC2743] Linn, J., "Generic Security Service Application Program 670 Interface Version 2, Update 1", RFC 2743, January 2000. 672 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 673 Resource Identifier (URI): Generic Syntax", STD 66, RFC 674 3986, January 2005. 676 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 677 Identifiers (IRIs)", RFC 3987, January 2005. 679 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 680 Security Layer (SASL)", RFC 4422, June 2006. 682 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 683 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 685 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 686 Housley, R. and W. Polk, "Internet X.509 Public Key 687 Infrastructure Certificate and Certificate Revocation List 688 (CRL) Profile", RFC 5280, May 2008. 690 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 691 Inquiry APIs", RFC 5587, July 2009. 693 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 694 Service Application Program Interface (GSS-API) Mechanisms 695 in Simple Authentication and Security Layer (SASL): The 696 GS2 Mechanism Family", RFC 5801, July 2010. 698 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 699 Verification of Domain-Based Application Service Identity 700 within Internet Public Key Infrastructure Using X.509 701 (PKIX) Certificates in the Context of Transport Layer 702 Security (TLS)", RFC 6125, March 2011. 704 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 705 version 1.0", June 2006. 707 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 708 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 709 September 2005. 711 9.2. Informative References 713 [RFC1939] Myers, J.G. and M.T. Rose, "Post Office Protocol - Version 714 3", STD 53, RFC 1939, May 1996. 716 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 717 4rev1", RFC 3501, March 2003. 719 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 720 Simple Authentication and Security Layer (SASL) Initial 721 Client Response", RFC 4959, September 2007. 723 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 724 Protocol (XMPP): Core", RFC 6120, March 2011. 726 [W3C.REC-html401-19991224] 727 Hors, A., Raggett, D. and I. Jacobs, "HTML 4.01 728 Specification", World Wide Web Consortium Recommendation 729 REC-html401-19991224, December 1999, . 732 Appendix A. Changes 734 This section to be removed prior to publication. 736 o 04 - 07 04 - 07 address LC and review comments, including those of 737 Stephen Farrell, Steve Kent, and Brian Carpenter. 739 o 03 Clarifies messages and ordering, and replace the empty message 740 with a "=" message. 742 o 02 Address all WGLC comments. 744 o 01 Specific text around possible improvements for OOB browser 745 control in security considerations. Also talk about transaction 746 id. 748 o 00 WG -00 draft. Slight wording modifications abou design 749 constraints per Alexey. 751 o 02 Correct single (significant) error on mechanism name. 753 o 01 Add nonce discussion, add authorized identity, explain a 754 definition. Add gs2 support. 756 o 00 Initial Revision. 758 Authors' Addresses 760 Eliot Lear 761 Cisco Systems GmbH 762 Richtistrasse 7 763 Wallisellen, ZH CH-8304 764 Switzerland 766 Phone: +41 44 878 9200 767 Email: lear@cisco.com 769 Hannes Tschofenig 770 Nokia Siemens Networks 771 Linnoitustie 6 772 Espoo, 02600 773 Finland 775 Phone: +358 (50) 4871445 776 Email: Hannes.Tschofenig@gmx.net 777 URI: http://www.tschofenig.priv.at 778 Henry Mauldin 779 Cisco Systems, Inc. 780 170 West Tasman Drive 781 San Jose, CA 95134 782 USA 784 Phone: +1 (800) 553-6387 785 Email: hmauldin@cisco.com 787 Simon Josefsson 788 SJD AB 789 Hagagatan 24 790 Stockholm, 113 47 791 SE 793 Email: simon@josefsson.org 794 URI: http://josefsson.org/