datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

HTTP/2.0 Intra-Connection Negotiation
draft-snell-httpbis-keynego-02

Document type: Active Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2013-11-25
Intended RFC status: Unknown
Other versions: plain text, xml, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: I-D Exists
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                           J. Snell
Internet-Draft
Intended status: Informational                         November 25, 2013
Expires: May 29, 2014

                 HTTP/2.0 Intra-Connection Negotiation
                     draft-snell-httpbis-keynego-02

Abstract

   This memo describes a proposed modification to HTTP/2.0 that
   introduces the concepts of Intra-Connection Negotiation and Secure
   Framing.

Status of This Memo

   This Internet-Draft is submitted to IETF 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 29, 2014.

Copyright Notice

   Copyright (c) 2013 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.

Snell                     Expires May 29, 2014                  [Page 1]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Agreement Negotiation . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Example: Pre-Shared Key . . . . . . . . . . . . . . . . .   3
     2.2.  Example: Multi-step Negotiation . . . . . . . . . . . . .   3
   3.  Secure Framing (Option 1) . . . . . . . . . . . . . . . . . .   4
   4.  Secure Framing (Option 2) . . . . . . . . . . . . . . . . . .   5
   5.  Renegotiation of Agreements . . . . . . . . . . . . . . . . .   5
   6.  Explicit Termination of Agreements  . . . . . . . . . . . . .   5
   7.  The INTEGRITY frame type  . . . . . . . . . . . . . . . . . .   6
   8.  Secure Tunneling with CONNECT . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   HTTP/2.0 Intra-Connection Negotiation allows peers to dynamically
   negotiate agreements (e.g. for cryptographic keys) with an origin (as
   defined by [RFC6454]) from within an established HTTP/2.0 connection.

   This mechanism would provide a number of important benefits,
   including:

   1.  The ability to negotiate multiple agreements for one or more
       origins within a single HTTP/2.0 connection;

   2.  The ability to revoke and renegotiate agreements on the fly
       without tearing down and reestablishing the HTTP/2.0 connection;

   3.  Support for multiple negotiation mechanisms, including pre-shared
       key, etc;

2.  Agreement Negotiation

   Intra-Connection Negotiation is facilitated through the use of a new
   "NEGOTIATE" HTTP pseudo-method.  The HTTP header field mapping for
   the NEGOTIATE method works similarly to that of CONNECT methods, with
   a few notable exceptions:

   o  The ":method" header field is set to "NEGOTIATE".

   o  The ":scheme" and ":path" header fields MUST be omitted.

   o  The ":authority" header field contains the host and port of the
      origin for which an agreement is being negotiated.

Snell                     Expires May 29, 2014                  [Page 2]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

   o  An ":id" header field MUST be given specifying the 31-bit numeric
      identifier of the agreement being negotiated.

   o  An ":algorithm" header field MUST be given specifying the IRI
      identifier of the negotiation / agreement algorithm being
      utilized.

   A complete negotiation consumes a single stream within a connection
   and may consist of one or more distinct "messages" exchanged within
   that stream.  The number of messages required for a negotiation
   depends on the specific algorithm being used.  On HEADERS and DATA
   frames, the currently reserved 0x2 flag is used to signal the end of
   individual messages.  The negotiation is considered complete when the
   stream is closed.  A negotiated agreement cannot be used until the
   negotiation for is completed.

2.1.  Example: Pre-Shared Key

   To illustrate the basic flow of the negotiation protocol, consider
   the simple case where both peers share a common pre-shared secret.
   To simplify the example, we assume that there is need to prove
   possession of the shared secret.

   The initiating peer would send:

   HEADERS
     END_STREAM  (0x1)
     END_MESSAGE (0x2)
     END_HEADERS (0x4)
     :method = NEGOTIATE
     :authority = example.org
     :id = 1
     :algorithm = urn:example:algorithm:psk
     name = Our Shared Key Name

   The flags END_STREAM and END_MESSAGE indicate to the receiving peer
   that no additional messages will be sent for this negotiation.
   Assuming the negotiation is accepted, a simplified response would be:

   HEADERS
     END_STREAM  (0x1)
     END_MESSAGE (0x2)
     END_HEADERS (0x4)
     :status = 200

2.2.  Example: Multi-step Negotiation

Snell                     Expires May 29, 2014                  [Page 3]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

   Some negotiation algorithms require multiple steps.  This is
   accomplished by exchanging multiple messages within a single stream.

   A "message" consists of a combination of a HEADERS frame followed by
   zero or more DATA frames.  The last frame in the message MUST have
   the END_MESSAGE flag set.

   Initializing a multi-step negotiation (note that the END_STREAM flag
   is not set)

   HEADERS
     END_MESSAGE (0x2)
     END_HEADERS (0x4)
     :method = NEGOTIATE
     :authority = example.org
     :id = 1
     :algorithm = urn:example:algorithm:multistep
     init-param-1 = foo

   The initializing reponse (again, note that the END_STREAM flag is not
   set)

   HEADERS
     END_MESSAGE (0x2)
     END_HEADERS (0x4)
     :status = 200
     init-param-A = bar

   Once the initial HEADERS frames are sent, the peers are free to
   exchange as many messages on the stream as necessary to complete the
   negotiation process.  When a peer is done with it's part of the
   negotiation, it will include the END_STREAM flag on the last frame it
   sends.  If the negotiation process fails after the initial HEADERS
   frames are sent, an RST_STREAM frame is used to terminate the
   negotiation process.

3.  Secure Framing (Option 1)

   Obviously, negotiating an agreement is pointless if it cannot be
   subsequently used.  To that end, I propose a modification to the
   existing DATA frame definition.

   Specifically, I propose the introduction of a new AGREEMENT flag
   (0x4).  When set, the flag indicates that the first four bytes of the
   DATA frame payload specify a numeric agreement identifier, and that
   the remaining DATA frame payload has been constructed in accordance
   with the referenced agreement.  They specific structure of that data
   depends entirely on the properties of the agreement identified.

Snell                     Expires May 29, 2014                  [Page 4]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|                    Agreement ID (31)                        |
   +-+-------------------------------------------------------------+
   |                    Protected Payload Data                   ...
   +---------------------------------------------------------------+

4.  Secure Framing (Option 2)

   A potential alternative (and likely better) option for use of a
   negotiated agreement is to move agreement identification out of the
   DATA frame and into a request header field.  For instance:

   HEADERS
     :method = POST
     :authority = example.org
     :agreement = 1

   The presence of the ":agreement" header field in the initial HEADERS
   block indicates that all frames transmitted on the stream (in the
   same direction) are constructed in accordance to the specified
   agreement.

5.  Renegotiation of Agreements

   Depending on the nature of the agreement, it might be possible for
   the requesting peer to renegotiate an agreement with the origin.
   Significant care should be taken here, however, to prevent the
   possibility of downgrade attacks.

   Renegotiation occurs by initiating a new NEGOTIATE request specifying
   an already established agreement identifier.  This new interaction
   could establish new properties, expectations, etc for the agreement.
   The renegotiation is not complete until after both peers successfully
   close the stream, meaning any new negotiated properties do not become
   effective until after renegotiation is complete.

6.  Explicit Termination of Agreements

   It is possible that a mechanism for explicitly revoking or
   terminating an agreement will be needed in some scenarios.
   Termination of an agreement is essentially a form of renegotiation
   and would happen following a similar approach.  One possible method
   for terminating an agreement would be to send something like the
   following:

Snell                     Expires May 29, 2014                  [Page 5]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

   HEADERS
     :method = NEGOTIATE
     :id = 1
     :algorithm: urn:example:algorithm:revoke-agreement

   A downside of this, however, termination would require action on the
   part of the requesting peer and could not be initiated by the origin
   unless we allow the origin to PUSH_PROMISE NEGOTIATE methods (which
   has it's own distinct problems since a client cannot send on a pushed
   stream).

7.  The INTEGRITY frame type

   The INTEGRITY frame (type=0xB) allows a sending peer to insert
   periodic message authentication codes (MACs) into a stream to provide
   integrity and authenticity of a streams content.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MAC (*)                           ...
   +---------------------------------------------------------------+

   The INTEGRITY frame defines the following flags:

   END_STREAM (0x1):  Bit 1 being set indicates that this frame is the
      last that the endpoint will send for the identified stream.
      Setting this flag causes the stream to entire one of "half closed"
      states or "closed" state.

   The payload of the INTEGRITY frame consists of a MAC calculated over
   the payloads of all other frames sent on a stream since either the
   stream was opened or a previous INTEGRITY frame was sent.

   INTEGRITY frames MUST be associated with a stream that is, in turn,
   associated with a negotiated agreement.  The algorithm used to
   gernerate the MAC is determined entirely through use of the NEGOTIATE
   pseudo-method.

8.  Secure Tunneling with CONNECT

   Obviously, the approach described thus far only secures the content
   of DATA frames.  With HTTP, however, there is a significant amount of
   sensitive content carried within HEADERS frames.  To provide a more
   complete solution, the mechanisms described herein can be combined
   with the CONNECT method to create a secure tunnel.  Specifically:

Snell                     Expires May 29, 2014                  [Page 6]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

   o  First, use the NEGOTIATE method to negotiate an agreement with an
      origin,

   o  Second, use the CONNECT method to establish a tunnel through that
      origin,

   o  Third, use SECURED DATA frames over the connected tunnel.

     HEADERS
       END_STREAM
       :method = NEGOTIATE
       :authority = example.org
       :id = 1
     ...

     HEADERS
       :method = CONNECT
       :authority = example.org
       :agreement = 1

     DATA
       {Protected Data}

     INTEGRITY
       {Mac}

     DATA
       {Protected Data}

     ...

9.  Security Considerations

   TBD.  TODO: Need to expand this...

10.  Normative References

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

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
              2011.

Snell                     Expires May 29, 2014                  [Page 7]
Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013

Author's Address

   James M Snell

   Email: jasnell@gmail.com

Snell                     Expires May 29, 2014                  [Page 8]