Internet DRAFT - draft-sporny-http-proofs
draft-sporny-http-proofs
Network Working Group M. Sporny
Internet-Draft D. Longley
Intended status: Standards Track Digital Bazaar
Expires: December 30, 2015 June 28, 2015
Proof-based Authentication for HTTP Messages
draft-sporny-http-proofs-01
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 new
authentication scheme for HTTP that may be used to request and
transmit 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 December 30, 2015.
Sporny & Longley Expires December 30, 2015 [Page 1]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Components of a Proof . . . . . . . . . . . . . . . . . . 3
2.1. Proof Parameters . . . . . . . . . . . . . . . . . . . . 3
2.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Ambiguous Parameters . . . . . . . . . . . . . . . . . . 4
3. The 'Proof' HTTP Authentication Scheme . . . . . . . . . . . 4
3.1. The Authorization Header . . . . . . . . . . . . . . . . 4
3.1.1. Initiating Proof Authorization . . . . . . . . . . . 4
4. Proof of Patience . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Proof of Patience Parameters . . . . . . . . . . . . . . 5
4.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. token . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Proof of Patience Example . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 7
5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Security Considerations . . . . . . . . . . . . . . 8
Appendix B. Extensions . . . . . . . . . . . . . . . . . . . . . 8
Appendix C. Test Values . . . . . . . . . . . . . . . . . . . . 8
C.1. Default Test . . . . . . . . . . . . . . . . . . . . . . 8
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Appendix E. IANA Considerations . . . . . . . . . . . . . . . . 9
E.1. Signature Authentication Scheme . . . . . . . . . . . . . 9
E.2. Proof Algorithm Registry . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This protocol extension is intended to provide a simple and standard
way for clients and servers to request and transmit proofs to one
another.
Sporny & Longley Expires December 30, 2015 [Page 2]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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.
2. The Components of a Proof
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.
2.1. Proof Parameters
The following section details the proof parameters.
2.1.1. type
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.
Sporny & Longley Expires December 30, 2015 [Page 3]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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 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.
3.1. The 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 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`.
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 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:
Sporny & Longley Expires December 30, 2015 [Page 4]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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.
4. Proof of Patience
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.
4.1. Proof of Patience Parameters
4.1.1. type
REQUIRED. The `type` field must be set to `patience`.
4.1.2. token
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
Sporny & Longley Expires December 30, 2015 [Page 5]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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.
4.2. Proof of Patience Example
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.
Sporny & Longley Expires December 30, 2015 [Page 6]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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.
[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.
Sporny & Longley Expires December 30, 2015 [Page 7]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
5.3. URIs
[1] http://tools.ietf.org/html/draft-ietf-rfc7235-auth-25#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 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.
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.
Appendix C. Test Values
Provide a simple test of a Proof of Patience.
C.1. Default Test
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.
Sporny & Longley Expires December 30, 2015 [Page 8]
Internet-DraftProof-based Authentication for HTTP Messages June 2015
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: patience
Reference: [SCRYPT_RFC_WHEN_IT_EXISTS] Status: active
Authors' Addresses
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/
Dave
Digital Bazaar
1700 Kraft Drive
Suite 2408
Blacksburg, VA 24060
US
Phone: +1 540 961 4469
Email: dlongley@digitalbazaar.com
URI: https://github.com/dlongley
Sporny & Longley Expires December 30, 2015 [Page 9]
