idnits 2.17.1 draft-snell-httpbis-keynego-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 25, 2013) is 3798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 319, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft 4 Intended status: Informational November 25, 2013 5 Expires: May 29, 2014 7 HTTP/2.0 Intra-Connection Negotiation 8 draft-snell-httpbis-keynego-02 10 Abstract 12 This memo describes a proposed modification to HTTP/2.0 that 13 introduces the concepts of Intra-Connection Negotiation and Secure 14 Framing. 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 29, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Agreement Negotiation . . . . . . . . . . . . . . . . . . . . 2 49 2.1. Example: Pre-Shared Key . . . . . . . . . . . . . . . . . 3 50 2.2. Example: Multi-step Negotiation . . . . . . . . . . . . . 3 51 3. Secure Framing (Option 1) . . . . . . . . . . . . . . . . . . 4 52 4. Secure Framing (Option 2) . . . . . . . . . . . . . . . . . . 5 53 5. Renegotiation of Agreements . . . . . . . . . . . . . . . . . 5 54 6. Explicit Termination of Agreements . . . . . . . . . . . . . 5 55 7. The INTEGRITY frame type . . . . . . . . . . . . . . . . . . 6 56 8. Secure Tunneling with CONNECT . . . . . . . . . . . . . . . . 6 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 HTTP/2.0 Intra-Connection Negotiation allows peers to dynamically 64 negotiate agreements (e.g. for cryptographic keys) with an origin (as 65 defined by [RFC6454]) from within an established HTTP/2.0 connection. 67 This mechanism would provide a number of important benefits, 68 including: 70 1. The ability to negotiate multiple agreements for one or more 71 origins within a single HTTP/2.0 connection; 73 2. The ability to revoke and renegotiate agreements on the fly 74 without tearing down and reestablishing the HTTP/2.0 connection; 76 3. Support for multiple negotiation mechanisms, including pre-shared 77 key, etc; 79 2. Agreement Negotiation 81 Intra-Connection Negotiation is facilitated through the use of a new 82 "NEGOTIATE" HTTP pseudo-method. The HTTP header field mapping for 83 the NEGOTIATE method works similarly to that of CONNECT methods, with 84 a few notable exceptions: 86 o The ":method" header field is set to "NEGOTIATE". 88 o The ":scheme" and ":path" header fields MUST be omitted. 90 o The ":authority" header field contains the host and port of the 91 origin for which an agreement is being negotiated. 93 o An ":id" header field MUST be given specifying the 31-bit numeric 94 identifier of the agreement being negotiated. 96 o An ":algorithm" header field MUST be given specifying the IRI 97 identifier of the negotiation / agreement algorithm being 98 utilized. 100 A complete negotiation consumes a single stream within a connection 101 and may consist of one or more distinct "messages" exchanged within 102 that stream. The number of messages required for a negotiation 103 depends on the specific algorithm being used. On HEADERS and DATA 104 frames, the currently reserved 0x2 flag is used to signal the end of 105 individual messages. The negotiation is considered complete when the 106 stream is closed. A negotiated agreement cannot be used until the 107 negotiation for is completed. 109 2.1. Example: Pre-Shared Key 111 To illustrate the basic flow of the negotiation protocol, consider 112 the simple case where both peers share a common pre-shared secret. 113 To simplify the example, we assume that there is need to prove 114 possession of the shared secret. 116 The initiating peer would send: 118 HEADERS 119 END_STREAM (0x1) 120 END_MESSAGE (0x2) 121 END_HEADERS (0x4) 122 :method = NEGOTIATE 123 :authority = example.org 124 :id = 1 125 :algorithm = urn:example:algorithm:psk 126 name = Our Shared Key Name 128 The flags END_STREAM and END_MESSAGE indicate to the receiving peer 129 that no additional messages will be sent for this negotiation. 130 Assuming the negotiation is accepted, a simplified response would be: 132 HEADERS 133 END_STREAM (0x1) 134 END_MESSAGE (0x2) 135 END_HEADERS (0x4) 136 :status = 200 138 2.2. Example: Multi-step Negotiation 139 Some negotiation algorithms require multiple steps. This is 140 accomplished by exchanging multiple messages within a single stream. 142 A "message" consists of a combination of a HEADERS frame followed by 143 zero or more DATA frames. The last frame in the message MUST have 144 the END_MESSAGE flag set. 146 Initializing a multi-step negotiation (note that the END_STREAM flag 147 is not set) 149 HEADERS 150 END_MESSAGE (0x2) 151 END_HEADERS (0x4) 152 :method = NEGOTIATE 153 :authority = example.org 154 :id = 1 155 :algorithm = urn:example:algorithm:multistep 156 init-param-1 = foo 158 The initializing reponse (again, note that the END_STREAM flag is not 159 set) 161 HEADERS 162 END_MESSAGE (0x2) 163 END_HEADERS (0x4) 164 :status = 200 165 init-param-A = bar 167 Once the initial HEADERS frames are sent, the peers are free to 168 exchange as many messages on the stream as necessary to complete the 169 negotiation process. When a peer is done with it's part of the 170 negotiation, it will include the END_STREAM flag on the last frame it 171 sends. If the negotiation process fails after the initial HEADERS 172 frames are sent, an RST_STREAM frame is used to terminate the 173 negotiation process. 175 3. Secure Framing (Option 1) 177 Obviously, negotiating an agreement is pointless if it cannot be 178 subsequently used. To that end, I propose a modification to the 179 existing DATA frame definition. 181 Specifically, I propose the introduction of a new AGREEMENT flag 182 (0x4). When set, the flag indicates that the first four bytes of the 183 DATA frame payload specify a numeric agreement identifier, and that 184 the remaining DATA frame payload has been constructed in accordance 185 with the referenced agreement. They specific structure of that data 186 depends entirely on the properties of the agreement identified. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |X| Agreement ID (31) | 192 +-+-------------------------------------------------------------+ 193 | Protected Payload Data ... 194 +---------------------------------------------------------------+ 196 4. Secure Framing (Option 2) 198 A potential alternative (and likely better) option for use of a 199 negotiated agreement is to move agreement identification out of the 200 DATA frame and into a request header field. For instance: 202 HEADERS 203 :method = POST 204 :authority = example.org 205 :agreement = 1 207 The presence of the ":agreement" header field in the initial HEADERS 208 block indicates that all frames transmitted on the stream (in the 209 same direction) are constructed in accordance to the specified 210 agreement. 212 5. Renegotiation of Agreements 214 Depending on the nature of the agreement, it might be possible for 215 the requesting peer to renegotiate an agreement with the origin. 216 Significant care should be taken here, however, to prevent the 217 possibility of downgrade attacks. 219 Renegotiation occurs by initiating a new NEGOTIATE request specifying 220 an already established agreement identifier. This new interaction 221 could establish new properties, expectations, etc for the agreement. 222 The renegotiation is not complete until after both peers successfully 223 close the stream, meaning any new negotiated properties do not become 224 effective until after renegotiation is complete. 226 6. Explicit Termination of Agreements 228 It is possible that a mechanism for explicitly revoking or 229 terminating an agreement will be needed in some scenarios. 230 Termination of an agreement is essentially a form of renegotiation 231 and would happen following a similar approach. One possible method 232 for terminating an agreement would be to send something like the 233 following: 235 HEADERS 236 :method = NEGOTIATE 237 :id = 1 238 :algorithm: urn:example:algorithm:revoke-agreement 240 A downside of this, however, termination would require action on the 241 part of the requesting peer and could not be initiated by the origin 242 unless we allow the origin to PUSH_PROMISE NEGOTIATE methods (which 243 has it's own distinct problems since a client cannot send on a pushed 244 stream). 246 7. The INTEGRITY frame type 248 The INTEGRITY frame (type=0xB) allows a sending peer to insert 249 periodic message authentication codes (MACs) into a stream to provide 250 integrity and authenticity of a streams content. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | MAC (*) ... 256 +---------------------------------------------------------------+ 258 The INTEGRITY frame defines the following flags: 260 END_STREAM (0x1): Bit 1 being set indicates that this frame is the 261 last that the endpoint will send for the identified stream. 262 Setting this flag causes the stream to entire one of "half closed" 263 states or "closed" state. 265 The payload of the INTEGRITY frame consists of a MAC calculated over 266 the payloads of all other frames sent on a stream since either the 267 stream was opened or a previous INTEGRITY frame was sent. 269 INTEGRITY frames MUST be associated with a stream that is, in turn, 270 associated with a negotiated agreement. The algorithm used to 271 gernerate the MAC is determined entirely through use of the NEGOTIATE 272 pseudo-method. 274 8. Secure Tunneling with CONNECT 276 Obviously, the approach described thus far only secures the content 277 of DATA frames. With HTTP, however, there is a significant amount of 278 sensitive content carried within HEADERS frames. To provide a more 279 complete solution, the mechanisms described herein can be combined 280 with the CONNECT method to create a secure tunnel. Specifically: 282 o First, use the NEGOTIATE method to negotiate an agreement with an 283 origin, 285 o Second, use the CONNECT method to establish a tunnel through that 286 origin, 288 o Third, use SECURED DATA frames over the connected tunnel. 290 HEADERS 291 END_STREAM 292 :method = NEGOTIATE 293 :authority = example.org 294 :id = 1 295 ... 297 HEADERS 298 :method = CONNECT 299 :authority = example.org 300 :agreement = 1 302 DATA 303 {Protected Data} 305 INTEGRITY 306 {Mac} 308 DATA 309 {Protected Data} 311 ... 313 9. Security Considerations 315 TBD. TODO: Need to expand this... 317 10. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 323 2011. 325 Author's Address 327 James M Snell 329 Email: jasnell@gmail.com