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.

Table of Contents

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

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:

• The ":method" header field is set to "NEGOTIATE".
• The ":scheme" and ":path" header fields MUST be omitted.
• The ":authority" header field contains the host and port of the origin for which an agreement is being negotiated.
• An "id" header field MUST be given specifying the 31-bit numeric identifier of the agreement being negotiated.
• 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.

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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |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:

• First, use the NEGOTIATE method to negotiate an agreement with an origin,
• Second, use the CONNECT method to establish a tunnel through that origin,
• 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

Author's Address