[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Standards Track                       November 14, 2012
Expires: May 18, 2013


                         HTTP Integrity Header
                   draft-hallambaker-httpintegrity-02

Abstract

   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.

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 May 18, 2013.

Copyright Notice

   Copyright (c) 2012 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Hallam-Baker              Expires May 18, 2013                  [Page 1]

Internet-Draft            HTTP Integrity Header            November 2012


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Use in conjunction with TLS. . . . . . . . . . . . . . . .  4
     1.2.  Use in Web Services  . . . . . . . . . . . . . . . . . . .  4
     1.3.  User Authentication and Authorization  . . . . . . . . . .  5
   2.  Use  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Example of Use . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  Client Request . . . . . . . . . . . . . . . . . . . .  7
       2.1.2.  Server Response  . . . . . . . . . . . . . . . . . . .  7
       2.1.3.  Design Notes for Key Exchange  . . . . . . . . . . . .  7
   3.  Syntax and options . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Required Attributes  . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Attribute id=[base64(value)] (required)  . . . . . . .  9
       3.1.2.  Attribute value=[base64(value)] (required) . . . . . .  9
       3.1.3.  Replay Attack Prevention Attributes  . . . . . . . . .  9
         3.1.3.1.  Attribute nnonce=[base64(value)],
                   rnonce=[base64(value)] . . . . . . . . . . . . . . 10
         3.1.3.2.  Attribute count=[hex(stream),hex(count)] . . . . . 10
       3.1.4.  Scope Attributes . . . . . . . . . . . . . . . . . . . 10
         3.1.4.1.  Attribute content=[true|false] . . . . . . . . . . 11
         3.1.4.2.  Attribute start=[true|false] . . . . . . . . . . . 11
         3.1.4.3.  Attribute header=[escaped(headers)]  . . . . . . . 11
     3.2.  TLS Channel Binding Attributes . . . . . . . . . . . . . . 11
       3.2.1.  Attribute tlsu=[value] . . . . . . . . . . . . . . . . 11
       3.2.2.  Attribute tlss=[value] . . . . . . . . . . . . . . . . 11
     3.3.  Preparing the Input to the Authentication Algorithm  . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     4.1.  Data outside the specified scope is not authenticated  . . 12
     4.2.  Truncated Hash Algorithms  . . . . . . . . . . . . . . . . 12
     4.3.  Randomness of Secret Keys and nonces . . . . . . . . . . . 12
     4.4.  Weak Ciphers . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Non Normative References . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13











Hallam-Baker              Expires May 18, 2013                  [Page 2]

Internet-Draft            HTTP Integrity Header            November 2012


1.  Introduction

   The HTTP Integrity header provides a simple and effective means of
   authenticating components of a HTTP message [RFC2616] inband without
   disclosure of the secret(s) used as the basis for authentication.

   This approach has considerable advantages over the traditional
   approaches of using HTTP Cookies [RFC2965] containing an
   authentication secret, embedding authentication data within the HTTP
   message content or relying on integrity checks in other protocol
   layers.

   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.

   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
   [RFC5652], XML Signature [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.

   Use of the HTTP Intergity header permits the same mutual
   authentication guarantees provided by TLS client authentication
   [RFC5246] without the need to provision client certificates and with
   considerably less complexity.

   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.

   In the typical case the authentication context identifier is a ticket
   (c.f.  Kerberos [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.






Hallam-Baker              Expires May 18, 2013                  [Page 3]

Internet-Draft            HTTP Integrity Header            November 2012


1.1.  Use in conjunction with TLS.

   Transport Layer Security (TLS) [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.

   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.

1.2.  Use in Web Services

   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.

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
















Hallam-Baker              Expires May 18, 2013                  [Page 4]

Internet-Draft            HTTP Integrity Header            November 2012


   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=="}}

   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.

   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.

1.3.  User Authentication and Authorization

   The term 'user authentication' is frequently applied indiscriminately
   to three separate concerns; credential management, session management
   and session continuation.

      Credential management describes the means by which credentials are
      created, issued and revoked.

      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.

      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.

   The HTTP Integrity header is designed to support only Session
   Continuation.  While a session continuation mechanism is not in



Hallam-Baker              Expires May 18, 2013                  [Page 5]

Internet-Draft            HTTP Integrity Header            November 2012


   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.


2.  Use

   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.

   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.

   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.

   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.

   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.

   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.

2.1.  Example of Use

   [The following example is for illustrative purposes only to aid
   discussion of the draft and should not be part of a final document.]



Hallam-Baker              Expires May 18, 2013                  [Page 6]

Internet-Draft            HTTP Integrity Header            November 2012


   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.

2.1.1.  Client Request

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

   Get / HTTP/1.1
   Host: example.com
   Support: Plaintext


2.1.2.  Server Response

   The server responds with the Authentication Context identifier, the
   key and the algorithm to use:

HTTP/1.1 201 OK
Plaintext:
    id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
      j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
      oB29dgs/ei6ieINZtmvXNCm2NUkWA==
    key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
    alg=HMAC-SHA256


   From this point on the client and server protect their messages using
   the Integrity header as shown in the previous example.

2.1.3.  Design Notes for Key Exchange

   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.

   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



Hallam-Baker              Expires May 18, 2013                  [Page 7]

Internet-Draft            HTTP Integrity Header            November 2012


   responses.

   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.

   In the Diffie Hellman approach, the key establishment would have the
   following pattern:

   1. Client->Server  Initiate conversation, signal support for DH key
      exchange option.

   2. Server->Client  Pass initial Authentication Context identifier and
      server Diffie Hellman key parameters.

   3. Client->Server  Pass client Diffie Hellman parameters,
      authenticate message under established key.

   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.

   Note that even though the key exchange is only completed in the third
   message, all messages following and including the third message are
   protected.

   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.


3.  Syntax and options

   The Integrity header has the tag 'Integrity' and takes a sequence of
   attribute values as follows:

   [Insert ABNF here]

   Four classes of attribute are currently specified:

   Required  Attributes that MUST always be specified.  These are the
      Authentication Context Identifier attribute 'id' and the
      Authentication Value attribute 'value'.




Hallam-Baker              Expires May 18, 2013                  [Page 8]

Internet-Draft            HTTP Integrity Header            November 2012


   Replay Attack Prevention   Attributes used to implement replay
      prevention mechanisms.

   Scope Attributes  Attributes that specify the scope over which the
      authentication value is calculated

   TLS Channel Binding Attributes  Attributes used to protect against
      TLS channel rebinding and/or TLS channel stripping attacks.

3.1.  Required Attributes

3.1.1.  Attribute id=[base64(value)] (required)

   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.

3.1.2.  Attribute value=[base64(value)] (required)

   The value attribute specifies the value resulting from applying the
   authentication context and nonce (if present) to the specified scope.

3.1.3.  Replay Attack Prevention Attributes

   Three means of protection against replay attack are supported:

   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.

      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.

   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.







Hallam-Baker              Expires May 18, 2013                  [Page 9]

Internet-Draft            HTTP Integrity Header            November 2012


   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.

      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.

      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.

   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.

3.1.3.1.  Attribute nnonce=[base64(value)], rnonce=[base64(value)]

   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.

3.1.3.2.  Attribute count=[hex(stream),hex(count)]

   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.

3.1.3.2.1.  Attribute time=[value]

   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.

3.1.4.  Scope Attributes

   Scope attributes specify which parts of the message are
   authenticated.




Hallam-Baker              Expires May 18, 2013                 [Page 10]

Internet-Draft            HTTP Integrity Header            November 2012


   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.

   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.

3.1.4.1.  Attribute content=[true|false]

   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.

3.1.4.2.  Attribute start=[true|false]

   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.

3.1.4.3.  Attribute header=[escaped(headers)]

   Specifies HTTP headers to be included in the specified scope
   following the escaped encoding defined in DKIM.

3.2.  TLS Channel Binding Attributes

   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.

3.2.1.  Attribute tlsu=[value]

   Specifies the TLS unique channel binding as specified in [RFC5929].

3.2.2.  Attribute tlss=[value]

   Specifies the TLS server end point channel binding as specified in
   [RFC5929].

3.3.  Preparing the Input to the Authentication Algorithm

   [Should specify how the content scope is assembles and how the replay
   attack attributes are included within it.]





Hallam-Baker              Expires May 18, 2013                 [Page 11]

Internet-Draft            HTTP Integrity Header            November 2012


4.  Security Considerations

4.1.  Data outside the specified scope is not authenticated

   The integrity check only extends to the portions of the message that
   are within the specified scope.

4.2.  Truncated Hash Algorithms

   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.

4.3.  Randomness of Secret Keys and nonces

   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 [RFC4086].

4.4.  Weak Ciphers

   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.


5.  IANA Considerations

   Add the 'Integrity' header to the list of provisional HTTP headers.

   [Upgrade if/when this becomes an RFC]

   Create a registry for Integrity Header attributes.  The initial
   contents of the registry to be:

   [Stuff from rest of document.]


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,



Hallam-Baker              Expires May 18, 2013                 [Page 12]

Internet-Draft            HTTP Integrity Header            November 2012


              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, July 2010.

6.2.  Non Normative References

   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.


Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com
















Hallam-Baker              Expires May 18, 2013                 [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/