HTTPsec
| HTTP |
|---|
| Request methods |
| Header fields |
| Status codes |
HTTPsec ("HTTP security") is an authentication scheme for the web protocol HTTP. HTTPsec provides cryptographically strong security at the application layer.
HTTPsec operates within the framework of the HTTP authentication headers. It uses RSA public keys for mutual authentication, and ephemeral Diffie–Hellman key exchange to ensure forward secrecy. The protocol provides mutual authentication and message origin authentication, via protection applied to (1) the integrity of URL, Method, and core HTTP headers, (2) the integrity of the message body, (3) message sequence, and (4) message replays. It optionally provides message body encryption. It does not provide header confidentiality (as messages would no longer be HTTP if their header fields were encrypted) or integrity protection applied to secondary headers (which may be legitimately altered by proxies).
Example with explanation
(Many details are omitted - refer to the full specifications for a complete explanation.)
The terms "requester" and "responder" are used in place of "client" and "server" for the two peers in the transaction. This is to acknowledge that the peers that are being authenticated do not necessarily map one-to-one to client or server devices. For example, a server may host multiple endpoints that are distinctly identified.
There are three possible types of transaction: Initialisation, Continuation, and Challenge.
Initialization transactions
Initialization transactions occur when a requester wishes to initiate a new shared-secret agreement. They are for protocol purposes only and are thus not used to carry message payloads.
- The requester sends its identifier, certificate, and an ephemeral Diffie-Hellman public value, and a random nonce.
- The responder responds with its identifier, certificate, an ephemeral Diffie-Hellman public value, and a separate random nonce encrypted in the RSA public key presented by the requester's certificate. It also signs with its RSA private key all the protocol parameters so far exchanged.
The responder is authenticated in the initialization stage, by the validating the signature against the public key presented by its certificate (authentication freshness is ensured by the requester's nonce). The requester is subsequently authenticated in the continuation stage by the use of HMAC message authentication codes (authentication freshness is ensured by the requester's ability to decrypt the responders's nonce).
The Diffie-Hellman values are used to generate an ephemeral shared secret. From this temporary secret keys are derived identically by both peers. In the initialise response, a token is also returned to reference these secret keys in subsequent continuation messages.
Example initialization request:
HEAD http://alice.example.com/foobar.txt HTTP/1.1
Authorization: httpsec/1.0 initialize
id=bob.example.com
dh=clW9y2X5Vy+5+Ncv5lAI3W9y2X5Vgfe4y+5+Ncv5l...
certificate=http://bob.example.com/my-cert
url=http://alice.example.com/foobar.txt
group=rfc3526#14
nonce=7iqgkzgfdIe0HN35r6met2579yxetyerty7MZW...
Example initialization response:
HTTP/1.1 401 Authorization Required
Expires: Thu, 11 Aug 2005 18:20:42 GMT
Cache-Control: no-transform
WWW-Authenticate: httpsec/1.0 initialize
id=alice.example.com
dh=+NcclW9y2I3W9X5Vy+5v5lAy4X56y+Ncrwrtv5lqe...
certificate=http://alice.example.com/my-cert
token=mCa5tx1vKBY
auth=vpCNmx7MZ7iqgkzIe0HWwfyrOMeqwg0TdbpwefI...
signature=2pX3SNgzWkV3w0W9y2X5V23hhy+5b8DQmo...
(For legibility, the example protocol headers are extended over multiple lines, as per [HTTP][4.2]. Additionally, the values of some initialization directives are lengthy and have therefore been abbreviated, indicated by a terminating ellipsis "...")
Continuation transactions
These transactions benefit from security protections that derive from a shared-secret agreement. They are in all other respects conventional HTTP messages. Continuation transactions can be employed if the requester has at a previous point initialised a shared-secret agreement.
- The requester and responder send a sequence of arbitrary HTTP messages, quoting the token as a reference to the secret keys employed.
- The secret keys are inputs to message authentication codes and message body encryption. As the keys are only known by the two legitimate peers, they are used by the message-receiving peer to validate the message-sending peer, and to decrypt the message body. Additionally, message uniqueness is enforced by an incrementing counter, which is one of various inputs to the message's MAC.
Example of a continuation request:
GET http://alice.example.com/foobar.txt HTTP/1.1
Authorization: httpsec/1.0 continue
token=mCa5tx1vKBY
url=http://alice.example.com/foobar.txt
count=1
mac=zhHPRbxqf3KSMQpjCnpDQmyBnoqiNDMQLjRtMjxUcM=
Example of a continuation response:
HTTP/1.1 200 OK
Date: Thu, 11 Aug 2005 18:20:48 GMT
Expires: Thu, 11 Aug 2005 18:20:48 GMT
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: 1234
Cache-Control: no-transform
Content-Encoding: x-httpsec/1.0-cipher
WWW-Authenticate: httpsec/1.0 continue
count=2
mac=VplDHX3SNgzWkLKgZkjZ+I5wvImOHAMptVSc/Abttps=
digest=V3w0W9y2X5Vy+5+Ncv5lAI3rb8qMlGzrOh9zjHXRHbk=
<entity-body ciphertext bytes>
Note that whilst the sample Continuation request has a GET method and therefore no body, it could equally be a POST, PUT, etc. with a message body and have the same message body protection as shown in the example Continuation response.
Challenge transactions
These transactions allow a responder to attempt to initiate HTTPsec.
- The requester asks for a resource, in a conventional HTTP request.
- The responder answers with a "401 Unauthorized" response, and states its support for HTTPsec.
Example of a challenge response:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: httpsec/1.0 challenge
id=alice.example.com
certificate=http://alice.example.com/my-cert
Algorithms
The algorithms employed by HTTPsec are RSA, OAEP, PSS, HMAC, SHA-256, and AES-256. The protocol does not allow algorithm negotiation.