idnits 2.17.1 draft-sporny-http-proofs-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 28, 2015) is 3224 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 328 -- Looks like a reference, but probably isn't: '2' on line 156 == Unused Reference: 'I-D.ietf-jose-json-web-algorithms' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC3230' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-40) exists of draft-ietf-jose-json-web-algorithms-20 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3230 (Obsoleted by RFC 9530) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sporny 3 Internet-Draft D. Longley 4 Intended status: Standards Track Digital Bazaar 5 Expires: December 30, 2015 June 28, 2015 7 Proof-based Authentication for HTTP Messages 8 draft-sporny-http-proofs-01 10 Abstract 12 For a client to access a particular resource on the Web, a server 13 must expend a certain amount of computational effort to respond to 14 the request. In some cases this computational effort is sizeable and 15 the server may want to only respond to certain clients. For example, 16 in a distributed denial-of-service attack, a server may require all 17 clients to expend a certain amount of resources via a client-run 18 proof-of-work algorithm to throttle the number of incoming requests 19 to a more manageable number. This document details a new 20 authentication scheme for HTTP that may be used to request and 21 transmit proofs in HTTP headers. 23 Feedback 25 This specification is a thought exercise that may be submitted on a 26 standardization track in the future. Feedback related to this 27 specification should be sent to msporny@digitalbazaar.com [1]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 30, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. The Components of a Proof . . . . . . . . . . . . . . . . . . 3 62 2.1. Proof Parameters . . . . . . . . . . . . . . . . . . . . 3 63 2.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Ambiguous Parameters . . . . . . . . . . . . . . . . . . 4 65 3. The 'Proof' HTTP Authentication Scheme . . . . . . . . . . . 4 66 3.1. The Authorization Header . . . . . . . . . . . . . . . . 4 67 3.1.1. Initiating Proof Authorization . . . . . . . . . . . 4 68 4. Proof of Patience . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Proof of Patience Parameters . . . . . . . . . . . . . . 5 70 4.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1.2. token . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. Proof of Patience Example . . . . . . . . . . . . . . . . 6 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 5.2. Informative References . . . . . . . . . . . . . . . . . 7 76 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Appendix A. Security Considerations . . . . . . . . . . . . . . 8 78 Appendix B. Extensions . . . . . . . . . . . . . . . . . . . . . 8 79 Appendix C. Test Values . . . . . . . . . . . . . . . . . . . . 8 80 C.1. Default Test . . . . . . . . . . . . . . . . . . . . . . 8 81 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 8 82 Appendix E. IANA Considerations . . . . . . . . . . . . . . . . 9 83 E.1. Signature Authentication Scheme . . . . . . . . . . . . . 9 84 E.2. Proof Algorithm Registry . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 This protocol extension is intended to provide a simple and standard 90 way for clients and servers to request and transmit proofs to one 91 another. 93 For a client to access a particular resource on the Web, a server 94 must expend a certain amount of computational effort to respond to 95 the request. In some cases this computational effort is sizeable and 96 the server may want to only respond to certain clients. For example, 97 in a distributed denial-of-service attack, a server may require all 98 clients to expend a certain amount of resources via a client-run 99 proof-of-work algorithm to throttle the number of incoming requests 100 to a more manageable number. 102 Fundamentally, proofs need to separate clients that are using the 103 system in good faith versus clients that are attempting to attack the 104 system. In order to do this, a proof must be selected that creates a 105 net economic loss to an attacker of the system while also not making 106 legitimate uses of the system too costly. Proofs must be tuned to 107 the type of protection the server would like to apply to a target 108 resource. 110 There are many classes of proofs that can be used by a server to 111 identify legitimate clients. Some of these include proof of work, 112 proof of navigation, proof of humanity, and proof of patience. A 113 proof of work typically requires a time consuming mathematical puzzle 114 to be solved, such as prime factorization. A proof of navigation 115 requires tokens to be fetched from a list of servers on a network in 116 a particular order. A proof of humanity requires a problem to be 117 solved, like identifying an emotion in an image, that cannot easily 118 be determined by a computer. A proof of patience requires a client 119 to prove that it has waited for a certain period of time before being 120 allowed to have access to a particular resource on a server. 122 2. The Components of a Proof 124 There are a number of components in a proof that are common between 125 the 'Proof' HTTP Authentication Scheme. This section details the 126 components of a HTTP Proof. 128 2.1. Proof Parameters 130 The following section details the proof parameters. 132 2.1.1. type 134 REQUIRED. The `type` field specifies the specific proof algorithm 135 that is employed by the rest of the parameters. The value of this 136 field SHOULD be a registered algorithm as defined in the Proof 137 Algorithm Registry. 139 2.2. Ambiguous Parameters 141 If any of the parameters listed above are erroneously duplicated in 142 the associated header field, then the last parameter defined MUST be 143 used. Any parameter that is not recognized as a parameter, or is not 144 well-formed, MUST be ignored. 146 3. The 'Proof' HTTP Authentication Scheme 148 The "Proof" authentication scheme is based on the model that the 149 client must establish a solution (aka proof) to a challenge posed by 150 the server. The scheme is parameterized enough such that it is not 151 bound to any particular proofing algorithm. 153 3.1. The Authorization Header 155 The client is expected to send an Authorization header (as defined in 156 RFC 7235 [RFC7235], Section 4.1 [2]) where the "auth-scheme" is 157 "Proof" and the "auth-param" parameters meet the requirements listed 158 in Section 2: The Components of a Proof and the specific parameters 159 for the proof algorithm being used. 161 Authorization: Proof type=example, foo=bar 163 Note: The example above uses 'example', 'foo', and 'bar' for purely 164 illustrative purposes. A real example is provided in the section 165 below titled `Proof of Patience`. 167 3.1.1. Initiating Proof Authorization 169 A server may notify a client when a protected resource could be 170 accessed by authenticating itself to the server via a proof. To 171 initiate this process, the server will request that the client 172 authenticate itself via a 401 response code. The server should 173 specify which type of proof it would like to have established in the 174 WWW-Authenticate header. 176 The example below is provided to illustrate a generic proof flow, but 177 the proof parameters are only for illustrative purposes. A more 178 specific example is included in the section titled "Proof of 179 Patience". Given the following request: 181 GET /examples/protected HTTP/1.1 182 Host: example.com 184 The following request for a proof is supplied by the server via the 185 WWW-Authenticate header: 187 HTTP/1.1 401 Unauthorized 188 Date: Thu, 05 Jul 2015 21:31:41 GMT 189 Content-Length: 1234 190 Content-Type: text/html 191 WWW-Authenticate: Proof type=example, foo=bar 193 ... 195 The client performs what is necessary given the proof and then 196 transmits the established proof back to the server via the 197 `Authorization` header. 199 GET /examples/protected HTTP/1.1 200 Host: example.com 201 Date: Thu, 05 Jul 2015 21:46:52 GMT 202 Authorization: Proof type=example, foo=bar 204 The server would then verify the proof and fulfill the request if the 205 proof is valid. 207 4. Proof of Patience 209 The Proof of Patience algorithm is a type of proof that demonstrates 210 that a client waited for a certain period of time before attempting a 211 request. 213 4.1. Proof of Patience Parameters 215 4.1.1. type 217 REQUIRED. The `type` field must be set to `patience`. 219 4.1.2. token 221 REQUIRED. The `token` field is typically a server-encrypted secret 222 that, when retransmitted to the server after a defined wait period, 223 proves that the client has waited a certain amount of time that was 224 requested by the server. It is important that the server specify the 225 amount of time to wait via the `Retry-After` HTTP Header. The client 226 should wait until the number of seconds specified in `Retry-After` 227 has elapsed. The client should then attempt the initial request 228 again with the contents supplied in the `WWW-Authenticate` copied 229 into a new `Authorization` header. 231 The contents of the token is specific to the server. For example, 232 the token could contain the requesting IP of the client, the specific 233 HTTP resource the token is tied to, and the time period when the 234 token is valid. The server could then encrypt the data, base64 235 encode it, and set `token` to the encrypted, base64-encoded value. 236 This ensures that the client cannot tamper with the data and can 237 simply re-transmit the token back to the server after a certain 238 period of time has elapsed to establish the proof of patience. 240 4.2. Proof of Patience Example 242 For example, given the following HTTP request: 244 POST /examples HTTP/1.1 245 Host: example.com 246 Date: Thu, 05 Jul 2015 21:31:40 GMT 247 Content-Type: application/json 248 Content-Length: 3 250 {} 252 The following request for a proof of patience is supplied by the 253 server via the WWW-Authenticate header: 255 HTTP/1.1 401 Unauthorized 256 Date: Thu, 05 Jul 2015 21:31:41 GMT 257 Content-Length: 1234 258 Content-Type: text/html 259 WWW-Authenticate: Proof type=patience, token="jA0EAwMpYIIz/X7aE+u3ADHjb4=" 260 Retry-After: 30 262 ... 264 The client then waits for 30 seconds, as specified in the `Retry- 265 After` header, and then transmits the proof of patience back to the 266 server via the `Authorization` header. 268 POST /examples HTTP/1.1 269 Host: example.com 270 Date: Thu, 05 Jul 2015 21:32:11 GMT 271 Content-Type: application/json 272 Content-Length: 3 273 Authorization: Proof type=patience, token="jA0EAwMpYIIz/X7aE+u3ADHjb4=" 275 {} 277 The server would then decrypt the token and verify that the contents 278 of the token meet the proof of patience requirement. If the 279 verification is successful, the server would fulfill the request. 281 5. References 283 5.1. Normative References 285 [I-D.ietf-jose-json-web-algorithms] 286 Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose- 287 json-web-algorithms-20 (work in progress), January 2014. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 293 Encodings", RFC 4648, October 2006. 295 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 296 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 297 September 2011. 299 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 300 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 301 2014. 303 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 304 (HTTP/1.1): Authentication", RFC 7235, June 2014. 306 5.2. Informative References 308 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 309 Leach, P., Luotonen, A., and L. Stewart, "HTTP 310 Authentication: Basic and Digest Access Authentication", 311 RFC 2617, June 1999. 313 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 314 3230, January 2002. 316 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 317 Standards (PKCS) #1: RSA Cryptography Specifications 318 Version 2.1", RFC 3447, February 2003. 320 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 321 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 323 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 324 6749, October 2012. 326 5.3. URIs 328 [1] http://tools.ietf.org/html/draft-ietf-rfc7235-auth-25#section-4.1 330 Appendix A. Security Considerations 332 Editor's note: Clearly there are a number of concerning reverse 333 denial of service attacks that could be executed over non-HTTPS 334 connections. A simple header injection could keep a client spinning 335 for a very long time in the event of a proof of work (e.g. by 336 corrupting the number of iterations to perform). More thinking needs 337 to be put into this section. 339 Appendix B. Extensions 341 This specification was designed to be simple, modular, and 342 extensible. Developers that desire more functionality than this 343 specification provides are urged to ensure that an extension 344 specification doesn't already exist before implementing a proprietary 345 extension. 347 If extensions to this specification are made by adding new Proof 348 Parameters, those extension parameters MUST be registered in the 349 Proof Parameter Registry. The registry will be created and 350 maintained at (the suggested URI) http://www.iana.org/assignments/ 351 http-proof-parameters . An example entry in this registry is included 352 below: 354 Proof Parameter: iterations 355 Reference to specification: [SOME_ALGORITHM], Section XYZ. 356 Notes (optional): The `iterations` parameter is used to specify the number 357 of iterations to run on the mathematical proof algorithm. 359 Appendix C. Test Values 361 Provide a simple test of a Proof of Patience. 363 C.1. Default Test 365 Appendix D. Acknowledgements 367 The editor would like to thank the following individuals for feedback 368 on and implementations of the specification (in alphabetical order): 369 None yet. 371 Appendix E. IANA Considerations 373 E.1. Signature Authentication Scheme 375 The following entry should be added to the Authentication Scheme 376 Registry located at http://www.iana.org/assignments/http-authschemes 378 Authentication Scheme Name: Proof 379 Reference: [RFC_THIS_DOCUMENT], Section 2. 380 Notes (optional): The Proof scheme is designed for clients to 381 authenticate themselves with a server by performing a mathematical 382 proof. 384 E.2. Proof Algorithm Registry 386 The following initial entries should be added to the Proof Algorithm 387 Registry to be created and maintained at (the suggested URI) 388 http://www.iana.org/assignments/proof-algorithms : 390 Algorithm Name: patience 391 Reference: [SCRYPT_RFC_WHEN_IT_EXISTS] Status: active 393 Authors' Addresses 395 Manu Sporny 396 Digital Bazaar 397 1700 Kraft Drive 398 Suite 2408 399 Blacksburg, VA 24060 400 US 402 Phone: +1 540 961 4469 403 Email: msporny@digitalbazaar.com 404 URI: http://manu.sporny.org/ 406 Dave 407 Digital Bazaar 408 1700 Kraft Drive 409 Suite 2408 410 Blacksburg, VA 24060 411 US 413 Phone: +1 540 961 4469 414 Email: dlongley@digitalbazaar.com 415 URI: https://github.com/dlongley