]> Digital Bazaar

1700 Kraft Drive Suite 2408 Blacksburg VA 24060 US +1 540 961 4469 msporny@digitalbazaar.com http://manu.sporny.org/

Digital Bazaar

1700 Kraft Drive Suite 2408 Blacksburg VA 24060 US +1 540 961 4469 dlongley@digitalbazaar.com https://github.com/dlongley

Security HTTP authentication mathematical proof proof of work proof of patience proof of navigation 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 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, 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.

&rfc2119; &rfc4648; &rfc6376; &rfc7230; &rfc7235; &jwa; &rfc2617; &rfc3230; &rfc3447; &rfc5246; &rfc6749;

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. 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.

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