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]