One document matched: draft-snell-httpbis-keynego-01.txt

Differences from draft-snell-httpbis-keynego-00.txt

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


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

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 23, 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 23, 2014                  [Page 1]

Internet-Draft    HTTP/2.0 Intra-Connection Negotiation    November 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Key Negotiation . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Example: Pre-Shared Key . . . . . . . . . . . . . . . . .   3
     2.2.  Example: Multi-step Negotiation . . . . . . . . . . . . .   3
   3.  Secure Framing  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Secure Tunneling with CONNECT . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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

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





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


   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

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





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


   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

   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.

   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



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


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|                    Agreement ID (31)                        |
   +-+-------------------------------------------------------------+
   |                    Protected Payload Data                   ...
   +---------------------------------------------------------------+

4.  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:

   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

     DATA
       SECURED
       Agreement ID = 1
       {Protected Data}

5.  Security Considerations

   TBD.  TODO: Need to expand this...

6.  Normative References

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





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


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

Author's Address

   James M Snell

   Email: jasnell@gmail.com











































Snell                     Expires May 23, 2014                  [Page 6]