One document matched: draft-hallambaker-httpintegrity-02.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
<!ENTITY RFC4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC5056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2965.xml">
<!ENTITY RFC5652 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC3275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3275.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-hallambaker-httpintegrity-02" ipr="trust200902">
<front>
<title abbrev="HTTP Integrity Header">HTTP Integrity Header</title>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date day="14" month="November" year="2012" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>
The HTTP Integrity header provides a means of specifying authentication data in
HTTP requests and responses. This document defines the HTTP integrity header
and specifies its use to authenticate and verify specific parts of an HTTP message.
The means by which the symmetric or asymmetric keys used to authenticate the messages
is outside the scope of this document.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The HTTP Integrity header provides a simple and effective means of authenticating
components of a HTTP message <xref target="RFC2616"/> inband without disclosure
of the secret(s) used as the basis for authentication.
</t>
<t>
This approach has considerable advantages over the traditional approaches of using
HTTP Cookies <xref target="RFC2965"/> containing an authentication secret, embedding authentication data
within the HTTP message content or relying on integrity checks in other protocol
layers.
</t>
<t>
Used in conjunction with an appropriate means of key exchange, the Integrity header
provides an equivalent
security functionality to the use of authentication cookies without the vulnerabilities
intrinsic to the use of static authentication secrets that are disclosed to the
verifying party en-clair to effect verification.
</t>
<t>
Use of a HTTP header to provide authentication information offers a simpler and more flexible
approach than including the authentication information in the message content using
schemes such as PKCS#7/CMS <xref target="RFC5652"/>, XML Signature <xref target="RFC3275"/>
or JSON Signature [TBS].
The chief technical challenge in such specifications being to reliably identify the
exact scope of the data being signed and the form of encoding. Moving the integrity
check to a HTTP header permits the scope of the signature to be defined as the
scope of the HTTP content body and the encoding to be the HTTP transport encoding.
</t>
<t>
Use of the HTTP Intergity header permits the same mutual authentication guarantees
provided by TLS client authentication <xref target="RFC5246"/> without the need to
provision client certificates
and with considerably less complexity.
</t>
<t>
For simplicity, the HTTP Integrity header is strictly limited to identifying a
authentication context, the HTTP transaction item(s) to be authenticated and the
resulting authentication value. The means of establishing the keys and algorithms
that make up the authentication context are outside the scope of this document.
</t>
<t>
In the typical case the authentication context identifier is a ticket (c.f. Kerberos
<xref target="RFC4120"/>)
that contains the account identifier, shared secret(s) and algorithm identifier
required a Web Service protocol or Web Browser Authentication protocol. This
approach permits a stateless server design in which the server does not
store per-account keys.
</t>
<section title="Use in conjunction with TLS.">
<t>
Transport Layer Security (TLS) <xref target="RFC5246"/> provides transport layer
enhancements to protect the confidentiality and integrity of messages.
Use of the HTTP Integrity header compliments the use of TLS security rather
than replacing TLS.
</t>
<t>
While
TLS provides for server and client authentication, these controls are implemented
at the transport layer and access to these features requires the traversal of
a protocol layer boundary that is frequently undesirable or inappropriate.
In particular the API available to the client may not expose the necessary
functionality and many server deployments make use of external cryptographic
accelerator devices that cause the TLS session to be terminated on an entirely
different machine.
Access control requires authorization in addition to authentication. Since
authorization is fundamentally an application layer concern, attempts to carry
authorization data at the transport layer tend to be rather unsatisfactory
requiring both the sender and receiver to cross the protocol layer.
</t>
</section>
<section title="Use in Web Services">
<t>
The HTTP Integrity header was originally developed to simplify implemenatation of
Web Services. Using the SOAP [TBS] approach a Web Service message is encoded in XML [TBS], wrapped in
a SOAP envelope and a WS-Security [TBS] header with an XML Signature [TBS] attached. The whole
package is then attached to a HTTP message as a content payload.
</t>
<t>
This approach involves a considerable degree of complexity and in most cases achieves
nothing more than attaching an authentication value. Carrying the authentication value as a HTTP
header eliminates the need for the SOAP and WS-Security layers entirely. For example,
the following example is a HTTP request in the Omnibroker connection protocol [TBS].
</t>
<figure>
<artwork>
<![CDATA[Post / HTTP/1.1
Host: example.com
Cache-Control: no-store
Content-Type: Application/json;charset=UTF-8
Content-Length: 78
Integrity: content=true;
value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
oB29dgs/ei6ieINZtmvXNCm2NUkWA==
{
"TicketRequest": {
"ChallengeResponse": "TctLOG74cwpm26YNpEibcQ=="}}]]>
</artwork>
</figure>
<t>
A single HTTP message MAY have multiple Integrity headers. This facilitates support
for multi-party transactions in which A submits a transaction to B who countersigns it
and passes it to C who is required to chek that she has proof of agreement by both
A and B.
</t>
<t>
Use of the Integrity header permits the developer to isolate integrity and
authentication checks to a single point of control, as is advised by best security
practice. The security monitor examines a HTTP message, verifies that the
required integrity data is present and correct and only passes the payload on for
processing by the Web Service itself if and only if the verification checks have
been passed.
</t>
</section>
<section title="User Authentication and Authorization">
<t>
The term 'user authentication' is frequently applied indiscriminately
to three separate concerns; credential management, session management and
session continuation.
</t>
<t>
<list>
<t>
Credential management describes the means by which credentials are created,
issued and revoked.
</t>
<t>
Session management describes the means by which a party demonstrates
holdership of a credential to establish an authentication session and
the means by which that authentication session may be terminated.
</t>
<t>
Session continuation describes the means by which a party demonstrates
that a particular transaction is taking place within the context of a
particular authentication session.
</t>
</list>
</t>
<t>
The HTTP Integrity header is designed to support only Session Continuation.
While a session continuation
mechanism is not in itself a solution to the problem of user authentication,
the provision of a robust session continuation mechanism that does not
depend on a bearer token addresses the
most challenging problem
facing the designers of SAML, OpenID and OAUTH.
</t>
</section>
</section>
<section title="Use">
<t>
The Integrity header has two required attributes, the id attribute which
identifies an authentication context and the value attribute which authenticates
the HTTP message in which it is presented within the specified authentication
context and optional attributes specified.
</t>
<t>
The authentication context comprises all the information used to authenticate
and validate HTTP messages. This includes the choice of cryptographic algorithms,
the keys and any protocol options such as the TLS channel binding or protections
against replay attack.
</t>
<t>
Confining the choice of cryptographic algorithm, protocol etc. to the authentication
context eliminates the need for identifiers to specify these attributes
in the Integrity header. Note that while the Integrity header primarily designed
for use with a symmetric key authentication algorithm (MAC), it MAY be employed
to support use of an public key based scheme such as a digital signature.
</t>
<t>
The means by which the authentication context is established are outside
the scope of this document. In the simplest approach, the authentication
context might be passed as in-band plaintext in a prior HTTP exchange.
In a more elaborate scheme the authentication context might be established
using an authentication framework such as Kerberos, SAML or OpenID.
</t>
<t>
The authentication identifier MAY be of any length up to the maximum
permitted by the client and server. This permits an authentication mechanism
to avoid the need to maintain server side per-session state by encoding the server
authentication context as encrypted data in the authentication identifier.
Alternatively, the same approach might be used to avoid the need to maintain
client side state.
</t>
<t>
The optional attributes are used to provide protection against replay attacks,
specify the scope of the authentication check and protect against
TLS man in the middle attacks.
</t>
<section title="Example of Use">
<t>
[The following example is for illustrative purposes only to aid discussion
of the draft and should not be part of a final document.]
</t>
<t>
The Plaintext Authentication exchange supports message authentication using
a MAC and a key exchanged as plaintext in-band. The communication pattern
consists of an initial exchange in which the server returns the
credential and authentication context to the client followed by an
indeterminate number of messages authenticated under that context.
</t>
<section title="Client Request">
<t>
By definition, the protocol exchange is initiated by a client request.
The client advises the server that it supports the use of the scheme
by means of the Support header (in an actual protocol mechanism, this
should probably be some other header but none appears to be a precise match).
</t>
<figure>
<artwork>
<![CDATA[Get / HTTP/1.1
Host: example.com
Support: Plaintext
]]>
</artwork>
</figure>
</section>
<section title="Server Response">
<t>
The server responds with the Authentication Context identifier, the key and
the algorithm to use:
</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 201 OK
Plaintext:
id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
oB29dgs/ei6ieINZtmvXNCm2NUkWA==
key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
alg=HMAC-SHA256
]]>
</artwork>
</figure>
<t>
From this point on the client and server protect their messages using the Integrity
header as shown in the previous example.
</t>
</section>
<section title="Design Notes for Key Exchange">
<t>
While the Plaintext mechanism described above offers better security than the use of HTTP
cookes as bearer tokens, the construction is very much sub optimal.
</t>
<t>
In particular a full key exchange binding should describe the precise manner in
which the scope is and the replay attack protection attributes are fed into the
digest algorithm. It is also desirable for an authentication mechanism to use
separate keys for different purposes, in particular use of separate keys for
requests and responses.
</t>
<t>
As specified, the mechanism only provides protection against passive eavesdropping
attacks if the Plaintext exchange is protected by an adequate confidentiality
protection. For example the use of TLS. A stronger protection MAY be established by
passing the key value through a Diffie Hellman key exchange.
</t>
<t>
In the Diffie Hellman approach, the key establishment would have the following pattern:
<list style="hanging">
<t hangText="1. Client->Server">
Initiate conversation, signal support for DH key exchange option.
</t>
<t hangText="2. Server->Client">
Pass initial Authentication Context identifier and server Diffie Hellman key
parameters.
</t>
<t hangText="3. Client->Server">
Pass client Diffie Hellman parameters, authenticate message under established
key.
</t>
<t hangText="4. Server->Client">
Optionally specify a new Authentication Context identifier to reflect the
fact that the initial aunthentication context has been updated to include the
client information.
</t>
</list>
</t>
<t>
Note that even though the key exchange is only completed in the third message,
all messages following and including the third message are protected.
</t>
<t>
A separate draft describing a lightweight exchange to replace the use of bearer
tokens is planned. Such a draft should probably support both the plaintext and
the Diffie Hellman approaches to ensure that there is no remaining excuse for
http authentication cookie attrocities.
</t>
</section>
</section>
</section>
<section title="Syntax and options">
<t>
The Integrity header has the tag 'Integrity' and takes a sequence of attribute values
as follows:
</t>
<t>
[Insert ABNF here]
</t>
<t>
Four classes of attribute are currently specified:
<list style="hanging">
<t hangText="Required">
Attributes that MUST always be specified. These are the Authentication Context
Identifier attribute 'id' and the Authentication Value attribute 'value'.
</t>
<t hangText="Replay Attack Prevention ">
Attributes used to implement replay prevention mechanisms.
</t>
<t hangText="Scope Attributes">
Attributes that specify the scope over which the authentication value is calculated
</t>
<t hangText="TLS Channel Binding Attributes">
Attributes used to protect against TLS channel rebinding and/or TLS channel
stripping attacks.
</t>
</list>
</t>
<section title="Required Attributes">
<section title="Attribute id=[base64(value)] (required)">
<t>
The ticket attribute identifies the authentication context under which the authentication
value has been generated. The attribute is an opaque sequence of octets in base64 encoding.
</t>
</section>
<section title="Attribute value=[base64(value)] (required)">
<t>
The value attribute specifies the value resulting from applying the authentication context
and nonce (if present) to
the specified scope.
</t>
</section>
<section title="Replay Attack Prevention Attributes">
<t>
Three means of protection against replay attack are supported:
</t>
<t>
<list style="hanging">
<t hangText="Challenge-Response">
Challenge response mechanisms are supported by the nnonce and cnnonce attributes.
The challenger specifies a new nonce using the nnonce attribute which the responder
MUST use to calculate the authentication value. In the case that the nonce value to
be used cannot be determined by the context, an authentication protocol MAY require
the reponder to return the value of the challenge nonce using the rnonce attribute.
</t>
<t>
This approach provides a very high
degree of protection but is limited to sequential protocols in which there is
only one exchange in progress at the same time.
</t>
<t hangText="Counter">
Counter based mechanisms are supported by the count attribute.
The value of a counter MUST increase
for successive transactions within the same transaction stream. Concurrency
MAY be supported by specifying multiple streams but this requires a separate
counter state to be maintained for each transaction stream.
</t>
<t hangText="Time">
Time based approaches are supported by the time attribute. If the value of the
time attribute falls within the permitted acceptance window, the message
MAY be accepted. Otherwise the message MUST be rejected.
</t>
<t>
Using a time based approach avoids the need to maintain state at either the
client or server. The principal disadvantage of this approach being that the
mechanism only protects against a replay attack within a specific time.
</t>
<t>
Another disadvantage to the time based approach is that it relies on the
sender and receiver maintaining a tollerably close time synchronization
over the duration of the transaction and for the latency introduced by the
communication path being tollerably small.
</t>
</list>
</t>
<t>
An authentication protocol MAY employ multiple replay attack protection schemes
within the same exchange. For example a time based approach MAY be employed to
perform an initial check before retreiving the state information needed to
validate a Counter or Challenge Response based mechanism.
</t>
<section title="Attribute nnonce=[base64(value)], rnonce=[base64(value)]">
<t>
The nnonce and rnonce attributes specify a nonce value to be used in combination
with a challenge-response mechanism defined by the specified authentication context.
The nnonce attribute is used to specify a new nonce value, the rnonce attribute
is used to specify a returned nonce value.
</t>
</section>
<section title="Attribute count=[hex(stream),hex(count)]">
<t>
Specifies a stream identifier and a count value that MUST increase monotonically for
successive messages with the same identifier. The stream and count values are specified
as hexadecimal encoded positive integers.
</t>
<section title="Attribute time=[value]">
<t>
Specifies a time value to be used in combination with the specified authentication context.
The format of the time value is determined by the authentication context.
</t>
</section>
</section>
</section>
<section title="Scope Attributes">
<t>
Scope attributes specify which parts of the message are authenticated.
</t>
<t>
Separating the scope attribute from the authentication context permits the scope of the
authentication check to be declared to intermediaries and allows the same authentication
context to be used to authenticate different portions of the HTTP message separately.
</t>
<t>
The scope is specified by the start, header and content attributes. The order in which the
scope attributes are specified is immaterial. The scope is always constructed in the
same order as the elements occur in a HTTP message, i.e. start, headers and content.
</t>
<section title="Attribute content=[true|false]">
<t>
If set true, the specified scope includes the message body. The content transfer encoding
(e.g. chunked) is ignored for the purpose of determining the content.
</t>
</section>
<section title="Attribute start=[true|false]">
<t>
If set true, the specified scope includes the message start line. This being the request Line in
the case of a request and the status line in the case of a response.
</t>
</section>
<section title="Attribute header=[escaped(headers)]">
<t>
Specifies HTTP headers to be included in the specified scope following the
escaped encoding defined in DKIM.
</t>
</section>
</section>
</section>
<section title="TLS Channel Binding Attributes">
<t>
TLS channel binding is used to ensure that the HTTP session is protected by TLS and
to prevent man in the middle attacks against TLS.
</t>
<section title="Attribute tlsu=[value]">
<t>
Specifies the TLS unique channel binding as specified in <xref target="RFC5929"/>.
</t>
</section>
<section title="Attribute tlss=[value]">
<t>
Specifies the TLS server end point channel binding as specified in <xref target="RFC5929"/>.
</t>
</section>
</section>
<section title="Preparing the Input to the Authentication Algorithm">
<t>
[Should specify how the content scope is assembles and how the replay attack
attributes are included within it.]
</t>
</section>
</section>
<section title="Security Considerations">
<section title="Data outside the specified scope is not authenticated">
<t>
The integrity check only extends to the portions of the message that
are within the specified scope.
</t>
</section>
<section title="Truncated Hash Algorithms">
<t>
If the authentication context permits the use of a truncated MAC, it
MUST specify the minimum length of the MAC after truncation and
verifiers MUST reject MAC values shorter than that length as invalid.
</t>
</section>
<section title="Randomness of Secret Keys and nonces">
<t>
The security of any cryptographic protocol relies on the difficulty
of guessing secret keys. Secret keys and nonces SHOULD be generated
using a mechanism that ensures that the range of possible values
is sufficiently large to prevent 'brute force' guessing attacks.
For more information see <xref target="RFC4086"/>.
</t>
</section>
<section title="Weak Ciphers">
<t>
Specification of the cryptographic algorithms used to construct the
Integrity header value is implicit in the authentication context identifier
and thus outside the scope of this specification.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
Add the 'Integrity' header to the list of provisional HTTP headers.
</t>
<t>
[Upgrade if/when this becomes an RFC]
</t>
<t>
Create a registry for Integrity Header attributes. The initial contents of
the registry to be:
</t>
<t>
[Stuff from rest of document.]
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2616;
&RFC2965;
&RFC5246;
&RFC5929;
&RFC4086;
</references>
<references title="Non Normative References">
&RFC5652;
&RFC3275;
&RFC4120;
</references>
</back>
</rfc> | PAFTECH AB 2003-2026 | 2026-04-24 04:05:56 |