CCNx Key Exchange Protocol Version 1.0
draft-wood-icnrg-ccnxkeyexchange-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Marc Mosko , Ersin Uzun , Christopher A. Wood | ||
Last updated | 2016-07-08 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-wood-icnrg-ccnxkeyexchange-00
icnrg M. Mosko Internet-Draft E. Uzun Intended status: Experimental C. Wood Expires: January 9, 2017 PARC July 08, 2016 CCNx Key Exchange Protocol Version 1.0 draft-wood-icnrg-ccnxkeyexchange-00 Abstract This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) protocol. The CCNxKE protocol allows two peers to establish a shared, forward-secure key for secure and confidential communication. The protocol is designed to prevent eavesdropping, tampering, and message forgery between two peers. It is also designed to minimize the number of rounds required to establish a shared key. In the worst case, it requires two RTTs between a consumer and producer to establish a shared key. In the best case, one RTT is required before sending any application data. This document outlines how to derive the keys used to encrypt traffic for a session and shows how session information is exchanged between a consumer and producer using message encapsulation. Status of This Memo This Internet-Draft is submitted 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 January 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Mosko, et al. Expires January 9, 2017 [Page 1] Internet-Draft CCNxKE July 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 5. CCNxKE Overview . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Connection Establishment Latency . . . . . . . . . . . . 7 5.2. Connection Migration and Resumption . . . . . . . . . . . 7 5.3. Re-Transmissions, Timeouts, and Replay Prevention . . . . 8 5.4. Loss Sensitivity . . . . . . . . . . . . . . . . . . . . 8 6. The CCNxKE Protocol . . . . . . . . . . . . . . . . . . . . . 8 6.1. Round Overview . . . . . . . . . . . . . . . . . . . . . 9 6.2. Round 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Round 2 . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Round 3 . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Alternative Exchanges . . . . . . . . . . . . . . . . . . . . 17 7.1. One-RTT Exchange . . . . . . . . . . . . . . . . . . . . 17 8. PSK Mode and Session Resumption . . . . . . . . . . . . . . . 18 9. Secret Derivation . . . . . . . . . . . . . . . . . . . . . . 19 9.1. SourceCookie Derivation . . . . . . . . . . . . . . . . . 20 9.2. MoveToken Derivation . . . . . . . . . . . . . . . . . . 20 9.3. SessionID and PreSharedKey Properties, Derivation, and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . 22 9.5. Secret Generation and Lifecycle . . . . . . . . . . . . . 23 10. Re-Key Message . . . . . . . . . . . . . . . . . . . . . . . 24 11. Application Data Protocol . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Mosko, et al. Expires January 9, 2017 [Page 2] Internet-Draft CCNxKE July 2016 1. Introduction DISCLAIMER: This is a WIP draft of CCNxKE and has not yet seen rigorous security analysis. Ephemeral sessions similar to those enabled by TLS 1.3 [TLS13], QUIC [QUIC], and DTLS 1.2 [DTLS12] are needed for some CCN exchanges between consumers and producers. Currently, there does not exist a standard way to establish these sessions. Thus, the primary goal of the CCNxKE protocol is to provide privacy and data integrity between two CCN-enabled peers (e.g., a consumer and producer engaged in session-based communication). It is built on the CCNx 1.0 protocol and only relies upon standard Interest and Content Objects as a vehicle for communication. The CCNxKE protocol is used to bootstrap session-based communication, wherein traffic is encapsulated and encrypted using symmetric-key cryptography for transmission between two endpoints (i.e., a consumer and producer). The CCNxKE protocol enables this form of communication by establishing shared state, i.e., shared, ephemeral, and forward-secure symmetric keys. This protocol has the following four main properties: - Each peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], ECDSA [ECDSA], etc.). Server authentication is mandatory whereas mutual authentication is optional. - The negotiation of a forward-secure shared secret is protected from eavesdroppers and man-in-the-middle (MITM) attacks. - The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication. - The state of a CCNxKE session can be securely migrated between an endpoint performing authentication and that which provides content using a "move token." This allows authentication and authorization to be separated from encryption for a session, enabling different systems to complete these steps. Usage of CCNxKE is entirely independent of upper-layer application protocols. Session-based communication via encapsulation and encryption enables secure, confidential, and authenticated communication between two peers. One advantage of this protocol is that it facilitates the creation and use of ephemeral CCN Interest and Content Objects. CCNxKE also introduces a new type of cookie based on reverse hash chains [HASHCHAIN] to help limit the amount of significant server Mosko, et al. Expires January 9, 2017 [Page 3] Internet-Draft CCNxKE July 2016 work done in response to a client or consumer Interest. TCP-based protocols, such as TLS [TLS13], use the TCP 3-way handshake for such proof. UDP-based protocols, such as QUIC [QUIC] and DTLS 1.2 [DTLS12], use an optional session address token or cookie that must be presented by the client (consumer) to prove ownership of an address during a key exchange procedure. Without source addresses, our cookie technique ensures that the same entity which requested server information, e.g., the public configuration data, is the same entity that wishes to complete a key exchange. The main contribution of this work is adapting key exchange principles to the pull-based CCNx communication model. CCNxKE only assumes that a consumer knows a first name prefix to initiate the key exchange. The first Interest does not need to be a CCNxKE packet -- the producer can signal back to the consumer that it requires CCNxKE before progressing. This specification does not subsume other ICN-compliant key exchange protocols. Nor does its existence imply that all encryption in an ICN must be based on sessions. It was designed specifically to solve the problem of session-based encryption in ICN. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms are used: Consumer/Client: The CCN consumer initiating the CCNxKE key exchange via a first Interest. Producer/Server: The CCN producer receiving or accepting the CCNxKE key exchange request request Interest. Sender: An endpoint that originates a message. Receiver: An endpoint that is receiving messages. Peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion. Connection: A network path of n >= 1 hops between the consumer and producer. Mosko, et al. Expires January 9, 2017 [Page 4] Internet-Draft CCNxKE July 2016 Endpoint: Either the consumer or producer of the connection. Handshake: A series of message exchanges between two peers that is used to perform a task (e.g., perform key exchange and derivation). Session: An association between a consumer and a producer resulting from a CCNxKE handshake. DH: A Diffie Hellman key exchange procedure [RFC2631] [DH]. Key Share: One half of the shared-secret provided by one peer performing a DH key exchange. Forward-secure: The property that compromising any long-term secrets (e.g., cryptographic keys) does not compromise any session keys derived from those long-term secrets. CONFIG information: A data structure created by a producer which contains long-term cryptographic material and associated information needed by a client to initiate a key-exchange with the producer. HELLO exchange: An exchange between a consumer and producer wherein the consumer retrieves the CONFIG information from the producer. Payload: The payload section of a CCNxMessage as defined in [CCNxMessages]. KEPayload: A payload for information used in the CCNxKE protocol which is a generic key-value store. The KEPayload is _not_ the CCNxMessage payload. CCNxName: A CCNxName as defined in [CCNxMessages]. Semi-static: Short-term. Short-term Secret (SS): A secret which is derived from the server's semi-static DH share and the client's fresh DH share. Forward-secure Secret (FSK): A secret which is derived from fresh (i.e., generated on demand at random) DH shares from both the consumer and producer for the given connection. HKDF: Hash-based key-derivation function [RFC5869]. Mosko, et al. Expires January 9, 2017 [Page 5] Internet-Draft CCNxKE July 2016 2. Goals The goals of the CCNxKE protocol, in order of priority, are as follows: 1. Cryptographic security: CCNxKE should be used to securely establish a session and all related shared secrets between two peers. Cryptographic properties of interest include: (a) forward-secure session key derivation and (b) (state and computational) denial-of-service prevention at the producer (see [RFC4987]) that is no worse than DTLS 1.2 [DTLS12]}. For property (a), different keys (and relevant algorithm parameters such as IVs) are established for each communication direction, i.e., from consumer to producer and producer to consumer. For property (b), we use a new type of stateless cookie inspired by that of DTLS 1.2. 2. Interoperability: Independent programmers should be able to develop applications utilizing CCNxKE that can successfully exchange cryptographic parameters without knowledge of one another's code. 3. Extensibility: CCNxKE seeks to provide a framework into which new public key and symmetric key methods and algorithms can be incorporated without breaking backwards compatibility or requiring all clients to implement new functionality. Moreover, the protocol should be able to support a variety of peer authentication protocols, e.g., EAP-TLS, EAP-PWD, or a simple challenge-response protocol. 4. Relative efficiency: CCNxKE tries to create sessions with minimal computation, bandwidth, and message complexity. In particular, it seeks to create sessions with as few end-to-end round trips as possible, and also provide support for accelerated session establishment and resumption when appropriate. At most 2 round- trip-times (RTTs) should be used to establish a session key, with the possibility of 1-RTT accelerated starts and resumption. 3. Scope This document and the CCNxKE protocol are influenced by the TLS 1.3 [TLS13], QUIC [QUIC], and DTLS 1.2 [DTLS12] protocols. The reader, however, does not need a detailed understanding of those protocols to understand this document. Moreover, where appropriate, references to related protocols are made for brevity and technical clarity. This document is intended primarily for readers who will be implementing the protocol and for those doing cryptographic analysis of it. The Mosko, et al. Expires January 9, 2017 [Page 6] Internet-Draft CCNxKE July 2016 specification has been written with this in mind and it is intended to reflect the needs of those two groups. This document is not intended to supply any details of service definition or of interface definition, although it does cover select areas of policy as they are required for the maintenance of solid security. 4. Presentation Language This document uses a presentation language of remote calls (i.e. packet messages) similar to the format used by TLS [TLS13]. 5. CCNxKE Overview 5.1. Connection Establishment Latency CCNxKE operates in three rounds, where each round requires a single RTT to complete. The full execution of the protocol therefore requires 2 RTTs before a session is fully established. The full version is used when consumers have no a priori information about the producer. An accelerated one round version is used when the consumer has valid configuration information and a source cookie from the producer; this variant requires 1 RTT before a session is established. 5.2. Connection Migration and Resumption CCN end hosts lack the notion of addresses. Thus, the producer endpoint for a given execution of the CCNxKE protocol is one which can authoritatively serve as the owner of a particular namespace. For example, a consumer may wish to establish a session with a producer who owns the /company/foo namespace. The specific end host which partakes in the protocol instance is not specified, by virtue of the fact that all CCNxKE messages are based on well-defined names. This enables the producer end-host which partakes in the protocol to change based on the name of the CCNxKE messages. Consequently, to maintain correctness, it is important that a single execution of the protocol operates within the same trusted context; this does not mean that the same producer end-host is required to participate in all three steps of the protocol. Rather, it means that the end-host responding to a CCNxKE message must be trusted by the consumer to complete the exchange. CCNxKE is designed to enable this sort of producer migration. For example, a consumer may use an initial name like '/parc/ index.html' that works like an IP any cast address and could got to one of several systems. CCNxKE allows the responding endpoint to Mosko, et al. Expires January 9, 2017 [Page 7] Internet-Draft CCNxKE July 2016 include a localized name to ensure that subsequent messages from the consumer come back to the same producer. CCNxKE also allows the key exchange peer to securely hand-off the session to a content producer peer via another name and session token once the client is authenticated and keying material is exchanged. 5.3. Re-Transmissions, Timeouts, and Replay Prevention CCNxKE timeouts and retransmissions are handled using the approach in [RFC6347]. One primary difference is that timer values may need to be adjusted (elongated) due to prefix shifts and the need for a producer to transfer security information between different machines. Replay attack prevention is also an optional feature, and if used, MAY be done using one of the following two approaches at the receiver (producer): - IPSec AH [RFC4302] and ESP [RFC4303] style replay detection based on sliding windows and monotonically increasing sequence numbers for windows. Note that the sliding window inherently limits the performance of the protocol to the window size, since only a finite number of messages may be received within a given window (based on the window size). - The optimized anti-replay algorithm of [RFC6479]. 5.4. Loss Sensitivity CCNxKE messages are transferred using standard CCN Interest and Content Objects and are therefore subject to loss as any datagram. This means that traffic encrypted with keys derived from CCNxKE must be stateless. They cannot depend on in-order arrival. This problem is solved by two mechanisms: (1) by prohibiting stream ciphers of any kind and (2) adding sequence numbers to each message that allow the receiver to identify and use the correct cryptographic state to decrypt the message. Moreover, sequence numbers permit anti-replay mechanisms similar to those used in DTLS [DTLS12] as mentioned above. 6. The CCNxKE Protocol This section describes the CCNxKE protocol in detail at the message level. The specific encoding of those messages is given later. CCNxKE could be adapted to different wire format encodings, such as those used by the NDN protocol. The following assumptions are made about peers participating in the CCNxKE protocol: Mosko, et al. Expires January 9, 2017 [Page 8] Internet-Draft CCNxKE July 2016 - Consumers know the namespace prefix of the producer for which they wish to execute the CCNxKE protocol. - CCNxKE protocol information is carried in a distinguished field outside of the payload of CCN messages. This is done to distinguish key exchange material with application data in a message. This is necessary for 0 RTT packets that carry both keying material and application payload. - CCNxKE does not require any special behavior of intermediate systems to forward packets. - CCNxKE packets generally should not be cached for significant periods of time, as use normal protocol methods to limit caching. Part of this is achieved through the use of consumer-specific nonces in names. 6.1. Round Overview CCNxKE is composed of three rounds. The purpose of each round is described below. - Round 1: Perform a bare HELLO exchange to obtain the extensions (parameters) for the key exchange provided by the producer and a source cookie to prove ownership of the "source" of the request. - Round 2: Perform the initial FULL-HELLO exchange to establish a forward-secure key used for future communication, i.e., Interest and Content Object exchanges in the context of the newly established session. - Round 3: Send the first bit of application data and (optionally) transfer resumption cookie(s) from the producer to the consumer. Conceptually, there are two secrets established during a single execution of CCNxKE: - Static Secret (SS): A secret which is derived in one of two ways: (a) from the client and server ephemeral key shares and (b) from the server's semi-static share and the client's ephemeral key share. Keying material derived from SS in option (a) is not forward secure. - Ephemeral Secret (ES): A secret which is derived from both the client and server ephemeral key shares. Mosko, et al. Expires January 9, 2017 [Page 9] Internet-Draft CCNxKE July 2016 Depending on the mode in which CCNxKE is used, these secrets can be established in a variety of ways. Key derivation details are outlined in Section Section 9. All secrets are derived with the appropriate amount of randomness [RFC4086]. An overview of the messages sent in each of the three rounds to establish and use these secrets is shown in Figure Figure 1 below. This diagram omits some parts of each message for brevity. Consumer Producer HELLO: + SourceChallenge I[/prefix/random-1] --------> HELLO-REJECT: + Timestamp + SourceCookie + pinned-prefix* + ServerChallenge* + ServerConfiguration* CO[/prefix/random-1] <--------- FULL-HELLO: + ClientKeyShare + SourceCookie + SourceProof + MoveChallenge + Timestamp I[/pinned-prefix/random-2] --------> HELLO-ACCEPT: + ServerKeyShare + SessionID + [CertificateRequest*] + [CertificateVerify*] + [MovePrefix*, MoveToken*] + [Finished] CO[/pinned-prefix/random-2] <-------- **key exchange complete** Payload: + MoveToken* + MoveProof* + [ConsumerData] I[/prefix/SessionID/[...]] Mosko, et al. Expires January 9, 2017 [Page 10] Internet-Draft CCNxKE July 2016 --------> + NewSessionID* + NewSessionIDTag* Payload: [ProducerData] CO[/prefix/SessionID/[...]] <-------- Repeat with data <--------> Repeat with data * Indicates optional or situation-dependent messages that are not always sent. {} Indicates messages protected using keys derived from the short-term secret (SS). () Indicates messages protected using keys derived from the ephemeral secret (ES). [] Indicates messages protected using keys derived from the traffic secret (TS). Figure 1: High-level message flow for full CCNxKE protocol with a maximum 2-RTT delay. In the following sections, we will describe the format of each round in this protocol in more detail. We do not specify the encoding of CCNxKE data sent in Interest and Content Object payloads. Any viable encoding will suffice, so long as both parties agree upon the type. For example, the payload could be structured and encoded as a JSON object, e.g., { "ClientKeyShare" : 0xaa, "SourceCookie" : 0xbb, "SourceProof" : 0xcc, ... } For now, we assume some valid encoding mechanism is used to give structure to message payloads. Moreover, we assume that these payloads are carried in a distinguished CCNxKE payload field contained in the Interest and Content Objects. 6.2. Round 1 The purpose of Round 1 is to acquire a cookie to binding the exchange to the initial consumer and the public configuration information contained in the ServerConfiguration structure. This information is used in the second round when performing the actual key exchange. To Mosko, et al. Expires January 9, 2017 [Page 11] Internet-Draft CCNxKE July 2016 that end, the format of the Round 1 message is trivial. First, the client issues an Interest with the following name /prefix/random-1 where random-1 is a randomly generated 64-bit nonce. This interest carries a KEPayload with the following information: +-----------------+-------------------------------------+-----------+ | HELLO Field | Description | Optional? | +-----------------+-------------------------------------+-----------+ | SourceChallenge | A random value generated to prove | No | | | ownership of the consumer's | | | | "source" | | +-----------------+-------------------------------------+-----------+ Upon receipt of this interest, the producer responds with a HELLO- REJECT Content Object whose KEPayload has the following fields: +---------------------+---------------------------------+-----------+ | HELLO-REJECT Field | Description | Optional? | +---------------------+---------------------------------+-----------+ | Timestamp | Current server timestamp | No | | | | | | SourceCookie | A cookie that binds the | No | | | consumer's challenge to the | | | | current timestamp | | | | | | | PinnedPrefix | A new prefix that pins the key | Yes | | | exchange to a particular server | | | | | | | ServerConfiguration | The public server configuration | Yes | | | information | | | | | | | ServerChallenge | A random value for the consumer | Yes | | | to include in its | | | | CertificateVerify if the server | | | | requires client authentication | | +---------------------+---------------------------------+-----------+ The Timestamp and SourceCookie are used in Round 2. Their derivation is described later. If the server provides a PinnedPrefix then the consumer must use this prefix in Round 2 in lieu of the Round 1 name prefix. (This is because the PinnedPrefix identifies a particular endpoint that is capable of completing the key exchange.) The ServerConfiguration information is a semi-static catalog of information that consumers may use to complete future key exchanges Mosko, et al. Expires January 9, 2017 [Page 12] Internet-Draft CCNxKE July 2016 with the producer. The fields of the ServerConfiguration information are shown below. +---------------------+---------------------------------+-----------+ | ServerConfiguration | Description | Optional? | | Field | | | +---------------------+---------------------------------+-----------+ | KEXS | Supported elliptic-curve key- | No | | | exchange algorithms | | | | | | | AEAD | Supported AEAD algorithms | No | | | | | | PUBS | List of public values (for key | No | | | exchange algorithm) encoded | | | | appropriately for the given | | | | group | | | | | | | EXPRY | Expiration timestamp (i.e., | No | | | longevity of the | | | | ServerConfiguration structure) | | | | | | | VER | Version of the CONFIG structure | Yes | | | | | | CERT | Server certificate | No | | | | | | SIG | Signature produced by the | No | | | server over the entire | | | | ServerConfiguration message | | +---------------------+---------------------------------+-----------+ The KEXS is a data structure that enumerates the elliptic curve key- exchange algorithms that are supported by the producer (see [QUIC] for more details). Currently, only the following curves are supported: - Curve25519 - P-256 Selection criteria for these curves is given at http://safecurves.cr.yp.to/. The AEAD structure enumerates the supported AEAD algorithms used for symmetric-key authenticated encryption after the session has been established. Currently, the only supported algorithms are: Mosko, et al. Expires January 9, 2017 [Page 13] Internet-Draft CCNxKE July 2016 - AES-GCM-(128,192,256) [GCM]: a 12-byte tag is used, where the first four bytes are taken from the FSK key-derivation step and the last eight are taken from the initial consumer nonce. - Salsa20 [SALSA20] (stream cipher) with Poly1305 (MAC). The key sizes and related parameters are provided with the AEAD tag in the CONFIG structure. The PUBS structure contains the public values for the initial key exchange. Both Curve25519 and P-256 provide their own set of accepted parameters. Thus, the only values provided here are the random curve elements used in the DH operation. The EXPRY value is an absolute timestamp that indicates the longevity of the ServerConfiguration. The CERT and SIG values contain the server's certificate and a signature generated over the entire ServerConfiguration field. This signature is generated with the corresponding private key. 6.3. Round 2 The purpose of Round 2 is to perform the initial FULL-HELLO exchange to establish a forward-secure key used for future communication. It is assumed that the consumer already has the ServerConfiguration information that is provided from the producer in Round 1. It is also assumed that the consumer has a Assuming that /prefix is the prefix established after Round 1, then the consumer issues an Interest with the following name: /prefix/random-2 and a KEPayload with the following information: +----------------------+--------------------------------+-----------+ | FULL-HELLO Field | Description | Optional? | +----------------------+--------------------------------+-----------+ | ClientKeyShare | The client's key share for the | No | | | key exchange | | | | | | | SourceCookie | SourceCookie provided by the | No | | | server in Round 1 | | | | | | | SourceProof | The SourceCookie construction | No | | | proof provided by the client | | | | | | Mosko, et al. Expires January 9, 2017 [Page 14] Internet-Draft CCNxKE July 2016 | Timestamp | The timestamp provided by the | No | | | server in Round 1 | | | | | | | ConsumerPrefix | The consumer's prefix that can | Yes | | | be used for the producer to | | | | send interests to the consumer | | | | | | | PreSharedKey | A pre-shared key that can be | Yes | | | configured between a consumer | | | | and producer | | | | | | | {MoveChallenge} | A move challenge generated | Yes | | | identically to the | | | | SourceChallenge | | | | | | | {AlgChoice} | Algorithm (KEXS and AEAD) | No | | | options choice (a list of tags | | | | echoed from the | | | | ServerConfiguration) | | | | | | | {Proof} | Proof of demand (i.e., a | No | | | sorted list of types of proof | | | | the consumer will expect) | | | | | | | {CCS} | Compressed certificate set | No | | | that the consumer possesses | | | | | | | {ConsumerData} | Application data encrypted | Yes | | | under a key derived from SS | | | | (in a 1-RTT exchange) | | | | | | | ServerNameIndication | A server name indication (as a | Yes | | | CCNxName) defined in Section 3 | | | | of [RFC6066] | | | | | | | Certificate | The client's certificate | Yes | +----------------------+--------------------------------+-----------+ The client may optionally sign this interest. If so, the client MUST provide its certificate in the Certificate field which contains the key used to verify this signature. Upon receipt of this interest, the producer performs the DH computation to compute ES and SS, decrypts all protected fields in the consumer's KEPayload, and validates the algorithm choice selection (AlgChoice). If any of these steps fail, the producer replies with with a HELLO-REJECT Content Object whose KEPayload Mosko, et al. Expires January 9, 2017 [Page 15] Internet-Draft CCNxKE July 2016 contains a REJECT flag and the reason of the error. The REJECT flag and value are encrypted by the SS (if possible). If the above steps complete without failure or error, then the producer responds with a Content Object whose KEPayload has the following fields: +--------------------+----------------------------------+-----------+ | HELLO-ACCEPT Field | Description | Optional? | +--------------------+----------------------------------+-----------+ | SessionID | Cleartext session identifier | No | | | | | | ServerKeyShare | Server's key share for the ES | No | | | derivation | | | | | | | {ServerExtensions} | Additional extensions provided | Yes | | | by the server, encrypted under | | | | ES | | | | | | | [ResumptionCookie] | Resumption cookie encrypted | Yes | | | under a TS-derived key | | | | | | | {MovePrefix} | CCNxName prefix to use when | Yes | | | moving to session establishment | | | | | | | {MoveToken} | A token to use when migrating to | Yes | | | the given MovePrefix | | | | | | | Certificate | Server certificate that matches | Yes | | | the type of proof provided by | | | | the client | | +--------------------+----------------------------------+-----------+ If a MovePrefix and MoveToken tuple is provided then in the HELLO- ACCEPT message then a CertificateVerify (signature) MUST also be provided in the response. The server response is always signed and the verification key may be obtained from either the content object ValidationAlgorithm data or the server-provided Certificate field. 6.4. Round 3 In Round 3, the consumer sends interests whose name and optional Payload are encrypted using one of the forward-secure keys derived after Round 2. In normal operation, the producer will respond with Content Objects whose Payloads are encrypted using a different forward-secure key. That is, interests and Content Objects are encrypted and authenticated using two separate keys. Mosko, et al. Expires January 9, 2017 [Page 16] Internet-Draft CCNxKE July 2016 - Payload: the actual Content Object payload data encrypted with the producer's forward-secure key. The producer may also reply with a new SessionID. This MUST be done if the client presented a MoveToken and MoveProof. A NewSessionID must be accompanied with a NewSessionIDTag, which is equal to the HMAC of NewSessionID computed with the traffic-secret key. A client MUST then use NewSessionID instead of SessionID after verifying the NewSessionIDTag. If the client server did not provide a MoveToken in Round 2, then the server in Round 3 MAY still provide a NewSessionID, but doing so is not required. 7. Alternative Exchanges CCNxKE also supports one-round key exchange and session resumption. These variants are outlined below. The key material differences are described later. In these variants, we use message ExchangeSourceCookie to denote the following exchange: Consumer Producer HELLO: + SourceChallenge I[/prefix/random-1] --------> HELLO-REJECT: + Timestamp + SourceCookie ServerChallenge* ServerConfiguration* CO[/prefix/random-1] <--------- Figure 2: SourceCookie exchange -- ExchangeSourceCookie. 7.1. One-RTT Exchange Mosko, et al. Expires January 9, 2017 [Page 17] Internet-Draft CCNxKE July 2016 Consumer Producer --------> ExchangeSourceCookie <--------- FULL-HELLO: + ClientKeyShare + SourceCookie + SourceProof + Timestamp + Certificate* + {ConsumerData*} I[/prefix/random-2] --------> HELLO-ACCEPT: + ServerKeyShare + SessionID + [ServerExtensions] + [PreSharedKey] + [CertificateRequest*] + [MovePrefix*, MoveToken*] + [Finished] CO[/prefix/random-2] <-------- **key exchange complete** Send encrypted data <--------> Send encrypted data * Indicates optional or situation-dependent messages that are not always sent. {} Indicates messages protected using keys derived from the short-term secret (SS). () Indicates messages protected using keys derived from the ephemeral secret (ES). [] Indicates messages protected using keys derived from the traffic secret (TS). Figure 3: Exchange with 1 RTT. As with TLS, the initial application data is protected with the 8. PSK Mode and Session Resumption In this mode, the client uses its PreSharedKey to re-create a previous session. The client also provides a key share in case the server opts to fall back and establish a fresh key. If the server Mosko, et al. Expires January 9, 2017 [Page 18] Internet-Draft CCNxKE July 2016 accepts the PreSharedKey, then the security context from the previous session is resumed. Consumer Producer --------> ExchangeSourceCookie <--------- FULL-HELLO: + ClientKeyShare + SourceCookie + SourceProof + Timestamp + PreSharedKey I[/prefix/random-2] --------> HELLO-ACCEPT: + PreSharedKey + ServerKeyShare + SessionID + [ServerExtensions] + [MovePrefix*, MoveToken*] + [Finished] CO[/prefix/random-2] <-------- **key exchange complete** Send encrypted data <--------> Send encrypted data * Indicates optional or situation-dependent messages that are not always sent. {} Indicates messages protected using keys derived from the short-term secret (SS). () Indicates messages protected using keys derived from the ephemeral secret (ES). [] Indicates messages protected using keys derived from the traffic secret (TS). Figure 4: Exchange with 1 RTT. 9. Secret Derivation In this section we describe how secrets used in the protocol are derived. We cover the SourceCookie, MoveToken, SessionID, ResumptionCookie, and the actual traffic keys. Mosko, et al. Expires January 9, 2017 [Page 19] Internet-Draft CCNxKE July 2016 9.1. SourceCookie Derivation The intention of the SourceCookie is to prove that a client is sending interests from a legitimate location before any server computation is done. Without this, a Denial of Service attack could be carried out by sending interests to the server with the intention of triggering wasted computation. TCP-based protocols prevent this with the SYN-flood cookie mechanism. Protocols based on UDP use cookies that bind to the client address [DTLS12]. Since CCN lacks any notion of a source address, these cookie mechanisms do not apply. Instead, we need a way for clients to prove that they initiated a key exchange from the "same origin." We now describe the cookie mechanism that gives us this guarantee. Instead of a source address, a SourceCookie is computed using a challenge provided by a consumer. To create this challenge, a consumer first generates a a randomly generated 256-bit string X. The consumer then computes SourceChallenge = SHA256(X). Upon receipt of this challenge, the producer generates a SourceCookie as follows: SourceCookie = HMAC(k, SourceChallenge || timestamp) where timestamp is the current server timestamp and k is the server's secret key. To prove ownership of the "source," the consumer then provides the SourceCookie and a SourceProof in the round 2 Interest. The SourceProof is set to the value X used to derive the SourceChallenge. Upon receipt of the SourceProof, the server verifies the following equality: SourceCookie = HMAC(k, SHA256(SourceProof) || timestamp) If this check passes, then the server continues with the computationally expensive part of the key exchange protocol. To avoid replays of the SourceProof and SourceCookie, a producer SHOULD keep a sliding window of previously received tuples. 9.2. MoveToken Derivation The MoveChallenge and MoveProof are computed identically to the SourceChallenge and SourceProof. The MoveToken, however, is left as an opaque bit string. Extensions may be specified to describe how to compute this value. Mosko, et al. Expires January 9, 2017 [Page 20] Internet-Draft CCNxKE July 2016 9.3. SessionID and PreSharedKey Properties, Derivation, and Usage The purpose of the session identifier SessionID and PreSharedKey are to uniquely identify a single session for the producer and consumer. A Producer MAY use a random bit string for both or MAY use the method described in this section or MAY use another proprietary method to distinguish clients. We provide a more secure creation of the SessionID since it is used with the PreSharedKey derivation (defined later). Specifically, the SessionID is derived as the encryption of the hash digest of a server secret, TS, and an optional prefix (e.g., MovePrefix). Encryption is done by the using a long-term secret key owned by the server used for only this purpose, i.e., it is not used for consumer traffic encryption. Mechanically, this derivation is: SessionID = Enc(k1, H(TS || (Prefix3))), where k1 is the long-term producer key. For the resumption cookie, we require that it must be able to be used to recover the TS for a given session. Without TS, correct session communication is not possible. We derive it as the encryption of the hash digest of the server secret, TS, and the optional (MovePrefix, MoveToken) tuple (if created for the session). The producer must use a long-term secret key for this encryption. Mechanically, this derivation is: PreSharedKey = Enc(k2, TS || ( (Prefix3 || MoveToken) )), where k2 is again a long-term producer key. Note that it may be the case that k1 = k2 (see above), though this is not required. With this SessionID and PreSharedKey, the consumer then resumes a session by providing both the SessionID and PreSharedKey to the producer. This is done to prove to the producer that the consumer who knows the SessionID is also in possession of the correct PreSharedKey. The producer verifies this by computing (TS || ( (Prefix3 || MoveToken) )) = Dec(k2, PreSharedKey) and checking the following equality SessionID = Enc(k1, H(TS || (Prefix3))) If equality holds, the producer uses the TS recovered from PreSharedKey to re-initialize the previous session with the consumer. Mosko, et al. Expires January 9, 2017 [Page 21] Internet-Draft CCNxKE July 2016 9.4. Key Derivation CCNxKE adopts the key schedule and derivation techniques defined in TLS 1.3 [TLS13]. Specifically, it uses the SS and ES to establish a common master secret (MS) and, from that, the traffic secret (TS). These dependencies are shown below. +------+ +------+ | KE-1 | | KE-2 | +------+ +----+-+ | | +---v--+ +----v-+ | SS +---+ +--+ ES | +------+ | | +------+ +-v----v-| | MK | +---+----+ | +-v--+ | TS | +----+ In this figure, KE-1 and KE-2 are two "sources" of keying material. The following table shows what these two sources are in different key exchange scenarios. +-------------+------------------------------+----------------------+ | Key | KE-1 | KE-2 | | Exchange | | | +-------------+------------------------------+----------------------+ | Full | ClientKeyShare and | ClientKeyShare and | | handshake | ServerKeyShare DH | ServerKeyShare DH | | | | | | Handshake | ClientKeyShare and | ClientKeyShare and | | with 1-RTT | ServerConfiguration public | ServerKeyShare DH | | | share DH | | | | | | | PSK | Pre-shared key | Pre-shared key | +-------------+------------------------------+----------------------+ Given the values for SS and ES, the remaining derivation steps are below as defined in [TLS13]. They are repeated here for posterity. 1. xSS = HKDF-Extract(0, SS). Note that HKDF-Extract always produces a value the same length as the underlying hash function. 2. xES = HKDF-Extract(0, ES) Mosko, et al. Expires January 9, 2017 [Page 22] Internet-Draft CCNxKE July 2016 3. mSS = HKDF-Expand-Label(xSS, "expanded static secret", handshake_hash, L) 4. mES = HKDF-Expand-Label(xES, "expanded ephemeral secret", handshake_hash, L) 5. master_secret = HKDF-Extract(mSS, mES) 6. traffic_secret_0 = HKDF-Expand-Label(master_secret, "traffic secret", handshake_hash, L) In all computations, the value "handshake_hash" is defined as the SHA256 hash digest of all CCNxKE messages concatenated up to the point of derivation. For example, the "handshake_hash" used to derive the ES after Round 2 is the hash of the wire-encoded messages (i.e., interest and content object) in Round 1 and Round 2. These will be available to both the consumer and producer since the same peers are involved in both rounds. More details are given in Section 7.3.1 of [TLS13]. Updating the traffic secret using the re-key message (defined later) increments traffic_secret_N to traffic_secret_(N+1). This update procedure works as follows: traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, "traffic secret", "", L) 9.5. Secret Generation and Lifecycle The secrets (keys and IVs) used to encrypt and authenticate traffic are derived from the traffic secret. The explicit derivation formula, as is defined in [TLS13], is as follows: secret = HKDF-Expand-Label(Secret, phase + ", " + purpose, handshake_context, key_length) In this context, secret can be a key or IV. This formula is used when deriving keys based on a non-forward-secure SS and the forward- secure TS. The following table enumerates the values for "phase", and "handshake_context" to be used when defining keys for different purposes. Mosko, et al. Expires January 9, 2017 [Page 23] Internet-Draft CCNxKE July 2016 +-------------+--------+------------------+-------------------------+ | Record Type | Secret | Phase | Handshake Context | +-------------+--------+------------------+-------------------------+ | 1-RTT Data | xSS | "early | HELLO + | | | | application data | ServerConfiguration + | | | | key expansion" | Server Certificate | | | | | | | Application | TS | "application | HELLO ... Finished | | Data | | data key | | | | | expansion" | | +-------------+--------+------------------+-------------------------+ Moreover, the following table indicates the values of "purpose" used in the generation of each secret. +------------------------+--------------------------+ | Secret | Purpose | +------------------------+--------------------------+ | Client Write Key | "client write key" | | | | | Server Write Key | "server write key" | | | | | Client Write IV | "client write IV" | | | | | Server Write IV | "server write IV" | | | | | Client Migration Token | "client migration token" | | | | | Server Migration Token | "server migration token" | +------------------------+--------------------------+ (( TODO: should we add examples for each of the above variants? )) 10. Re-Key Message Either the client and server can trigger a key update by sending an Interest or Content Object with a KEPayload field containing the flag KeyUpdate. The KEPayload will be encrypted by the traffic key. Upon receipt, the recipient MUST update the traffic secret as defined above and re-compute the traffic keys. The previous traffic key must then be securely discarded. 11. Application Data Protocol Once traffic keys and the associated IVs are derived from the CCNxKE protocol, all subsequent Interest and Content Object messages are encrypted. Packet encryption uses the TLV encapsulation mechanism specified in [TLVENCAP]. Mosko, et al. Expires January 9, 2017 [Page 24] Internet-Draft CCNxKE July 2016 12. Security Considerations For CCNxKE to be able to provide a secure connection, both the consumer and producer systems, keys, and applications must be secure. In addition, the implementation must be free of security errors. The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used. Short public keys and anonymous servers should be used with great caution. Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can cause tremendous damage. 13. References 13.1. Normative References [CCNxMessages] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Format", June 2016, <https://tools.ietf.org/html/draft- irtf-icnrg-ccnxmessages-03>. [DH] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n.6 , June 1977. [DTLS12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", January 2012, <https://tools.ietf.org/html/rfc6347>. [ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI ANS X9.62-2005, November 2005. [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007. [QUIC] Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", December 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. Mosko, et al. Expires January 9, 2017 [Page 25] Internet-Draft CCNxKE July 2016 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <http://www.rfc-editor.org/info/rfc2631>. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>. [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm without Bit Shifting", RFC 6479, DOI 10.17487/RFC6479, January 2012, <http://www.rfc-editor.org/info/rfc6479>. [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 120-126., February 1978. [SALSA20] Bernstein, D., "Salsa20 specification", www.http://cr.yp.to/snuffle/spec.pdf , April 2005. Mosko, et al. Expires January 9, 2017 [Page 26] Internet-Draft CCNxKE July 2016 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", December 2015, <https://tools.ietf.org/html/ draft-ietf-tls-tls13-11>. [TLVENCAP] Mosko, M. and C. Wood, "CCNx Packet Encapsulation", n.d., <https://github.com/PARC/ccnx-tlvencap-rfc>. 13.2. Informative References [HASHCHAIN] L. Lamport, "Password Authentication with Insecure Communication", ANSI Communications of the ACM 24.11, pp 770-772, November 1981. Authors' Addresses M. Mosko PARC EMail: marc.mosko@parc.com Ersin Uzun PARC EMail: ersin.uzun@parc.com Christopher A. Wood PARC EMail: christopher.wood@parc.com Mosko, et al. Expires January 9, 2017 [Page 27]