Network Working Group M. Sporny Internet-Draft Digital Bazaar Intended status: Standards Track August 26, 2014 Expires: February 27, 2015 Cryptographic Proofs for HTTP Messages draft-sporny-http-proofs-00 Abstract For a client to access a particular resource on the Web, a server must expend a certain amount of computational effort to respond to the request. In some cases this computational effort is sizeable and the server may want to only respond to certain clients. For example, in a distributed denial-of-service attack, a server may require all clients to expend a certain amount of resources via a client-run proof-of-work algorithm to throttle the number of incoming requests to a more manageable number. This document details a few HTTP Headers that may be used to request and transmit cryptographic mathematical proofs in HTTP headers. Feedback This specification is a thought exercise that may be submitted on a standardization track in the future. Feedback related to this specification should be sent to msporny@digitalbazaar.com [1]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 27, 2015. Sporny Expires February 27, 2015 [Page 1] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Components of a Proof . . . . . . . . . . . . . . . . . . 3 2.1. Proof Parameters . . . . . . . . . . . . . . . . . . . . 3 2.1.1. algorithm . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. difficulty . . . . . . . . . . . . . . . . . . . . . 3 2.1.3. problem . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.4. solution . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Ambiguous Parameters . . . . . . . . . . . . . . . . . . 4 3. The 'Proof' HTTP Authentication Scheme . . . . . . . . . . . 4 3.1. Authorization Header . . . . . . . . . . . . . . . . . . 4 3.1.1. Initiating Proof Authorization . . . . . . . . . . . 5 3.1.2. Proof Example . . . . . . . . . . . . . . . . . . . . 5 4. The 'Proof' HTTP Header . . . . . . . . . . . . . . . . . . . 5 4.1. Proof Header . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Proof Header Example . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 6 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Security Considerations . . . . . . . . . . . . . . 7 Appendix B. Extensions . . . . . . . . . . . . . . . . . . . . . 7 Appendix C. Test Values . . . . . . . . . . . . . . . . . . . . 8 C.1. Default Test . . . . . . . . . . . . . . . . . . . . . . 8 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix E. IANA Considerations . . . . . . . . . . . . . . . . 8 E.1. Signature Authentication Scheme . . . . . . . . . . . . . 8 E.2. Proof Algorithm Registry . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This protocol extension is intended to provide a simple and standard way for clients and servers to request and transmit mathematical proofs to one another. Sporny Expires February 27, 2015 [Page 2] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 For a client to access a particular resource on the Web, a server must expend a certain amount of computational effort to respond to the request. In some cases this computational effort is sizeable and the server may want to only respond to certain clients. For example, in a distributed denial-of-service attack, a server may require all clients to expend a certain amount of resources via a client-run proof-of-work algorithm to throttle the number of incoming requests to a more manageable number. Editor's note: Explain why proofs of work are interesting for HTTP. Specifically, when you have a public resource where you don't want to authenticate users, but you do want to be able to throttle requests. For example, proxies, URL redirection services, and CDNs could benefit from these sorts of services to mitigate distributed denial- of-service attacks. Systems where all clients slam a particular endpoint, like high-frequency trading systems, could use such a mechanism to purposefully slow incoming requests. Block-chain-like systems could use this mechanism as a native way to access shared databases (like a decentralized ledger). There may be more uses, but those are the ones that inspired this specification. 2. The Components of a Proof There are a number of components in a proof that are common between the 'Proof' HTTP Authentication Scheme and the 'Proof' HTTP Header. This section details the components of a HTTP Proof. 2.1. Proof Parameters The following section details the proof parameters. 2.1.1. algorithm REQUIRED. The `algorithm` field specifies the specific mathematical proof algorithm that is employed by the rest of the parameters. The value of this field SHOULD be a registered algorithm as defined in the Proof Algorithm Registry. 2.1.2. difficulty REQUIRED. The `difficulty` field denotes the level of difficulty that is associated with the `algorithm` field. The value of the field is highly dependent on the algorithm listed in the Proof Algorithm Registry. Sporny Expires February 27, 2015 [Page 3] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 2.1.3. problem OPTIONAL. The `problem` value is used by the server to specify the problem to solve. It is typically used to initialize the proof algorithm. 2.1.4. solution OPTIONAL. The `answer` value is used by the client to specify the answer to the problem posed to it by the server. This field is typically used when sending a calculated answer to the server. 2.2. Ambiguous Parameters If any of the parameters listed above are erroneously duplicated in the associated header field, then the last parameter defined MUST be used. Any parameter that is not recognized as a parameter, or is not well-formed, MUST be ignored. 3. The 'Proof' HTTP Authentication Scheme The "proof" authentication scheme is based on the model that the client must authenticate itself with a mathematical proof that answers the question posed by the server. The scheme is parameterized enough such that it is not bound to any particular proofing algorithm. 3.1. Authorization Header The client is expected to send an Authorization header (as defined in RFC 7235 [RFC7235], Section 4.1 [2]) where the "auth-scheme" is "Proof" and the "auth-param" parameters meet the requirements listed in Section 2: The Components of a Proof. The rest if this section uses the following HTTP request as an example. POST /foo HTTP/1.1 Host: example.org Date: Tue, 07 Aug 2014 20:51:35 GMT Content-Type: application/json Content-Length: 18 {"hello": "world"} Sporny Expires February 27, 2015 [Page 4] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 3.1.1. Initiating Proof Authorization A server may notify a client when a protected resource could be accessed by authenticating itself to the server. To initiate this process, the server will request that the client authenticate itself via a 401 response code. The server may optionally specify which type of proof, difficulty, and problem it would like to have solved in the WWW-Authenticate header. For example: HTTP/1.1 401 Unauthorized Date: Thu, 08 Jun 2014 18:32:30 GMT Content-Length: 1234 Content-Type: text/html WWW-Authenticate: Proof realm="Example", algorithm="scrypt",difficulty="1068",problem="0f43ba8b21" ... 3.1.2. Proof Example The authorization header and proof would be generated as: Authorization: Proof realm="Example",algorithm="scrypt",difficulty="1068", problem="0f43ba8b21",solution="00000000b28fcd2" 4. The 'Proof' HTTP Header The "proof" HTTP Header is based on the model that the client must authenticate itself with a mathematical proof that answers a question that is commonly known to the client and the server. The scheme is parameterized enough such that it is not bound to any particular proofing algorithm. 4.1. Proof Header The sender is expected to transmit a header (as defined in RFC 7230 [RFC7230], Section 3.2 [3]) where the "field-name" is "Proof", and the "field-value" contains one or more "auth-param"s (as defined in RFC 7235 [RFC7235], Section 4.1 [4]) where the "auth-param" parameters meet the requirements listed in Section 2: The Components of a Proof. The rest if this section uses the following HTTP request as an example. Sporny Expires February 27, 2015 [Page 5] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 POST /foo HTTP/1.1 Host: example.org Date: Tue, 07 Aug 2014 20:51:35 GMT Content-Type: application/json Content-Length: 18 {"hello": "world"} 4.1.1. Proof Header Example The proof header would be generated as: Proof: algorithm="scrypt",difficulty="1068", problem="0f43ba8b21",solution="00000000b28fcd2" 5. References 5.1. Normative References [I-D.ietf-jose-json-web-algorithms] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose- json-web-algorithms-20 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 5.2. Informative References [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Sporny Expires February 27, 2015 [Page 6] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. 5.3. URIs [1] http://tools.ietf.org/html/draft-ietf-rfc7235-auth-25#section-4.1 [2] http://tools.ietf.org/html/rfc7230#section-3.2 [3] http://tools.ietf.org/html/rfc7235#section-4.1 Appendix A. Security Considerations Editor's note: Clearly there are a number of concerning reverse denial of service attacks that could be executed over non-HTTPS connections. A simple header injection could keep a client spinning for a very long time. Much more thinking needs to be put into this section. Appendix B. Extensions This specification was designed to be simple, modular, and extensible. Developers that desire more functionality than this specification provides are urged to ensure that an extension specification doesn't already exist before implementing a proprietary extension. If extensions to this specification are made by adding new Proof Parameters, those extension parameters MUST be registered in the Proof Parameter Registry. The registry will be created and maintained at (the suggested URI) http://www.iana.org/assignments/ http-proof-parameters . An example entry in this registry is included below: Proof Parameter: iterations Reference to specification: [SOME_ALGORITHM], Section XYZ. Notes (optional): The `iterations` parameter is used to specify the number of iterations to run on the mathematical proof algorithm. Sporny Expires February 27, 2015 [Page 7] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 Appendix C. Test Values Editor's note: This section should include some scrypt calculation stuff. Editor's note: Some scrypt parameters. All examples use this request: POST /foo?param=value&pet=dog HTTP/1.1 Host: example.com Date: Thu, 05 Jan 2014 21:31:40 GMT Content-Type: application/json Content-Length: 18 {"hello": "world"} C.1. Default Test Editor's Note: A simple scrypt-based proof of work. Appendix D. Acknowledgements The editor would like to thank the following individuals for feedback on and implementations of the specification (in alphabetical order): None yet. Appendix E. IANA Considerations E.1. Signature Authentication Scheme The following entry should be added to the Authentication Scheme Registry located at http://www.iana.org/assignments/http-authschemes Authentication Scheme Name: Proof Reference: [RFC_THIS_DOCUMENT], Section 2. Notes (optional): The Proof scheme is designed for clients to authenticate themselves with a server by performing a mathematical proof. E.2. Proof Algorithm Registry The following initial entries should be added to the Proof Algorithm Registry to be created and maintained at (the suggested URI) http://www.iana.org/assignments/proof-algorithms : Algorithm Name: scrypt Reference: [SCRYPT_RFC_WHEN_IT_EXISTS] Status: active Sporny Expires February 27, 2015 [Page 8] Internet-Draft Cryptographic Proofs for HTTP Messages August 2014 Author's Address Manu Sporny Digital Bazaar 1700 Kraft Drive Suite 2408 Blacksburg, VA 24060 US Phone: +1 540 961 4469 Email: msporny@digitalbazaar.com URI: http://manu.sporny.org/ Sporny Expires February 27, 2015 [Page 9]