Network Working Group J. Snell
Internet-Draft August 4, 2012
Intended status: Informational
Expires: February 5, 2013
HTTP/2.0 Discussion: SPDY In-Session Key Negotiation
draft-snell-httpbis-keynego-00
Abstract
This memo describes a proposed modification to SPDY that introduces
the concepts of In-Session Key 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 February 5, 2013.
Copyright Notice
Copyright (c) 2012 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Snell Expires February 5, 2013 [Page 1]
Internet-Draft application/merge-patch August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-Session Key Negotiation . . . . . . . . . . . . . . . . . . 3
3. Secure Framing . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example: Pre-shared Secret Key . . . . . . . . . . . . . . . . 6
5. Example: Diffie-Helmman Exchange . . . . . . . . . . . . . . . 7
6. Example: In-Session TLS . . . . . . . . . . . . . . . . . . . 8
7. Example: Server-Initiated Key Exchange . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Snell Expires February 5, 2013 [Page 2]
Internet-Draft application/merge-patch August 2012
1. Introduction
In-Session Key Negotiation allows endpoints to dynamically negotiate
cryptographic keys after a SPDY Session has already been established
through the exchange of one or more KEY_NEGO control frames.
There are a number of benefits to such a mechanism:
1. The ability to negotiate multiple keys over a single TCP/IP
connection.
2. The ability to renegotiate keys on the fly without tearing down
and reestablishing the TCP/IP connection.
3. Key Negotiation is intermediary friendly while remaining secure.
Both Hop-by-Hop and End-to-End negotiation schemes would be
possible.
4. Support for multiple key negotiation mechanisms, including pre-
shared key.
5. Support for server-initiated key negotiation .. allowing
responses to be secured on-demand by servers even if the client
did not initiate the secure request. This allows servers to
enforce secure communication with the client.
6. The ability to target specific key negotiations at individual
hosts.
7. The possibility of using negotiated keys as an alternative to
basic and digest authentication.
TODO: More coverage on the needs, benefits
2. In-Session Key Negotiation
The KEY_NEGO control frame is used to negotiate cryptographic keys
for use by either endpoint within an established SPDY Session.
The KEY_NEGO Frame
+---------------------------------+
|1| version | KEY_NEGO |
+---------------------------------+
| Flags (8) | LENGTH (24) |
+---------------------------------|
|X| KEY_ID (31) |
+---------------------------------+
|X| Associated-To-Stream-ID (31) |
+---------------------------------+
| ALG_ID(16) | SEQ(8) | |
+------------------------+ |
| (HEADERS BLOCK) |
| |
Snell Expires February 5, 2013 [Page 3]
Internet-Draft application/merge-patch August 2012
Flags: Flags related to this frame. Valid flags are:
0x01 = FLAG_EXPECTS_RESPONSE - Indicates that the sender is
expecting to receive a KEY_NEGO frame in response to this one.
0x02 = FLAG_DONE - Indicates that this is the last KEY_NEGO frame
the sender will send for this key negotiation sequence.
0x04 = FLAG_WAIT - Indicates that the sender will be sending
additional KEY_NEGO frames and that the recipient should wait for
those before responding.
0x08 = FLAG_ERROR - Indicates that an error has occurred within
the key negotiation sequence and that the headers contains the
details of the error.
0x10 = FLAG_VOID - Indicates that the sender wishes for a
previously negotiated key to be voided, making it unavailable for
further use within the same SPDY Session.
Length: The length is the number of bytes which follow the length
field in the frame. For KEY_NEGO frames, this is 7 bytes plus the
length of Headers block.
KEY_ID: The 31-bit identifier for the key being negotiated. KEY_NEGO
frames initiated by the client MUST have an odd-numbered ID.
KEY_NEGO frames initiated by the server MUST have an even-numbered
ID.
Associated-To-Stream-ID: The 31-bit identifier for a Stream for which
this key is to be associated. If this key is independent of all
other streams, it should be 0.
If a key is associated with a given stream, the key is destroyed when
the stream is concluded.
ALG_ID: The 16-bit identifier of the key negotiation algorithm being
performed.
SEQ: An 8-bit unsigned integer incremented for each KEY_NEGO frame
exchanged for a given KEY_ID.
HEADERS BLOCK: The block of headers carried as part of the KEY_NEGO
frame.
Within any single SPDY session, multiple KEY_NEGO exchanges may
occur. However, once the range of possible KEY_ID's has been
exhausted, no further negotiation is possible within that session.
3. Secure Framing
Obviously, negotiating a key is pointless if it cannot be
Snell Expires February 5, 2013 [Page 4]
Internet-Draft application/merge-patch August 2012
subsequently used to secure communications. For this, we can either
modify the existing SPDY frames defined in
[draft-mbelshe-httpbis-spdy-00] or introduce additional extension
Control Frames. Currently, this memo adopts the latter approach.
Three new Control Frames would be introduced:
o SYN_SEC_STREAM
o SYN_SEC_REPLY
o INTEGRITY
The SYN_SEC_STREAM and SYN_SEC_REPLY control frames are generally
identical to the existing SYN_STREAM and SYN_REPLY frames, but
include an additional 31-bit KEY_ID field that identifies the
negotiated key used to encrypt the contents of both the block of
headers (within the SYN_* frame as well as subsequent HEADERS frames)
and all data frames within the stream.
SYN_SEC_STREAM Control Frame:
+------------------------------------+
|1| version | SYN_SEC_STREAM |
+------------------------------------+
| Flags (8) | Length (24 bits) |
+------------------------------------+
|X| Stream-ID (31bits) |
+------------------------------------+
|X| Associated-To-Stream-ID (31bits) |
+------------------------------------+
| Pri|Unused | Slot |X| KEY_ID (31) |
+------------------------------------|
| (Headers Block) |
| ... |
SYN_SEC_REPLY:
+------------------------------------+
|1| version | SYN_SEC_REPLY |
+------------------------------------+
| Flags (8) | Length (24 bits) |
+------------------------------------+
|X| Stream-ID (31bits) |
+------------------------------------+
|X| KEY-ID (31) |
+------------------------------------+
| (Headers Block) |
| ... |
Additional, a new Stream Integrity Control frame is proposed that
Snell Expires February 5, 2013 [Page 5]
Internet-Draft application/merge-patch August 2012
allows a sender to periodically insert a checksum into the stream.
The checksum is calculated over the bytes of all HEADERS and Data
frames sent since (and including) the initial SYN_* control frame or
the previously sent INTEGRITY frame. If a key is used to generate
the digest, the KEY_ID field can be used to reference the key. If
the SYN_SEC_STREAM or SYN_SEC_REPLY contained a KEY_ID, then the
digest is encrypted using the identified key..
INTEGRITY Frame:
+----------------------------------+
|0| version | INTEGRITY |
+----------------------------------+
|X| Stream-ID (31bits) |
+----------------------------------+
|X| KEY-ID (31bits) |
+----------------------------------+
| ALG_ID (8) | SEQ(8) |Length (24) |
+----------------------------------+
| Digest |
+----------------------------------+
If the recipient receives an INTEGRITY frame that does not validate,
it can choose to terminate the stream with a RST_STREAM.
4. Example: Pre-shared Secret Key
Consider a scenario where user, Tom, is accessing a service on host
"example.org". As part of the out of band registration process, a
shared secret key is generated and shared by Tom and the hosted
service. This key is tied to Tom's user account name: "tom".
In this example, only a single KEY_NEGO frame needs to be exchanged,
sent by Tom to the Server to identify the name of the pre-shared key.
Snell Expires February 5, 2013 [Page 6]
Internet-Draft application/merge-patch August 2012
Tom Server
| |
|=====================>|
| 1) SYN |
|<=====================|
| 2) SYN_ACK |
|=====================>|
| 3) ACK |
| |
|=====================>|
| 4) KEY_NEGO |
| ID=1 |
| ALG_ID=1 (PSK) |
| FLAGS=0x02 |
| SEQ=1 |
| :host=example.org |
| :key=tom |
| |
|=====================>|
| 5) SYN_SEC_STREAM |
| ID=1 |
| KEY_ID=1 |
| :method=POST |
| :host=example.org |
| |
|=====================>|
| 6) DATA |
| ID=1 |
| (encrypted data) |
| |
| ...
The SYN_SEC_STREAM establishes a secured stream that references the
established key, and all headers and data transmitted would be
encrypted using the identified key.
The server MAY choose to respond with either a SYN_REPLY or
SYN_SEC_REPLY.
5. Example: Diffie-Helmman Exchange
Multi-step key negotiation mechanisms, such as the popular Diffie-
Hellman mechanism, can also be implemented through the exchange of
multiple KEY_NEGO frames.
Snell Expires February 5, 2013 [Page 7]
Internet-Draft application/merge-patch August 2012
Tom Server
| |
|=====================>|
| 1) SYN |
|<=====================|
| 2) SYN_ACK |
|=====================>|
| 3) ACK |
| |
|=====================>|
| 4) KEY_NEGO |
| ID=1 |
| ALG_ID=2 (DH) |
| FLAGS=0x01 |
| SEQ=1 |
| :host=example.org |
| :p={p} |
| :g={g} |
| :A={A} |
| |
|<=====================|
| 5) KEY_NEGO |
| ID=1 |
| ALG_ID=2 (DH) |
| FLAGS=0x02 |
| SEQ=2 |
| :B={B} |
| |
|<====================>|
| STREAM / REPLY |
| (secured w/Key 1) |
| |
6. Example: In-Session TLS
KEY_NEGO frames can even be orchestrated to mimic the existing TLS-
Handshake protocol:
Tom Server
| |
|=====================>|
| 1) SYN |
|<=====================|
| 2) SYN_ACK |
|=====================>|
| 3) ACK |
| |
Snell Expires February 5, 2013 [Page 8]
Internet-Draft application/merge-patch August 2012
|=====================>|
| 4) KEY_NEGO | // CLIENT_HELLO
| ID=1 |
| ALG_ID=3 (IS-TLS) |
| FLAGS=0x01 |
| SEQ=1 |
| :host=example.org |
| :gmt_unix_time={X} |
| :random:... |
| :session:... |
| :ciphers:... |
| :extensions:... |
| |
|<=====================|
| 5) KEY_NEGO | // SERVER_HELLO
| ID=1 |
| ALG_ID=3 |
| FLAGS=0x04 |
| SEQ=2 |
| :random:... |
| :session:... |
| :cipher:... |
| :extensions:... |
| :cert:... |
| ... | <==| Certificate
| | <==| ServerKeyExchange
| | <==| CertificateRequest
|<=====================|
| 6) KEY_NEGO | // SERVER_FINISHED
| ID=1 |
| ALG_ID=3 |
| FLAGS=0x2 |
| | |==> Certificate
| | |==> ClientKeyExchange
| | |==> CertificateVerify
| | <==> Change Cipher Spec
|=====================>|
| 7) KEY_NEGO | // CLIENT_FINISHED
| ID=1 |
| ALG_ID=3 |
| FLAGS=0x2 |
| |
|<====================>|
| STREAM / REPLY |
| (secured w/Key 1) |
| |
Snell Expires February 5, 2013 [Page 9]
Internet-Draft application/merge-patch August 2012
7. Example: Server-Initiated Key Exchange
One of the more interesting cases enabled by In-Session Key
Negotiation is the possibility of server-initiated protection. That
is, if a client opens an insecured stream with the server, the server
could choose to upgrade that stream on-the-fly by initiating a
KEY_NEGO exchange and responding with a SYN_SEC_REPLY. All content
returned by the server would be encrypted, even if the request was
not.
Tom Server
| |
|=====================>|
| 1) SYN |
|<=====================|
| 2) SYN_ACK |
|=====================>|
| 3) ACK |
| |
|=====================>|
| 4) SYN_STREAM |
| ID=1 |
| :method=GET |
| :path=/ |
| :host=example.org |
| |
|<=====================|
| 5) KEY_NEGO |
| ID=2 |
| ASSOC_STREAM_ID=1 |
| ALG_ID=1 |
| FLAGS=0x2 |
| :key="tom" |
| |
|<=====================|
| 6) SYN_SEC_REPLY |
| ID=1 |
| KEY_ID=2 |
| ... |
| |
8. Security Considerations
TBD. TODO: Need to expand this...
Negotiated Keys should likely be tied to a same-origin policy. The
same negotiated key could not be used with multiple origins...
Snell Expires February 5, 2013 [Page 10]
Internet-Draft application/merge-patch August 2012
instead, require the client to negotiate a separate key for each
origin unless the specific key negotiation protocol allows multi-
origin operation.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
James M Snell
Email: jasnell@gmail.com
Snell Expires February 5, 2013 [Page 11]