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

<?xml version="1.0"?> 
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc6454 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml'>
]>
<?rfc toc="yes"?> 
<?rfc strict="yes"?> 
<?rfc symrefs="yes" ?> 
<?rfc sortrefs="yes"?> 
<?rfc compact="yes"?> 
<rfc category="info" ipr="trust200811" docName="draft-snell-httpbis-keynego-01"> 
  <front> 
    <title abbrev="HTTP/2.0 Intra-Connection Negotiation"> 
      HTTP/2.0 Intra-Connection Negotiation
    </title> 
 
    <author initials="J.M." surname="Snell" fullname="James M Snell"> 
      <address> 
        <email>jasnell@gmail.com</email> 
      </address> 
    </author> 
    
    <date month="November" year="2013" /> 
 
    <keyword>I-D</keyword> 
    <keyword>http</keyword>
    <keyword>spdy</keyword>
 
    <abstract> 
      <t>
        This memo describes a proposed modification to HTTP/2.0 that 
        introduces the concepts of Intra-Connection Negotiation 
        and Secure Framing.</t> 
    </abstract> 
 
  </front> 
  
  <middle> 

    <section title="Introduction">
      <t>
        HTTP/2.0 Intra-Connection Negotiation allows peers to
        dynamically negotiate agreements (e.g. for cryptographic keys) with 
        an origin (as defined by <xref target="RFC6454" />) from within an 
        established HTTP/2.0 connection.
      </t>

      <t>
        This mechanism would provide a number of important benefits, 
        including:
        <list style="numbers">
          <t>
            The ability to negotiate multiple agreements for one or more 
            origins within a single HTTP/2.0 connection;
          </t>
          <t>
            The ability to revoke and renegotiate agreements on the fly 
            without tearing down and reestablishing the HTTP/2.0 
            connection;
          </t>
          <t>
            Support for multiple negotiation mechanisms, 
            including pre-shared key, etc;
          </t>
        </list>
      </t>
      
    </section>
    
    <section title="Key Negotiation">
      
      <t>
        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:   
        <list style="symbols">
          <t>The ":method" header field is set to "NEGOTIATE".</t>
          <t>The ":scheme" and ":path" header fields MUST be omitted.</t>
          <t>
            The ":authority" header field contains the host and port 
            of the origin for which an agreement is being negotiated.
          </t>
          <t>
            An "id" header field MUST be given specifying the 
            31-bit numeric identifier of the agreement being negotiated.
          </t>
          <t>
            An "algorithm" header field MUST be given specifying the
            IRI identifier of the negotiation / agreement algorithm
            being utilized. 
          </t>
        </list>   
      </t>
      
      <t>
        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.
      </t>

      <section title="Example: Pre-Shared Key">
        
        <t>
          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.
        </t>
        
        <t>
          The initiating peer would send:
        </t>
        
<figure><artwork>
  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
</artwork></figure>

        <t>
          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:
        </t>
        
<figure><artwork>
  HEADERS
    END_STREAM  (0x1)
    END_MESSAGE (0x2)
    END_HEADERS (0x4)
    :status = 200
</artwork></figure>
        
      </section>
            
      <section title="Example: Multi-step Negotiation">
        
        <t>
          Some negotiation algorithms require multiple steps.
          This is accomplished by exchanging multiple messages within
          a single stream.
        </t>
        
        <t>
          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.
        </t>
        
<figure><preamble>Initializing a multi-step negotiation (note that the END_STREAM flag is not set)</preamble><artwork>
  HEADERS
    END_MESSAGE (0x2)
    END_HEADERS (0x4)
    :method = NEGOTIATE
    :authority = example.org
    id = 1
    algorithm = urn:example:algorithm:multistep
    init-param-1 = foo
</artwork></figure>

<figure><preamble>The initializing reponse (again, note that the END_STREAM flag is not set)</preamble><artwork>
  HEADERS
    END_MESSAGE (0x2)
    END_HEADERS (0x4)
    :status = 200
    init-param-A = bar
</artwork></figure>

        <t>
          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.
        </t>
        
      </section>
            
    </section>
    
    <section title="Secure Framing">
      
      <t>
        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.
      </t>
      
      <t>
        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.
      </t>
      
<figure><artwork>
  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                   ...
  +---------------------------------------------------------------+
</artwork></figure>

    </section>
    
    <section title="Secure Tunneling with CONNECT">
      
      <t>
        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:
        <list style="symbols">
          <t>
            First, use the NEGOTIATE method to negotiate an 
            agreement with an origin,
          </t>
          <t>
            Second, use the CONNECT method to establish a 
            tunnel through that origin,
          </t>
          <t>
            Third, use SECURED DATA frames over the connected 
            tunnel.
          </t>
        </list>
      </t>
      
<figure><artwork>
  HEADERS 
    END_STREAM
    :method = NEGOTIATE
    authority = example.org
    id = 1
    ...
  
  HEADERS
    :method = CONNECT
    authority = example.org
  
  DATA 
    SECURED
    Agreement ID = 1
    {Protected Data}
</artwork></figure>
  
    </section>
        
    <section title="Security Considerations">

      <t>TBD. TODO: Need to expand this...</t>

    </section>
        
  </middle> 

  <back>
    <references title="Normative References"> 
  &rfc2119;
  &rfc6454;
    </references>    
        
  </back>
</rfc>