Network Working Group | M. Sporny |
Internet-Draft | D. Longley |
Intended status: Standards Track | Digital Bazaar |
Expires: December 29, 2015 | June 27, 2015 |
Proof-based Authentication for HTTP Messages
draft-sporny-http-proofs-01
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 new authentication scheme for HTTP that may be used to request and transmit proofs in HTTP headers.
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.
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 December 29, 2015.
Copyright (c) 2015 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.
This protocol extension is intended to provide a simple and standard way for clients and servers to request and transmit proofs to one another.
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.
Fundamentally, proofs need to separate clients that are using the system in good faith versus clients that are attempting to attack the system. In order to do this, a proof must be selected that creates a net economic loss to an attacker of the system while also not making legitimate uses of the system too costly. Proofs must be tuned to the type of protection the server would like to apply to a target resource.
There are many classes of proofs that can be used by a server to identify legitimate clients. Some of these include proof of work, proof of navigation, proof of humanity, and proof of patience. A proof of work typically requires a time consuming mathematical puzzle to be solved, such as prime factorization. A proof of navigation requires tokens to be fetched from a list of servers on a network in a particular order. A proof of humanity requires a problem to be solved, like identifying an emotion in an image, that cannot easily be determined by a computer. A proof of patience requires a client to prove that it has waited for a certain period of time before being allowed to have access to a particular resource on a server.
There are a number of components in a proof that are common between the 'Proof' HTTP Authentication Scheme. This section details the components of a HTTP Proof.
The following section details the proof parameters.
REQUIRED. The `type` field specifies the specific 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.
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.
The "Proof" authentication scheme is based on the model that the client must establish a solution (aka proof) to a challenge posed by the server. The scheme is parameterized enough such that it is not bound to any particular proofing algorithm.
The client is expected to send an Authorization header (as defined in RFC 7235 [RFC7235], Section 4.1) where the "auth-scheme" is "Proof" and the "auth-param" parameters meet the requirements listed in Section 2: The Components of a Proof and the specific parameters for the proof algorithm being used.
Authorization: Proof type=example, foo=bar
Note: The example above uses 'example', 'foo', and 'bar' for purely illustrative purposes. A real example is provided in the section below titled `Proof of Patience`.
A server may notify a client when a protected resource could be accessed by authenticating itself to the server via a proof. To initiate this process, the server will request that the client authenticate itself via a 401 response code. The server should specify which type of proof it would like to have established in the WWW-Authenticate header.
The example below is provided to illustrate a generic proof flow, but the proof parameters are only for illustrative purposes. A more specific example is included in the section titled "Proof of Patience". Given the following request:
GET /examples/protected HTTP/1.1 Host: example.com
The following request for a proof is supplied by the server via the WWW-Authenticate header:
HTTP/1.1 401 Unauthorized Date: Thu, 05 Jul 2015 21:31:41 GMT Content-Length: 1234 Content-Type: text/html WWW-Authenticate: Proof type=example, foo=bar ...
The client performs what is necessary given the proof and then transmits the established proof back to the server via the `Authorization` header.
GET /examples/protected HTTP/1.1 Host: example.com Date: Thu, 05 Jul 2015 21:46:52 GMT Authorization: Proof type=example, foo=bar
The server would then verify the proof and fulfill the request if the proof is valid.
The Proof of Patience algorithm is a type of proof that demonstrates that a client waited for a certain period of time before attempting a request.
REQUIRED. The `type` field must be set to `patience`.
REQUIRED. The `token` field is typically a server-encrypted secret that, when retransmitted to the server after a defined wait period, proves that the client has waited a certain amount of time that was requested by the server. It is important that the server specify the amount of time to wait via the `Retry-After` HTTP Header. The client should wait until the number of seconds specified in `Retry-After` has elapsed. The client should then attempt the initial request again with the contents supplied in the `WWW-Authenticate` copied into a new `Authorization` header.
The contents of the token is specific to the server. For example, the token could contain the requesting IP of the client, the specific HTTP resource the token is tied to, and the time period when the token is valid. The server could then encrypt the data, base64 encode it, and set `token` to the encrypted, base64-encoded value. This ensures that the client cannot tamper with the data and can simply re-transmit the token back to the server after a certain period of time has elapsed to establish the proof of patience.
For example, given the following HTTP request:
POST /examples HTTP/1.1 Host: example.com Date: Thu, 05 Jul 2015 21:31:40 GMT Content-Type: application/json Content-Length: 3 {}
The following request for a proof of patience is supplied by the server via the WWW-Authenticate header:
HTTP/1.1 401 Unauthorized Date: Thu, 05 Jul 2015 21:31:41 GMT Content-Length: 1234 Content-Type: text/html WWW-Authenticate: Proof type=patience, token="jA0EAwMpYIIz/X7aE+u3ADHjb4=" Retry-After: 30 ...
The client then waits for 30 seconds, as specified in the `Retry-After` header, and then transmits the proof of patience back to the server via the `Authorization` header.
POST /examples HTTP/1.1 Host: example.com Date: Thu, 05 Jul 2015 21:32:11 GMT Content-Type: application/json Content-Length: 3 Authorization: Proof type=patience, token="jA0EAwMpYIIz/X7aE+u3ADHjb4=" {}
The server would then decrypt the token and verify that the contents of the token meet the proof of patience requirement. If the verification is successful, the server would fulfill the request.
[I-D.ietf-jose-json-web-algorithms] | Jones, M., "JSON Web Algorithms (JWA)", Internet-Draft draft-ietf-jose-json-web-algorithms-20, 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. |
[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. |
[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. |
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 in the event of a proof of work (e.g. by corrupting the number of iterations to perform). More thinking needs to be put into this section.
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.
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.
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:
Provide a simple test of a Proof of Patience.
The editor would like to thank the following individuals for feedback on and implementations of the specification (in alphabetical order): None yet.
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.
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: patience
Reference: [SCRYPT_RFC_WHEN_IT_EXISTS] Status: active