idnits 2.17.1 draft-wood-icnrg-ccnxkeyexchange-01.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 date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Finished' is mentioned on line 912, but not defined == Missing Reference: 'ConsumerData' is mentioned on line 501, but not defined == Missing Reference: 'ProducerData' is mentioned on line 508, but not defined == Missing Reference: 'ResumptionCookie' is mentioned on line 910, but not defined == Missing Reference: 'ServerExtensions' is mentioned on line 909, but not defined == Unused Reference: 'RFC5077' is defined on line 1287, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CCNxMessages' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' ** Obsolete normative reference: RFC 6347 (ref. 'DTLS12') (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC' ** Downref: Normative reference to an Informational RFC: RFC 4987 ** Downref: Normative reference to an Informational RFC: RFC 5869 -- Duplicate reference: RFC6347, mentioned in 'RFC6347', was also mentioned in 'DTLS12'. ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 6479 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SALSA20' == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'TLVENCAP' -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 icnrg M. Mosko 3 Internet-Draft E. Uzun 4 Intended status: Standards Track C. Wood 5 Expires: May 4, 2017 PARC 6 October 31, 2016 8 CCNx Key Exchange Protocol Version 1.0 9 draft-wood-icnrg-ccnxkeyexchange-01 11 Abstract 13 This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) 14 protocol. The CCNxKE protocol allows two peers to establish a 15 shared, forward-secure key for secure and confidential communication. 16 The protocol is designed to prevent eavesdropping, tampering, and 17 message forgery between two peers. It is also designed to minimize 18 the number of rounds required to establish a shared key. In the 19 worst case, it requires two RTTs between a consumer and producer to 20 establish a shared key. In the best case, one RTT is required before 21 sending any application data. This document outlines how to derive 22 the keys used to encrypt traffic. An annex provides an example peer- 23 to-peer transport protocol for exchanging encrypted CCNx 24 communications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 62 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 65 5. CCNxKE Overview . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Connection Establishment Latency . . . . . . . . . . . . 8 67 5.2. Connection Migration and Resumption . . . . . . . . . . . 8 68 5.3. Re-Transmissions, Timeouts, and Replay Prevention . . . . 8 69 5.4. Loss Sensitivity . . . . . . . . . . . . . . . . . . . . 9 70 6. The CCNxKE Protocol . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Round Overview . . . . . . . . . . . . . . . . . . . . . 10 72 6.2. Round 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.3. Round 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.4. Round 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 7. Alternative Exchanges . . . . . . . . . . . . . . . . . . . . 18 76 7.1. One-RTT Exchange . . . . . . . . . . . . . . . . . . . . 19 77 8. Resumption and PSK Mode . . . . . . . . . . . . . . . . . . . 20 78 9. Secret Derivation . . . . . . . . . . . . . . . . . . . . . . 21 79 9.1. SourceCookie Derivation . . . . . . . . . . . . . . . . . 21 80 9.2. Move Derivation . . . . . . . . . . . . . . . . . . . . . 21 81 9.3. SessionID and ResumptionCookie Properties, Derivation, 82 and Usage . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . 23 84 9.5. Secret Generation and Lifecycle . . . . . . . . . . . . . 24 85 10. Re-Key Message . . . . . . . . . . . . . . . . . . . . . . . 25 86 11. Application Data Protocol . . . . . . . . . . . . . . . . . . 25 87 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 90 13.2. Informative References . . . . . . . . . . . . . . . . . 28 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 93 1. Introduction 95 DISCLAIMER: This is a WIP draft of CCNxKE and has not yet seen 96 rigorous security analysis. 98 CCNx Key Exchange (CCNxKE) establishes ephemeral forward secure keys 99 between two peers, called the consumer (client) and producer 100 (server). The underlying cryptography of CCNxKE is similar to TLS 101 1.3, though there are some protocol changes due to the ICN nature of 102 CCNxKE. CCNxKE also supports the concept of a MoveToken, which 103 allows the authenticating producer to shift a session to one (or 104 more) co-operating replicas. 106 CCNxKE does not specify how the keys are used. It only specifies how 107 to derive the traffic secret that could be used to encrypt/decrypt 108 data. The draft [draft-wood-icnrg-tlvencap] specifies one way to use 109 the traffic secret to carry out communications in a session. 110 Annex A also sketches out an example CCNx protocol for exchanging 111 encrypted messages, though it is not part of this standard. Other 112 protocols may use CCNxKE. 113 For example, a producer and replica may use CCNxKE to establish a 114 shared key to use in Move Tokens. Two routers may use CCNxKE to 115 establish MACSEC keys. A consumer and publisher could establish a 116 symmetric key while on-line then publish content later for an off- 117 line consumer. In short, the use of CCNxKE is not limited to a TLS- 118 like transport protocol. 120 CCNxKE allows upper-layer data to be returned in Round 3, like TLS 121 1.3. In this sense, one can achieve 3 RTT (worst case) or 1 RTT 122 (best case) communcations. The data put in this response is up to 123 the protocol using CCNxKE and may or may not be used. 125 CCNxKE is not a substitue for data authenticity, such as Content 126 Object provenance via signatures, group encryption of cached objects, 127 or DRM protections. CCNxKE only creates a private, ephemeral tunnel 128 between a consumer and a producer. CCNxKE expects that the encrypted 129 communications protocol still carries normal CCNx packets with normal 130 CCNx attributes such as signatures. 132 Some types of ICN communications require emphemeral, forward secure 133 encryption. Typical examples are on-line banking, real-time voice, 134 or on-line shopping. Other applications may need different types of 135 encryption and thus not use CCNxKE. There is currently no standard 136 way for CCNx peers to exchange emphemeral, forward secure keys, thus 137 this RFC specifies the standard mechanism that should be used by all 138 CCNx peers for such keys. CCNxKE is built on the CCNx 1.0 protocol 139 and only relies upon standard Interest and Content Objects as a 140 vehicle for communication. 142 In this document, the term 'CCNxKE session' refers to the key 143 exchange session. It does not refer to a transport protocol session 144 (like TLS) that uses the derived keys. 146 This protocol has the following four main properties: 148 - Each peer's identity can be authenticated using asymmetric, or 149 public key, cryptography (e.g., RSA [RSA], ECDSA [ECDSA], etc.). 150 Server authentication is mandatory whereas mutual authentication 151 is optional. 153 - The negotiation of a forward-secure shared secret is protected 154 from eavesdroppers and man-in-the-middle (MITM) attacks. 156 - The negotiation is reliable: no attacker can modify the 157 negotiation communication without being detected by the parties to 158 the communication. 160 - The state of a CCNxKE session can be securely migrated between an 161 endpoint performing authentication and that which provides content 162 using a "move token." This allows authentication and 163 authorization to be separated from encryption for a session, 164 enabling different systems to complete these steps. 166 Usage of CCNxKE is entirely independent of upper-layer application 167 protocols. CCNxKE may be used for any purpose that requires producer 168 authentication and shared emphemeral forward-secure keys. 170 CCNxKE also introduces a new type of cookie based on reverse hash 171 chains [HASHCHAIN] to help limit the amount of significant server 172 work done in response to a client or consumer Interest. TCP-based 173 protocols, such as TLS [TLS13], use the TCP 3-way handshake for such 174 proof. UDP-based protocols, such as QUIC [QUIC] and DTLS 1.2 175 [DTLS12], use an optional session address token or cookie that must 176 be presented by the client (consumer) to prove ownership of an 177 address during a key exchange procedure. Without source addresses, 178 our cookie technique ensures that the same entity which requested 179 server information, e.g., the public configuration data, is the same 180 entity that wishes to complete a key exchange. 182 The main contribution of this work is adapting key exchange 183 principles to the pull-based CCNx communication model. CCNxKE only 184 assumes that a consumer knows a first name prefix to initiate the key 185 exchange. The first Interest does not need to be a CCNxKE packet -- 186 the producer can signal back to the consumer that it requires a 187 transport protocol using CCNxKE in the response. 189 This specification does not subsume other ICN-compliant key exchange 190 protocols. Nor does its existence imply that all encryption in an 191 ICN must be based on sessions. It was designed specifically to solve 192 the problem of session-based encryption in ICN. 194 1.1. Conventions and Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in RFC 199 2119 [RFC2119]. 201 The following terms are used: 203 Consumer/Client: The CCN consumer initiating the CCNxKE key exchange 204 via a first Interest. 206 Producer/Server: The CCN producer receiving or accepting the CCNxKE 207 key exchange request request Interest. 209 Sender: An endpoint that originates a message. 211 Receiver: An endpoint that is receiving messages. 213 Peer: An endpoint. When discussing a particular endpoint, "peer" 214 refers to the endpoint that is remote to the primary subject of 215 discussion. 217 Connection: A network path of n >= 1 hops between the consumer and 218 producer. 220 Endpoint: Either the consumer or producer of the connection. 222 Handshake: A series of message exchanges between two peers that is 223 used to perform a task (e.g., perform key exchange and derivation). 225 Session: An association between a consumer and a producer resulting 226 from a CCNxKE handshake. 228 DH: A Diffie Hellman key exchange procedure [RFC2631] [DH]. 230 Key Share: One half of the shared-secret provided by one peer 231 performing a DH key exchange. 233 Forward-secure: The property that compromising any long-term secrets 234 (e.g., cryptographic keys) does not compromise any session keys 235 derived from those long-term secrets. 237 CONFIG information: A data structure created by a producer which 238 contains long-term cryptographic material and associated information 239 needed by a client to initiate a key-exchange with the producer. 241 HELLO exchange: An exchange between a consumer and producer wherein 242 the consumer retrieves the CONFIG information from the producer. 244 Payload: The payload section of a CCNxMessage as defined in 245 [CCNxMessages]. 247 KEPayload: A payload for information used in the CCNxKE protocol 248 which is a generic key-value store. The KEPayload is _not_ the 249 CCNxMessage payload. 251 CCNxName: A CCNxName as defined in [CCNxMessages]. 253 Semi-static: Short-term. 255 Short-term Secret (SS): A secret which is derived from the server's 256 semi-static DH share and the client's fresh DH share. 258 Forward-secure Secret (FSK): A secret which is derived from fresh 259 (i.e., generated on demand at random) DH shares from both the 260 consumer and producer for the given connection. 262 HKDF: Hash-based key-derivation function [RFC5869]. 264 2. Goals 266 The goals of the CCNxKE protocol, in order of priority, are as 267 follows: 269 1. Cryptographic security: CCNxKE should be used to securely 270 establish a session and all related shared secrets between two 271 peers. Cryptographic properties of interest include: (a) 272 forward-secure session key derivation and (b) (state and 273 computational) denial-of-service prevention at the producer (see 274 [RFC4987]) that is no worse than DTLS 1.2 [DTLS12]}. For property 275 (a), different keys (and relevant algorithm parameters such as 276 IVs) are established for each communication direction, i.e., from 277 consumer to producer and producer to consumer. For property (b), 278 we use a new type of stateless cookie inspired by that of DTLS 279 1.2. 281 2. Interoperability: Independent programmers should be able to 282 develop applications utilizing CCNxKE that can successfully 283 exchange cryptographic parameters without knowledge of one 284 another's code. 286 3. Extensibility: CCNxKE seeks to provide a framework into which new 287 public key and symmetric key methods and algorithms can be 288 incorporated without breaking backwards compatibility or 289 requiring all clients to implement new functionality. Moreover, 290 the protocol should be able to support a variety of peer 291 authentication protocols, e.g., EAP-TLS, EAP-PWD, or a simple 292 challenge-response protocol. 294 4. Relative efficiency: CCNxKE tries to create sessions with minimal 295 computation, bandwidth, and message complexity. In particular, 296 it seeks to create sessions with as few end-to-end round trips as 297 possible, and also provide support for accelerated session 298 establishment and resumption when appropriate. At most 2 round- 299 trip-times (RTTs) should be used to establish a session key, with 300 the possibility of 1-RTT accelerated starts and resumption. 302 3. Scope 304 This document and the CCNxKE protocol are influenced by the TLS 1.3 305 [TLS13], QUIC [QUIC], and DTLS 1.2 [DTLS12] protocols. The reader, 306 however, does not need a detailed understanding of those protocols to 307 understand this document. Moreover, where appropriate, references to 308 related protocols are made for brevity and technical clarity. This 309 document is intended primarily for readers who will be implementing 310 the protocol and for those doing cryptographic analysis of it. The 311 specification has been written with this in mind and it is intended 312 to reflect the needs of those two groups. 314 Unlike TLS, this document does not specify the transport protocol. 315 It specifies the establishment of a session ID and shared keys. 316 Other documents specify the use of CCKxKE within a transport 317 protocol. 319 This document is not intended to supply any details of service 320 definition or of interface definition, although it does cover select 321 areas of policy as they are required for the maintenance of solid 322 security. 324 4. Presentation Language 326 This document uses a presentation language of remote calls (i.e. 327 packet messages) similar to the format used by TLS [TLS13]. 329 5. CCNxKE Overview 330 5.1. Connection Establishment Latency 332 CCNxKE operates in three rounds, where each round requires a single 333 RTT to complete. The full execution of the protocol therefore 334 requires 2 RTTs before a session is fully established. The full 335 version is used when consumers have no a priori information about the 336 producer. An accelerated one round version is used when the consumer 337 has valid configuration information and a source cookie from the 338 producer; this variant requires 1 RTT before a session is 339 established. 341 5.2. Connection Migration and Resumption 343 CCN end hosts lack the notion of addresses. Thus, the producer 344 endpoint for a given execution of the CCNxKE protocol is one which 345 can authoritatively serve as the owner of a particular namespace. 346 For example, a consumer may wish to establish a session with a 347 producer who owns the /company/foo namespace. The specific end host 348 which partakes in the protocol instance is not specified, by virtue 349 of the fact that all CCNxKE messages are based on well-defined names. 350 This enables the producer end-host which partakes in the protocol to 351 change based on the name of the CCNxKE messages. Consequently, to 352 maintain correctness, it is important that a single execution of the 353 protocol operates within the same trusted context; this does not mean 354 that the same producer end-host is required to participate in all 355 three steps of the protocol. Rather, it means that the end-host 356 responding to a CCNxKE message must be trusted by the consumer to 357 complete the exchange. CCNxKE is designed to enable this sort of 358 producer migration. 360 For example, a consumer may use an initial name like '/parc/ 361 index.html' that works like an IP any cast address and could got to 362 one of several systems. CCNxKE allows the responding endpoint to 363 include a localized name to ensure that subsequent messages from the 364 consumer come back to the same producer. CCNxKE also allows the key 365 exchange peer to securely hand-off the session to a content producer 366 peer via another name and session token once the client is 367 authenticated and keying material is exchanged. 369 5.3. Re-Transmissions, Timeouts, and Replay Prevention 371 CCNxKE timeouts and retransmissions are handled using the approach in 372 [RFC6347]. One primary difference is that timer values may need to 373 be adjusted (elongated) due to prefix shifts and the need for a 374 producer to transfer security information between different machines. 376 Replay attack prevention is also an optional feature, and if used, 377 MAY be done using one of the following two approaches at the receiver 378 (producer): 380 - IPSec AH [RFC4302] and ESP [RFC4303] style replay detection based 381 on sliding windows and monotonically increasing sequence numbers 382 for windows. Note that the sliding window inherently limits the 383 performance of the protocol to the window size, since only a 384 finite number of messages may be received within a given window 385 (based on the window size). 387 - The optimized anti-replay algorithm of [RFC6479]. 389 5.4. Loss Sensitivity 391 CCNxKE messages are transferred using standard CCN Interest and 392 Content Objects and are therefore subject to loss as any datagram. 393 This means that traffic encrypted with keys derived from CCNxKE must 394 be stateless. They cannot depend on in-order arrival. This problem 395 is solved by two mechanisms: (1) by prohibiting stream ciphers of any 396 kind and (2) adding sequence numbers to each message that allow the 397 receiver to identify and use the correct cryptographic state to 398 decrypt the message. Moreover, sequence numbers permit anti-replay 399 mechanisms similar to those used in DTLS [DTLS12] as mentioned above. 401 6. The CCNxKE Protocol 403 This section describes the CCNxKE protocol in detail at the message 404 level. The specific encoding of those messages is given later. 405 CCNxKE could be adapted to different wire format encodings, such as 406 those used by the NDN protocol. 408 The following assumptions are made about peers participating in the 409 CCNxKE protocol: 411 - Consumers know the namespace prefix of the producer for which they 412 wish to execute the CCNxKE protocol. 414 - CCNxKE protocol information is carried in a distinguished field 415 outside of the payload of CCN messages. This is done to 416 distinguish key exchange material with application data in a 417 message. This is necessary for 1 RTT packets that carry both 418 keying material and application payload. 420 - CCNxKE does not require any special behavior of intermediate 421 systems to forward packets. 423 - CCNxKE packets generally should not be cached for significant 424 periods of time, as use normal protocol methods to limit caching. 425 Part of this is achieved through the use of consumer-specific 426 nonces in names. 428 6.1. Round Overview 430 CCNxKE is composed of three rounds. The purpose of each round is 431 described below. 433 - Round 1: Perform a bare HELLO exchange to obtain the extensions 434 (parameters) for the key exchange provided by the producer and a 435 source cookie to prove ownership of the "source" of the request. 437 - Round 2: Perform the initial FULL-HELLO exchange to establish a 438 forward-secure key used for future communication, i.e., Interest 439 and Content Object exchanges in the context of the newly 440 established session. 442 - Round 3: Send the first bit of application data and (optionally) 443 transfer resumption cookie(s) from the producer to the consumer. 445 Conceptually, there are two secrets established during a single 446 execution of CCNxKE: 448 - Static Secret (SS): A secret which is derived in one of two ways: 449 (a) from the client and server ephemeral key shares and (b) from 450 the server's semi-static share and the client's ephemeral key 451 share. Keying material derived from SS in option (a) is not 452 forward secure. 454 - Ephemeral Secret (ES): A secret which is derived from both the 455 client and server ephemeral key shares. 457 Depending on the mode in which CCNxKE is used, these secrets can be 458 established in a variety of ways. Key derivation details are 459 outlined in Section Section 9. 461 All secrets are derived with the appropriate amount of randomness 462 [RFC4086]. An overview of the messages sent in each of the three 463 rounds to establish and use these secrets is shown in Figure Figure 1 464 below. This diagram omits some parts of each message for brevity. 466 Consumer Producer 468 HELLO: 469 + SourceChallenge 470 I[/prefix/random-1] 471 --------> 472 HELLO-REJECT: 473 + Timestamp 474 + SourceCookie 475 + pinned-prefix* 476 + ServerChallenge* 477 + ServerConfiguration* 479 CO[/prefix/random-1] 480 <--------- 481 FULL-HELLO: 482 + ClientKeyShare 483 + SourceCookie 484 + SourceProof 485 + Timestamp 486 I[/pinned-prefix/random-2] 487 --------> 488 HELLO-ACCEPT: 489 + ServerKeyShare 490 + SessionID 491 + [CertificateRequest*] 492 + [CertificateVerify*] 493 + [MovePrefix*, MoveToken)*] 494 + [Finished] 495 CO[/pinned-prefix/random-2] 496 <-------- 497 **key exchange complete** 498 Payload: 499 + MoveToken* 500 + MoveProof* 501 + [ConsumerData] 503 I[/prefix/SessionID/[...]] 504 --------> 505 + NewSessionID* 506 + NewSessionIDTag* 507 Payload: 508 [ProducerData] 509 CO[/prefix/SessionID/[...]] 510 <-------- 512 Repeat with data <--------> Repeat with data 514 * Indicates optional or situation-dependent 515 messages that are not always sent. 517 {} Indicates messages protected using keys 518 derived from the short-term secret (SS). 520 () Indicates messages protected using keys 521 derived from the ephemeral secret (ES). 523 [] Indicates messages protected using keys 524 derived from the traffic secret (TS). 526 Figure 1: High-level message flow for full CCNxKE protocol with a 527 maximum 2-RTT delay. 529 In the following sections, we will describe the format of each round 530 in this protocol in more detail. 532 We do not specify the encoding of CCNxKE data sent in Interest and 533 Content Object payloads. Any viable encoding will suffice, so long 534 as both parties agree upon the type. For example, the payload could 535 be structured and encoded as a JSON object, e.g., 537 { "ClientKeyShare" : 0xaa, "SourceCookie" : 0xbb, "SourceProof" : 538 0xbb, ... } 540 For now, we assume some valid encoding mechanism is used to give 541 structure to message payloads. Moreover, we assume that these 542 payloads are carried in a distinguished CCNxKE payload field 543 contained in the Interest and Content Objects. 545 6.2. Round 1 547 The purpose of Round 1 is to acquire a cookie to binding the exchange 548 to the initial consumer and the public configuration information 549 contained in the ServerConfiguration structure. This information is 550 used in the second round when performing the actual key exchange. To 551 that end, the format of the Round 1 message is trivial. First, the 552 client issues an Interest with the following name 554 /prefix/random-1 556 where random-1 is a randomly generated 64-bit nonce. This interest 557 carries a KEPayload with the following information: 559 +-----------------+-------------------------------------+-----------+ 560 | HELLO Field | Description | Optional? | 561 +-----------------+-------------------------------------+-----------+ 562 | SourceChallenge | A random value generated to prove | No | 563 | | ownership of the consumer's | | 564 | | "source" | | 565 +-----------------+-------------------------------------+-----------+ 566 Upon receipt of this interest, the producer responds with a HELLO- 567 REJECT Content Object whose KEPayload has the following fields: 569 +---------------------+---------------------------------+-----------+ 570 | HELLO-REJECT Field | Description | Optional? | 571 +---------------------+---------------------------------+-----------+ 572 | Timestamp | Current server timestamp | No | 573 | | | | 574 | SourceCookie | A cookie that binds the | No | 575 | | consumer's challenge to the | | 576 | | current timestamp | | 577 | | | | 578 | PinnedPrefix | A new prefix that pins the key | Yes | 579 | | exchange to a particular server | | 580 | | | | 581 | ServerConfiguration | The public server configuration | Yes | 582 | | information | | 583 | | | | 584 | ServerChallenge | A random value for the consumer | Yes | 585 | | to include in its | | 586 | | CertificateVerify if the server | | 587 | | requires client authentication | | 588 +---------------------+---------------------------------+-----------+ 590 The Timestamp and SourceCookie are used in Round 2. Their derivation 591 is described later. If the server provides a PinnedPrefix then the 592 consumer must use this prefix in Round 2 in lieu of the Round 1 name 593 prefix. (This is because the PinnedPrefix identifies a particular 594 endpoint that is capable of completing the key exchange.) 596 The ServerConfiguration information is a semi-static catalog of 597 information that consumers may use to complete future key exchanges 598 with the producer. The fields of the ServerConfiguration information 599 are shown below. 601 +---------------------+---------------------------------+-----------+ 602 | ServerConfiguration | Description | Optional? | 603 | Field | | | 604 +---------------------+---------------------------------+-----------+ 605 | KEXS | Supported elliptic-curve key- | No | 606 | | exchange algorithms | | 607 | | | | 608 | AEAD | Supported AEAD algorithms | No | 609 | | | | 610 | PUBS | List of public values (for key | No | 611 | | exchange algorithm) encoded | | 612 | | appropriately for the given | | 613 | | group | | 614 | | | | 615 | EXPRY | Expiration timestamp (i.e., | No | 616 | | longevity of the | | 617 | | ServerConfiguration structure) | | 618 | | | | 619 | VER | Version of the CONFIG structure | Yes | 620 | | | | 621 | CERT | Server certificate | No | 622 | | | | 623 | SIG | Signature produced by the | No | 624 | | server over the entire | | 625 | | ServerConfiguration message | | 626 +---------------------+---------------------------------+-----------+ 628 The KEXS is a data structure that enumerates the elliptic curve key- 629 exchange algorithms that are supported by the producer (see [QUIC] 630 for more details). Currently, only the following curves are 631 supported: 633 - Curve25519 635 - P-256 637 Selection criteria for these curves is given at 638 http://safecurves.cr.yp.to/. 640 The AEAD structure enumerates the supported AEAD algorithms used for 641 symmetric-key authenticated encryption after the session has been 642 established. Currently, the only supported algorithms are: 644 - AES-GCM-(128,192,256) [GCM]: a 12-byte tag is used, where the 645 first four bytes are taken from the FSK key-derivation step and 646 the last eight are taken from the initial consumer nonce. 648 - Salsa20 [SALSA20] (stream cipher) with Poly1305 (MAC). 650 The key sizes and related parameters are provided with the AEAD tag 651 in the CONFIG structure. 653 The PUBS structure contains the public values for the initial key 654 exchange. Both Curve25519 and P-256 provide their own set of 655 accepted parameters. Thus, the only values provided here are the 656 random curve elements used in the DH operation. 658 The EXPRY value is an absolute timestamp that indicates the longevity 659 of the ServerConfiguration. 661 The CERT and SIG values contain the server's certificate and a 662 signature generated over the entire ServerConfiguration field. This 663 signature is generated with the corresponding private key. 665 6.3. Round 2 667 The purpose of Round 2 is to perform the initial FULL-HELLO exchange 668 to establish a forward-secure key used for future communication. It 669 is assumed that the consumer already has the ServerConfiguration 670 information that is provided from the producer in Round 1. It is 671 also assumed that the consumer has a 673 Moreover, assume that nonce2 is a ephemeral nonce provided by the 674 producer in Round 1. Then, the consumer issues an Interest with the 675 following name: 677 /prefix/random-2 679 and a KEPayload with the following information: 681 +----------------------+--------------------------------+-----------+ 682 | FULL-HELLO Field | Description | Optional? | 683 +----------------------+--------------------------------+-----------+ 684 | ClientKeyShare | The client's key share for the | No | 685 | | key exchange | | 686 | | | | 687 | SourceCookie | SourceCookie provided by the | No | 688 | | server in Round 1 | | 689 | | | | 690 | SourceProof | The SourceCookie construction | No | 691 | | proof provided by the client | | 692 | | | | 693 | Timestamp | The timestamp provided by the | No | 694 | | server in Round 1 | | 695 | | | | 696 | ConsumerPrefix | The consumer's prefix that can | Yes | 697 | | be used for the producer to | | 698 | | send interests to the consumer | | 699 | | | | 700 | PreSharedKey | A pre-shared key that can be | Yes | 701 | | configured between a consumer | | 702 | | and producer | | 703 | | | | 704 | ResumptionCookie | The ResumptionCookie derived | Yes | 705 | | from a past session | | 706 | | | | 707 | {MoveChallenge} | A move challenge generated | Yes | 708 | | identically to the | | 709 | | SourceChallenge | | 710 | | | | 711 | {AlgChoice} | Algorithm (KEXS and AEAD) | No | 712 | | options choice (a list of tags | | 713 | | echoed from the | | 714 | | ServerConfiguration) | | 715 | | | | 716 | {Proof} | Proof of demand (i.e., a | No | 717 | | sorted list of types of proof | | 718 | | the consumer will expect) | | 719 | | | | 720 | {CCS} | Compressed certificate set | No | 721 | | that the consumer possesses | | 722 | | | | 723 | {ConsumerData} | Application data encrypted | Yes | 724 | | under a key derived from SS | | 725 | | (in a 1-RTT exchange) | | 726 | | | | 727 | ServerNameIndication | A server name indication (as a | Yes | 728 | | CCNxName) defined in Section 3 | | 729 | | of [RFC6066] | | 730 | | | | 731 | Certificate | The client's certificate | Yes | 732 | | | | 733 | CertificateVerify | A signature generated over the | Yes | 734 | | entire FULL-HELLO message | | 735 +----------------------+--------------------------------+-----------+ 737 ((TODO: provide more details about each of these fields)) 739 Upon receipt of this interest, the producer performs the DH 740 computation to compute ES and SS, decrypts all protected fields in 741 the consumer's KEPayload, and validates the algorithm choice 742 selection (AlgChoice). If any of these steps fail, the producer 743 replies with with a HELLO-REJECT Content Object whose KEPayload 744 contains a REJ flag and the reason of the error. The REJ flag and 745 value are encrypted by the SS (if possible). 747 If the above steps complete without failure or error, then the 748 producer responds with a Content Object whose KEPayload has the 749 following fields: 751 +--------------------------+----------------------------+-----------+ 752 | HELLO-ACCEPT Field | Description | Optional? | 753 +--------------------------+----------------------------+-----------+ 754 | SessionID | Cleartext session | No | 755 | | identifier | | 756 | | | | 757 | ServerKeyShare | Server's key share for the | No | 758 | | ES derivation | | 759 | | | | 760 | {ServerExtensions} | Additional extensions | Yes | 761 | | provided by the server, | | 762 | | encrypted under ES | | 763 | | | | 764 | [ResumptionCookie] | Resumption cookie | Yes | 765 | | encrypted under a TS- | | 766 | | derived key | | 767 | | | | 768 | {(MovePrefix,MoveToken)} | Third CCNxName prefix and | Yes | 769 | | token to use when moving | | 770 | | to session establishment | | 771 | | | | 772 | CertificateRequest* | Server certificate that | Yes | 773 | | matches the type of proof | | 774 | | provided by the client | | 775 | | | | 776 | CertificateVerify* | Signature generated over | Yes | 777 | | the entire HELLO-ACCEPT | | 778 | | message | | 779 +--------------------------+----------------------------+-----------+ 781 If a MovePrefix and MoveToken tuple is provided then in the HELLO- 782 ACCEPT message then a CertificateVerify (signature) MUST also be 783 provided in the response. 785 6.4. Round 3 787 In Round 3, the consumer sends interests whose name and optional 788 Payload are encrypted using one of the forward-secure keys derived 789 after Round 2. In normal operation, the producer will respond with 790 Content Objects whose Payloads are encrypted using a different 791 forward-secure key. That is, interests and Content Objects are 792 encrypted and authenticated using two separate keys. The producer 793 may also optionally provide a new resumption cookie (RC) with a 794 Content Object response. This is used to keep the consumer's 795 resumption cookie fresh and to also support 0 RTT resumption. In 796 this case, the producer's Content Object response has the following 797 fields: 799 - Payload: the actual Content Object payload data encrypted with the 800 producer's forward-secure key. 802 - ResumptionCookie: A new resumption cookie to be used for resuming 803 this session in the future. 805 The producer is free to choose the frequency at which new resumption 806 cookies are issued to the consumer. 808 The producer may also reply with a new SessionID. This is done if 809 the client presented a MoveToken and MoveProof. A NewSessionID must 810 be accompanied with a NewSessionIDTag, which is equal to the HMAC of 811 NewSessionID computed with the traffic-secret key. A client MUST 812 then use NewSessionID instead of SessionID after verifying the 813 NewSessionIDTag. 815 7. Alternative Exchanges 817 CCNxKE also supports one-round key exchange and session resumption. 818 These variants are outlined below. The key material differences are 819 described later. In these variants, we use message 820 ExchangeSourceCookie to denote the following exchange: 822 Consumer Producer 824 HELLO: 825 + SourceChallenge 826 I[/prefix/random-1] 827 --------> 828 HELLO-REJECT: 829 + Timestamp 830 + SourceCookie 831 ServerChallenge* 832 ServerConfiguration* 834 CO[/prefix/random-1] 835 <--------- 837 Figure 2: SourceCookie exchange -- ExchangeSourceCookie. 839 7.1. One-RTT Exchange 841 Consumer Producer 842 --------> 843 ExchangeSourceCookie 844 <--------- 845 FULL-HELLO: 846 + ClientKeyShare 847 + SourceCookie 848 + SourceProof 849 + Timestamp 850 + Certificate* 851 + CertificateVerify* 852 + {ConsumerData*} 853 I[/prefix/random-2] 854 --------> 855 HELLO-ACCEPT: 856 + ServerKeyShare 857 + SessionID 858 + [ServerExtensions] 859 + [ResumptionCookie] 860 + [CertificateRequest*] 861 + [CertificateVerify*] 862 + [MovePrefix*, MoveToken*] 863 + [Finished] 864 CO[/prefix/random-2] 865 <-------- 866 **key exchange complete** 867 Send encrypted data <--------> Send encrypted data 869 * Indicates optional or situation-dependent 870 messages that are not always sent. 872 {} Indicates messages protected using keys 873 derived from the short-term secret (SS). 875 () Indicates messages protected using keys 876 derived from the ephemeral secret (ES). 878 [] Indicates messages protected using keys 879 derived from the traffic secret (TS). 881 Figure 3: Exchange with 1 RTT. 883 As with TLS, the initial application data is protected with the 885 8. Resumption and PSK Mode 887 In this mode, the client uses its ResumptionCookie to re-create a 888 previous session. The client also provides a key share in case the 889 server opts to fall back and establish a fresh key. If the server 890 accepts the ResumptionCookie then it MUST issue a new SessionID and 891 ResumptionCookie for future use with the client. 893 Consumer Producer 894 --------> 895 ExchangeSourceCookie 896 <--------- 897 FULL-HELLO: 898 + ClientKeyShare 899 + SourceCookie 900 + SourceProof 901 + Timestamp 902 + PreSharedKey 903 + ResumptionCookie 904 I[/prefix/random-2] 905 --------> 906 HELLO-ACCEPT: 907 + ServerKeyShare 908 + SessionID 909 + [ServerExtensions] 910 + [ResumptionCookie] 911 + [MovePrefix*, MoveToken*] 912 + [Finished] 913 CO[/prefix/random-2] 914 <-------- 915 **key exchange complete** 916 Send encrypted data <--------> Send encrypted data 918 * Indicates optional or situation-dependent 919 messages that are not always sent. 921 {} Indicates messages protected using keys 922 derived from the short-term secret (SS). 924 () Indicates messages protected using keys 925 derived from the ephemeral secret (ES). 927 [] Indicates messages protected using keys 928 derived from the traffic secret (TS). 930 Figure 4: Exchange with 1 RTT. 932 9. Secret Derivation 934 In this section we describe how secrets used in the protocol are 935 derived. We cover the SourceCookie, MoveToken, SessionID, 936 ResumptionCookie, and the actual traffic keys. 938 9.1. SourceCookie Derivation 940 The intention of the SourceCookie is to prove that a client is 941 sending interests from a legitimate location before any server 942 computation is done. Without this, a Denial of Service attack could 943 be carried out by sending interests to the server with the intention 944 of triggering wasted computation. TCP-based protocols prevent this 945 with the SYN-flood cookie mechanism. Protocols based on UDP use 946 cookies that bind to the client address [DTLS12]. Since CCN lacks 947 any notion of a source address, these cookie mechanisms do not apply. 948 Instead, we need a way for clients to prove that they initiated a key 949 exchange from the "same origin." We now describe the cookie 950 mechanism that gives us this guarantee. 952 Instead of a source address, a SourceCookie is computed using a 953 challenge provided by a consumer. To create this challenge, a 954 consumer first generates a a randomly generated 256-bit string X. 955 The consumer then computes SourceChallenge = SHA256(X). Upon receipt 956 of this challenge, the producer generates a SourceCookie as follows: 958 SourceCookie = HMAC(k, SourceChallenge || timestamp) 960 where timestamp is the current server timestamp and k is the server's 961 secret key. To prove ownership of the "source," the consumer then 962 provides the SourceCookie and a SourceProof in the round 2 Interest. 963 The SourceProof is set to the value X used to derive the 964 SourceChallenge. Upon receipt of the SourceProof, the server 965 verifies the following equality: 967 SourceCookie = HMAC(k, SHA256(SourceProof) || timestamp) 969 If this check passes, then the server continues with the 970 computationally expensive part of the key exchange protocol. 972 9.2. Move Derivation 974 The MoveChallenge and MoveProof are computed identically to the 975 SourceChallenge and SourceProof. The MoveToken, however, is left as 976 an opaque bit string. Extensions may be specified to describe how to 977 compute this value. 979 9.3. SessionID and ResumptionCookie Properties, Derivation, and Usage 981 The purpose of the session identifier SessionID is to uniquely 982 identify a single session for the producer and consumer. A Producer 983 MAY use a random bit string or MAY use the method described in this 984 section or MAY use another proprietary method to distinguish clients. 986 We provide a more secure creation of the SessionID since it is used 987 with the ResumptionCookie derivation (defined later). Specifically, 988 the SessionID is derived as the encryption of the hash digest of a 989 server secret, TS, and an optional prefix (e.g., MovePrefix). 991 Encryption is done by the using a long-term secret key owned by the 992 server used for only this purpose, i.e., it is not used for consumer 993 traffic encryption. Mechanically, this derivation is: 995 SessionID = Enc(k1, H(TS || (Prefix3))), 997 where k1 is the long-term producer key. 999 For the resumption cookie, we require that it must be able to be used 1000 to recover the TS for a given session. Without TS, correct session 1001 communication is not possible. We derive it as the encryption of the 1002 hash digest of the server secret, TS, and the optional (MovePrefix, 1003 MoveToken) tuple (if created for the session). The producer must use 1004 a long-term secret key for this encryption. Mechanically, this 1005 derivation is: 1007 ResumptionCookie = Enc(k2, TS || ( (Prefix3 || MoveToken) )), 1009 where k2 is again a long-term producer key. Note that it may be the 1010 case that k1 = k2 (see above), though this is not required. 1012 With this SessionID and ResumptionCookie, the consumer then resumes a 1013 session by providing both the SessionID and ResumptionCookie to the 1014 producer. This is done to prove to the producer that the consumer 1015 who knows the SessionID is also in possession of the correct 1016 ResumptionCookie. The producer verifies this by computing 1018 (TS || ( (Prefix3 || MoveToken) )) = Dec(k2, ResumptionCookie) 1020 and checking the following equality 1022 SessionID = Enc(k1, H(TS || (Prefix3))) 1024 If equality holds, the producer uses the TS recovered from 1025 ResumptionCookie to re-initialize the previous session with the 1026 consumer. 1028 9.4. Key Derivation 1030 CCNxKE adopts the key schedule and derivation techniques defined in 1031 TLS 1.3 [TLS13]. Specifically, it uses the SS and ES to establish a 1032 common master secret (MS) and, from that, the traffic secret (TS). 1033 These dependencies are shown below. 1035 +------+ +------+ 1036 | KE-1 | | KE-2 | 1037 +------+ +----+-+ 1038 | | 1039 | | 1040 | | 1041 +---v--+ +----v-+ 1042 | SS +---+ +--+ ES | 1043 +------+ | | +------+ 1044 | | 1045 | | 1046 +-v----v-| 1047 | MK | 1048 +---+----+ 1049 | 1050 | 1051 | 1052 +-v--+ 1053 | TS | 1054 +----+ 1056 In this figure, KE-1 and KE-2 are two "sources" of keying material. 1057 The following table shows what these two sources are in different key 1058 exchange scenarios. 1060 +-------------+------------------------------+----------------------+ 1061 | Key | KE-1 | KE-2 | 1062 | Exchange | | | 1063 +-------------+------------------------------+----------------------+ 1064 | Full | ClientKeyShare and | ClientKeyShare and | 1065 | handshake | ServerKeyShare DH | ServerKeyShare DH | 1066 | | | | 1067 | Handshake | ClientKeyShare and | ClientKeyShare and | 1068 | with 1-RTT | ServerConfiguration public | ServerKeyShare DH | 1069 | | share DH | | 1070 | | | | 1071 | PSK | Pre-shared key | Pre-shared key | 1072 +-------------+------------------------------+----------------------+ 1074 Given the values for SS and ES, the remaining derivation steps are 1075 below as defined in [TLS13]. They are repeated here for posterity. 1077 1. xSS = HKDF-Extract(0, SS). Note that HKDF-Extract always 1078 produces a value the same length as the underlying hash function. 1080 2. xES = HKDF-Extract(0, ES) 1082 3. mSS = HKDF-Expand-Label(xSS, "expanded static secret", 1083 handshake_hash, L) 1085 4. mES = HKDF-Expand-Label(xES, "expanded ephemeral secret", 1086 handshake_hash, L) 1088 5. master_secret = HKDF-Extract(mSS, mES) 1090 6. traffic_secret_0 = HKDF-Expand-Label(master_secret, "traffic 1091 secret", handshake_hash, L) 1093 In all computations, the value "handshake_hash" is defined as the 1094 SHA256 hash digest of all CCNxKE messages contained up to the point 1095 of derivation. More details are given in Section 7.3.1 of [TLS13]. 1097 Updating the traffic secret using the re-key message (defined later) 1098 increments traffic_secret_N to traffic_secret_(N+1). This update 1099 procedure works as follows: 1101 traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, "traffic 1102 secret", "", L) 1104 9.5. Secret Generation and Lifecycle 1106 The secrets (keys and IVs) used to encrypt and authenticate traffic 1107 are derived from the traffic secret. The explicit derivation 1108 formula, as is defined in [TLS13], is as follows: 1110 secret = HKDF-Expand-Label(Secret, phase + ", " + purpose, 1111 handshake_context, key_length) 1113 In this context, secret can be a key or IV. This formula is used 1114 when deriving keys based on a non-forward-secure SS and the forward- 1115 secure TS. The following table enumerates the values for "phase", 1116 and "handshake_context" to be used when defining keys for different 1117 purposes. 1119 +-------------+--------+------------------+-------------------------+ 1120 | Record Type | Secret | Phase | Handshake Context | 1121 +-------------+--------+------------------+-------------------------+ 1122 | 1-RTT | xSS | "early handshake | HELLO + | 1123 | Handshake | | key expansion" | ServerConfiguration + | 1124 | | | | Server Certificate | 1125 | | | | | 1126 | 1-RTT Data | xSS | "early | HELLO + | 1127 | | | application data | ServerConfiguration + | 1128 | | | key expansion" | Server Certificate | 1129 | | | | | 1130 | Application | TS | "application | HELLO ... Finished | 1131 | Data | | data key | | 1132 | | | expansion" | | 1133 +-------------+--------+------------------+-------------------------+ 1135 Moreover, the following table indicates the values of "purpose" used 1136 in the generation of each secret. 1138 +------------------+--------------------+ 1139 | Secret | Purpose | 1140 +------------------+--------------------+ 1141 | Client Write Key | "client write key" | 1142 | | | 1143 | Server Write Key | "server write key" | 1144 | | | 1145 | Client Write IV | "client write IV" | 1146 | | | 1147 | Server Write IV | "server write IV" | 1148 +------------------+--------------------+ 1150 (( TODO: should we add examples for each of the above variants? )) 1152 10. Re-Key Message 1154 Either the client and server can trigger a key update by sending an 1155 Interest or Content Object with a KEPayload field containing the flag 1156 KeyUpdate. The KEPayload will be encrypted by the traffic key. Upon 1157 receipt, the recipient MUST update the traffic secret as defined 1158 above and re-compute the traffic encryption and authentication keys. 1159 The previous traffic key must be securely discarded. 1161 11. Application Data Protocol 1163 Once traffic keys and the associated IVs are derived from the CCNxKE 1164 protocol, all subsequent Interest and Content Object messages are 1165 encrypted. Packet encryption uses the TLV encapsulation mechanism 1166 specified in [TLVENCAP]. For Interest encryption, the Salt in 1168 [TLVENCAP] is set to the packet sequence number. The same 1169 substitution is done for Content Object encryption. Similarly, the 1170 KeyId field is substituted with the SessionID derived by the CCNxKE 1171 protocol. Packet sequence numbers are 64-bit numbers initialized to 1172 0 when after the traffic secret is calculated. Each message 1173 increments and uses the sequence number when sending a new datagram 1174 (Interest). The sequence number for an Interest matches that of the 1175 Content Object response. 1177 12. Security Considerations 1179 For CCNxKE to be able to provide a secure connection, both the 1180 consumer and producer systems, keys, and applications must be secure. 1181 In addition, the implementation must be free of security errors. 1183 The system is only as strong as the weakest key exchange and 1184 authentication algorithm supported, and only trustworthy 1185 cryptographic functions should be used. Short public keys and 1186 anonymous servers should be used with great caution. Implementations 1187 and users must be careful when deciding which certificates and 1188 certificate authorities are acceptable; a dishonest certificate 1189 authority can do tremendous damage. 1191 13. References 1193 13.1. Normative References 1195 [CCNxMessages] 1196 Mosko, M. and I. Solis, "CCNx Messages in TLV Format", 1197 January 2016, . 1200 [DH] Diffie, W. and M. Hellman, "New Directions in 1201 Cryptography", IEEE Transactions on Information Theory, 1202 V.IT-22 n.6 , June 1977. 1204 [DTLS12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1205 Security Version 1.2", January 2012, 1206 . 1208 [ECDSA] American National Standards Institute, "Public Key 1209 Cryptography for the Financial Services Industry: The 1210 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1211 ANSI ANS X9.62-2005, November 2005. 1213 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 1214 Operation: Galois/Counter Mode (GCM) and GMAC", 1215 NIST Special Publication 800-38D, November 2007. 1217 [QUIC] Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and 1218 Reliable Transport for HTTP/2", December 2015. 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, 1222 DOI 10.17487/RFC2119, March 1997, 1223 . 1225 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1226 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1227 . 1229 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1230 "Randomness Requirements for Security", BCP 106, RFC 4086, 1231 DOI 10.17487/RFC4086, June 2005, 1232 . 1234 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1235 DOI 10.17487/RFC4302, December 2005, 1236 . 1238 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1239 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1240 . 1242 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1243 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1244 . 1246 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1247 Key Derivation Function (HKDF)", RFC 5869, 1248 DOI 10.17487/RFC5869, May 2010, 1249 . 1251 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1252 Extensions: Extension Definitions", RFC 6066, 1253 DOI 10.17487/RFC6066, January 2011, 1254 . 1256 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1257 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1258 January 2012, . 1260 [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm 1261 without Bit Shifting", RFC 6479, DOI 10.17487/RFC6479, 1262 January 2012, . 1264 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 1265 Obtaining Digital Signatures and Public-Key 1266 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 1267 120-126., February 1978. 1269 [SALSA20] Bernstein, D., "Salsa20 specification", 1270 www.http://cr.yp.to/snuffle/spec.pdf , April 2005. 1272 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1273 Version 1.3", December 2015, . 1276 [TLVENCAP] 1277 Mosko, M. and C. Wood, "CCNx Packet Encapsulation", n.d., 1278 . 1280 13.2. Informative References 1282 [HASHCHAIN] 1283 L. Lamport, "Password Authentication with Insecure 1284 Communication", ANSI Communications of the ACM 24.11, pp 1285 770-772, November 1981. 1287 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1288 "Transport Layer Security (TLS) Session Resumption without 1289 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1290 January 2008, . 1292 Authors' Addresses 1294 M. Mosko 1295 PARC 1297 EMail: marc.mosko@parc.com 1299 Ersin Uzun 1300 PARC 1302 EMail: ersin.uzun@parc.com 1304 Christopher A. Wood 1305 PARC 1307 EMail: christopher.wood@parc.com