idnits 2.17.1 draft-prodromou-dialback-00.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 (September 6, 2012) is 4242 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-20 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Prodromou 3 Internet-Draft StatusNet, Inc. 4 Intended status: Experimental September 6, 2012 5 Expires: March 10, 2013 7 HTTP Authentication: Dialback Access Authentication 8 draft-prodromou-dialback-00 10 Abstract 12 This specification defines the Dialback Access Authentication Scheme. 13 It provides a way for HTTP clients to identify an Internet host or 14 account responsible for an HTTP request, and for HTTP servers to 15 verify that identity by sending a token to a declared dialback 16 endpoint. 18 The specification defines a new HTTP authentication scheme, 19 "Dialback". It also defines a new link relation, "dialback", to 20 specify the endpoint for the dialback verification. Finally, it 21 defines the interface for the dialback endpoint. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 10, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 2. Authentication scheme . . . . . . . . . . . . . . . . . . . . . 3 60 3. Dialback endpoint discovery . . . . . . . . . . . . . . . . . . 4 61 4. Dialback verification endpoint . . . . . . . . . . . . . . . . 4 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Host authentication . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Webfinger authentication . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Authentication scheme . . . . . . . . . . . . . . . . . . . 7 67 6.2. Link relation . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Replay attacks . . . . . . . . . . . . . . . . . . . . . . 7 70 7.2. Link discovery . . . . . . . . . . . . . . . . . . . . . . 7 71 7.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . . 8 73 7.5. Data integrity . . . . . . . . . . . . . . . . . . . . . . 8 74 7.6. Denial of service . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 HTTP/1.1 [RFC2616] has an extensible authentication mechanism using 83 the "Authorization" header. Basic and Digest Authentication 84 [RFC2617] are two authentication schemes for HTTP/1.1. OAuth 1.0 85 [RFC5849] is another. 87 All of these authentication schemes assume that the HTTP server is 88 able to validate the authentication credentials. With distributed 89 publishing and social networking applications, however, the security 90 domain may be separate from the resource domain. In addition, the 91 resource and security domains may have no previously-negotiated 92 relationship. 94 With dialback authentication, an HTTP client can authenticate as a 95 host or Webfinger address without creating a previous relationship. 96 The HTTP server verifies the identity using a dialback endpoint 97 specified by the host or Webfinger address. 99 Because dialback authentication requires one or more additional 100 requests from server to client, its intended use is for bootstrapping 101 longer-term relationships, such as dynamic registration of OAuth 102 clients. It can also be useful for single use requests. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. Authentication scheme 112 This spec adds a new Authorization type, "Dialback". 114 The header has the following optional elements: 116 host The host authorizing the request. 118 webfinger The webfinger account authorizing the request. 120 token An opaque value used to confirm the request authorization 122 Exactly one of "host" or "webfinger" is required. 124 "token" is always required. 126 3. Dialback endpoint discovery 128 To validate the token, the server must identify a dialback endpoint 129 for the host or Webfinger address. 131 For a host parameter, the server SHOULD use Web Host Metadata 132 [RFC6415] to find the endpoint. It will have the link relation 133 "dialback". 135 For a webfinger parameter, the server SHOULD use Webfinger 136 [I-D.jones-appsawg-webfinger] to find the endpoint with the link 137 relation "dialback". 139 4. Dialback verification endpoint 141 To confirm, the server makes an HTTP POST request to the dialback 142 endpoint. The request MUST have the Content-Type application/ 143 x-www-url-encoded. 145 The HTTP request has the following parameters. 147 host The host value provided in the original Authorization header. 149 webfinger The webfinger value provided in the original Authorization 150 header. 152 token The token provided in the original Authorization header. 154 url The URL that the original request was made to. 156 date The Date header on the original request. 158 The request MUST include exactly one of "host" or "webfinger". 160 The request MUST include the "token", "url" and "date" parameters. 162 All parameters MUST be encoded in the body of the request. 164 If the token is valid, the endpoint SHOULD return a 200 OK or 204 No 165 Content result. 167 If the token is invalid, the endpoint SHOULD return a 400 Bad Request 168 result. 170 5. Examples 172 5.1. Host authentication 174 o The client sends an HTTP request with an Authorization header: 176 POST /some/endpoint HTTP/1.1 177 Host: photo.example 178 Date: Tue, 28 Aug 2012 09:41:21 -0400 179 Content-Type: application/x-www-url-form-encoded 180 Authorization: Dialback 181 host="checkin.example", 182 token="4430086d" 184 arg1=186&arg2=50 186 Figure 1 188 o The server checks that the Date: header is within an acceptable 189 window (+/- 5 minutes recommended). 191 o The server checks that it hasn't seen this (host, url, token, 192 date) tuple before. 194 o The server discovers a dialback confirmation endpoint at 195 checkin.example. Its rel type is "dialback". 197 o The server posts an HTTP request to confirm the token: 199 POST /dialback HTTP/1.1 200 Host: checkin.example 201 Date: Tue, 28 Aug 2012 09:41:43 -0400 202 Content-Type: application/x-www-url-form-encoded 204 host=checkin.example&\ 205 token=4430086d&\ 206 url=http://photo.example/some/endpoint&\ 207 date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400 209 Figure 2 211 Note: the "\" character is used here to indicate the line wrapping 212 in the request content and is not part of the content itself. 214 o checkin.example returns 200 OK for a confirmation, 4xx for 215 confirmation failure, 5xx for server failure. 217 5.2. Webfinger authentication 219 o The client sends an HTTP request with an Authorization header: 221 GET /some/resource HTTP/1.1 222 Host: photo.example 223 Date: Tue, 28 Aug 2012 09:41:21 -0400 224 Authorization: Dialback 225 webfinger="alice@checkin.example", 226 token="b3265cd5" 228 Figure 3 230 o The server checks that the Date: header is within an acceptable 231 window (+/- 5 minutes recommended). 233 o The server checks that it hasn't seen this (webfinger, url, token, 234 date) tuple before. 236 o The server discovers a dialback confirmation endpoint for 237 alice@checkin.example. Its rel type is "dialback". 239 o The server posts an HTTP request to confirm the token: 241 POST /dialback HTTP/1.1 242 Host: checkin.example 243 Date: Tue, 28 Aug 2012 09:41:43 -0400 244 Content-Type: application/x-www-url-form-encoded 246 webfinger=alice@checkin.example&\ 247 token=b3265cd5&\ 248 url=http://photo.example/some/resource&\ 249 date=Tue%2C%2028%20Aug%202012%2009%3A41%3A21%20-0400 251 Figure 4 253 Note: the "\" character is used here to indicate the line wrapping 254 in the request content and is not part of the content itself. 256 o checkin.example returns 200 OK for a confirmation, 4xx for 257 confirmation failure, 5xx for server failure. 259 6. IANA Considerations 260 6.1. Authentication scheme 262 This specification defines a new HTTP authentication scheme, 263 "Dialback", per HTTP/1.1, part 7: Authentication 264 [I-D.ietf-httpbis-p7-auth] to be registered at 265 http://www.iana.org/assignments/http-authschemes. 267 o Authentication Scheme Name: Dialback 269 o Reference: (this document) 271 6.2. Link relation 273 This specification defines a new link relation type to be registered 274 at http://www.iana.org/assignments/link-relations according to RFC 275 5988 [RFC5988]. 277 o Relation Name: dialback 279 o Description: a dialback token verification endpoint 281 o Reference: (this document) 283 7. Security Considerations 285 7.1. Replay attacks 287 An attacker could capture the Authorization header of a request and 288 replay the header for another payload. 290 To prevent replay attacks, the server MUST NOT accept a request if it 291 has already seen a request with the same host or webfinger, url, 292 token, and date. 294 Servers MAY mitigate storage requirements by rejecting requests with 295 a Date: outside a fixed window. +/- 5 minutes from server time is 296 reasonable. 298 7.2. Link discovery 300 An attacker could use DNS poisoning techniques to provide links to a 301 false dialback endpoint. 303 Clients supporting dialback SHOULD support TLS for host-meta and 304 Webfinger discovery. 306 HTTP servers SHOULD use the TLS endpoint for host-meta and Webfinger. 308 HTTP servers MAY fall back to the unencrypted equivalent. 310 7.3. Endpoint 312 An attacker could use DNS poisoning techniques to provide false 313 responses to requests to the dialback verification endpoint. 315 HTTP clients support dialback SHOULD use TLS for dialback endpoints. 317 HTTP servers SHOULD require valid certificates for dialback 318 endpoints. 320 7.4. Confidentiality 322 The dialback endpoint confirms that the host or Webfinger account is 323 responsible for the HTTP request. 325 An attacker could use brute-force methods to determine if the host or 326 Webfinger account has made an HTTP request to a given URL. 328 The dialback endpoint SHOULD NOT verify requests for dates outside a 329 small window around the current time (+/- five minutes). 331 The dialback endpoint SHOULD use large enough tokens to make brute- 332 force attacks impractical. 334 7.5. Data integrity 336 Dialback authentication does not confirm the contents of the HTTP 337 request. For example, man-in-the-middle attack could replace the 338 contents of a POST request with another payload, which would be 339 verified. 341 Servers SHOULD use TLS to prevent man-in-the-middle attacks. 343 7.6. Denial of service 345 Dialback authentication lets the HTTP client induce the HTTP server 346 to make additional verification requests. 348 By making requests with a host or webfinger parameter referring to a 349 third party, a malicious client can cause extra HTTP requests to that 350 third party. 352 To avoid denial-of-service attacks, HTTP servers SHOULD cache the 353 results of host-meta and Webfinger requests. 355 8. References 357 8.1. Normative References 359 [I-D.ietf-httpbis-p7-auth] 360 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 361 7: Authentication", draft-ietf-httpbis-p7-auth-20 (work in 362 progress), July 2012. 364 [I-D.jones-appsawg-webfinger] 365 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 366 draft-jones-appsawg-webfinger-06 (work in progress), 367 June 2012. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 373 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 374 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 376 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 377 Leach, P., Luotonen, A., and L. Stewart, "HTTP 378 Authentication: Basic and Digest Access Authentication", 379 RFC 2617, June 1999. 381 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 383 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", 384 RFC 6415, October 2011. 386 8.2. Informative References 388 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 389 April 2010. 391 Author's Address 393 Evan Prodromou 394 StatusNet, Inc. 396 Email: evan@status.net 397 URI: http://evan.status.net/