idnits 2.17.1 draft-wood-icnrg-ccnxkeyexchange-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Finished' is mentioned on line 889, but not defined == Missing Reference: 'ConsumerData' is mentioned on line 479, but not defined == Missing Reference: 'ProducerData' is mentioned on line 486, but not defined == Missing Reference: 'ResumptionCookie' is mentioned on line 887, but not defined == Missing Reference: 'ServerExtensions' is mentioned on line 886, but not defined == Unused Reference: 'RFC5077' is defined on line 1265, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (ref. 'DTLS12') (Obsoleted by RFC 9147) -- Duplicate reference: RFC6347, mentioned in 'RFC6347', was also mentioned in 'DTLS12'. ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-11 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 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: Experimental PARC 5 Expires: September 14, 2017 C. Wood 6 University of California Irvine 7 March 13, 2017 9 CCNx Key Exchange Protocol Version 1.0 10 draft-wood-icnrg-ccnxkeyexchange-02 12 Abstract 14 This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) 15 protocol. The CCNxKE protocol allows two peers to establish a 16 shared, forward-secure key for secure and confidential communication. 17 The protocol is designed to prevent eavesdropping, tampering, and 18 message forgery between two peers. It is also designed to minimize 19 the number of rounds required to establish a shared key. In the 20 worst case, it requires two RTTs between a consumer and producer to 21 establish a shared key. In the best case, one RTT is required before 22 sending any application data. This document outlines how to derive 23 the keys used to encrypt traffic for a session and shows how session 24 information is exchanged between a consumer and producer using 25 message encapsulation. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 75 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 78 5. CCNxKE Overview . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Connection Establishment Latency . . . . . . . . . . . . 7 80 5.2. Connection Migration and Resumption . . . . . . . . . . . 7 81 5.3. Re-Transmissions, Timeouts, and Replay Prevention . . . . 8 82 5.4. Loss Sensitivity . . . . . . . . . . . . . . . . . . . . 8 83 6. The CCNxKE Protocol . . . . . . . . . . . . . . . . . . . . . 9 84 6.1. Round Overview . . . . . . . . . . . . . . . . . . . . . 9 85 6.2. Round 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 6.3. Round 2 . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.4. Round 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 7. Alternative Exchanges . . . . . . . . . . . . . . . . . . . . 17 89 7.1. One-RTT Exchange . . . . . . . . . . . . . . . . . . . . 18 90 8. Resumption and PSK Mode . . . . . . . . . . . . . . . . . . . 20 91 9. Secret Derivation . . . . . . . . . . . . . . . . . . . . . . 21 92 9.1. SourceCookie Derivation . . . . . . . . . . . . . . . . . 21 93 9.2. Move Derivation . . . . . . . . . . . . . . . . . . . . . 21 94 9.3. SessionID and ResumptionCookie Properties, Derivation, 95 and Usage . . . . . . . . . . . . . . . . . . . . . . . . 22 96 9.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . 23 97 9.5. Secret Generation and Lifecycle . . . . . . . . . . . . . 25 98 10. Re-Key Message . . . . . . . . . . . . . . . . . . . . . . . 26 99 11. Application Data Protocol . . . . . . . . . . . . . . . . . . 26 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 103 13.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 106 1. Introduction 108 DISCLAIMER: This is a WIP draft of CCNxKE and has not yet seen 109 rigorous security analysis. 111 Ephemeral sessions similar to those enabled by TLS 1.3 [TLS13], QUIC 112 [QUIC], and DTLS 1.2 [DTLS12] are needed for some CCN exchanges 113 between consumers and producers. Currently, there does not exist a 114 standard way to establish these sessions. Thus, the primary goal of 115 the CCNxKE protocol is to provide privacy and data integrity between 116 two CCN-enabled peers (e.g., a consumer and producer engaged in 117 session-based communication). It is built on the CCNx 1.0 protocol 118 and only relies upon standard Interest and Content Objects as a 119 vehicle for communication. The CCNxKE protocol is used to bootstrap 120 session-based communication, wherein traffic is encapsulated and 121 encrypted using symmetric-key cryptography for transmission between 122 two endpoints (i.e., a consumer and producer). The CCNxKE protocol 123 enables this form of communication by establishing shared state, 124 i.e., shared, ephemeral, and forward-secure symmetric keys. This 125 protocol has the following four main properties: 127 - Each peer's identity can be authenticated using asymmetric, or 128 public key, cryptography (e.g., RSA [RSA], ECDSA [ECDSA], etc.). 129 Server authentication is mandatory whereas mutual authentication 130 is optional. 132 - The negotiation of a forward-secure shared secret is protected 133 from eavesdroppers and man-in-the-middle (MITM) attacks. 135 - The negotiation is reliable: no attacker can modify the 136 negotiation communication without being detected by the parties to 137 the communication. 139 - The state of a CCNxKE session can be securely migrated between an 140 endpoint performing authentication and that which provides content 141 using a "move token." This allows authentication and 142 authorization to be separated from encryption for a session, 143 enabling different systems to complete these steps. 145 Usage of CCNxKE is entirely independent of upper-layer application 146 protocols. Session-based communication via encapsulation and 147 encryption enables secure, confidential, and authenticated 148 communication between two peers. One advantage of this protocol is 149 that it facilitates the creation and use of ephemeral CCN Interest 150 and Content Objects. 152 CCNxKE also introduces a new type of cookie based on reverse hash 153 chains [HASHCHAIN] to help limit the amount of significant server 154 work done in response to a client or consumer Interest. TCP-based 155 protocols, such as TLS [TLS13], use the TCP 3-way handshake for such 156 proof. UDP-based protocols, such as QUIC [QUIC] and DTLS 1.2 157 [DTLS12], use an optional session address token or cookie that must 158 be presented by the client (consumer) to prove ownership of an 159 address during a key exchange procedure. Without source addresses, 160 our cookie technique ensures that the same entity which requested 161 server information, e.g., the public configuration data, is the same 162 entity that wishes to complete a key exchange. 164 The main contribution of this work is adapting key exchange 165 principles to the pull-based CCNx communication model. CCNxKE only 166 assumes that a consumer knows a first name prefix to initiate the key 167 exchange. The first Interest does not need to be a CCNxKE packet -- 168 the producer can signal back to the consumer that it requires CCNxKE 169 before progressing. 171 This specification does not subsume other ICN-compliant key exchange 172 protocols. Nor does its existence imply that all encryption in an 173 ICN must be based on sessions. It was designed specifically to solve 174 the problem of session-based encryption in ICN. 176 1.1. Conventions and Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in RFC 181 2119 [RFC2119]. 183 The following terms are used: 185 Consumer/Client: The CCN consumer initiating the CCNxKE key exchange 186 via a first Interest. 188 Producer/Server: The CCN producer receiving or accepting the CCNxKE 189 key exchange request request Interest. 191 Sender: An endpoint that originates a message. 193 Receiver: An endpoint that is receiving messages. 195 Peer: An endpoint. When discussing a particular endpoint, "peer" 196 refers to the endpoint that is remote to the primary subject of 197 discussion. 199 Connection: A network path of n >= 1 hops between the consumer and 200 producer. 202 Endpoint: Either the consumer or producer of the connection. 204 Handshake: A series of message exchanges between two peers that is 205 used to perform a task (e.g., perform key exchange and derivation). 207 Session: An association between a consumer and a producer resulting 208 from a CCNxKE handshake. 210 DH: A Diffie Hellman key exchange procedure [RFC2631] [DH]. 212 Key Share: One half of the shared-secret provided by one peer 213 performing a DH key exchange. 215 Forward-secure: The property that compromising any long-term secrets 216 (e.g., cryptographic keys) does not compromise any session keys 217 derived from those long-term secrets. 219 CONFIG information: A data structure created by a producer which 220 contains long-term cryptographic material and associated information 221 needed by a client to initiate a key-exchange with the producer. 223 HELLO exchange: An exchange between a consumer and producer wherein 224 the consumer retrieves the CONFIG information from the producer. 226 Payload: The payload section of a CCNxMessage as defined in 227 [CCNxMessages]. 229 KEPayload: A payload for information used in the CCNxKE protocol 230 which is a generic key-value store. The KEPayload is _not_ the 231 CCNxMessage payload. 233 CCNxName: A CCNxName as defined in [CCNxMessages]. 235 Semi-static: Short-term. 237 Short-term Secret (SS): A secret which is derived from the server's 238 semi-static DH share and the client's fresh DH share. 240 Forward-secure Secret (FSK): A secret which is derived from fresh 241 (i.e., generated on demand at random) DH shares from both the 242 consumer and producer for the given connection. 244 HKDF: Hash-based key-derivation function [RFC5869]. 246 2. Goals 248 The goals of the CCNxKE protocol, in order of priority, are as 249 follows: 251 1. Cryptographic security: CCNxKE should be used to securely 252 establish a session and all related shared secrets between two 253 peers. Cryptographic properties of interest include: (a) 254 forward-secure session key derivation and (b) (state and 255 computational) denial-of-service prevention at the producer (see 256 [RFC4987]) that is no worse than DTLS 1.2 [DTLS12]}. For property 257 (a), different keys (and relevant algorithm parameters such as 258 IVs) are established for each communication direction, i.e., from 259 consumer to producer and producer to consumer. For property (b), 260 we use a new type of stateless cookie inspired by that of DTLS 261 1.2. 263 2. Interoperability: Independent programmers should be able to 264 develop applications utilizing CCNxKE that can successfully 265 exchange cryptographic parameters without knowledge of one 266 another's code. 268 3. Extensibility: CCNxKE seeks to provide a framework into which new 269 public key and symmetric key methods and algorithms can be 270 incorporated without breaking backwards compatibility or 271 requiring all clients to implement new functionality. Moreover, 272 the protocol should be able to support a variety of peer 273 authentication protocols, e.g., EAP-TLS, EAP-PWD, or a simple 274 challenge-response protocol. 276 4. Relative efficiency: CCNxKE tries to create sessions with minimal 277 computation, bandwidth, and message complexity. In particular, 278 it seeks to create sessions with as few end-to-end round trips as 279 possible, and also provide support for accelerated session 280 establishment and resumption when appropriate. At most 2 round- 281 trip-times (RTTs) should be used to establish a session key, with 282 the possibility of 1-RTT accelerated starts and resumption. 284 3. Scope 286 This document and the CCNxKE protocol are influenced by the TLS 1.3 287 [TLS13], QUIC [QUIC], and DTLS 1.2 [DTLS12] protocols. The reader, 288 however, does not need a detailed understanding of those protocols to 289 understand this document. Moreover, where appropriate, references to 290 related protocols are made for brevity and technical clarity. This 291 document is intended primarily for readers who will be implementing 292 the protocol and for those doing cryptographic analysis of it. The 293 specification has been written with this in mind and it is intended 294 to reflect the needs of those two groups. 296 This document is not intended to supply any details of service 297 definition or of interface definition, although it does cover select 298 areas of policy as they are required for the maintenance of solid 299 security. 301 4. Presentation Language 303 This document uses a presentation language of remote calls (i.e. 304 packet messages) similar to the format used by TLS [TLS13]. 306 5. CCNxKE Overview 308 5.1. Connection Establishment Latency 310 CCNxKE operates in three rounds, where each round requires a single 311 RTT to complete. The full execution of the protocol therefore 312 requires 2 RTTs before a session is fully established. The full 313 version is used when consumers have no a priori information about the 314 producer. An accelerated one round version is used when the consumer 315 has valid configuration information and a source cookie from the 316 producer; this variant requires 1 RTT before a session is 317 established. 319 5.2. Connection Migration and Resumption 321 CCN end hosts lack the notion of addresses. Thus, the producer 322 endpoint for a given execution of the CCNxKE protocol is one which 323 can authoritatively serve as the owner of a particular namespace. 324 For example, a consumer may wish to establish a session with a 325 producer who owns the /company/foo namespace. The specific end host 326 which partakes in the protocol instance is not specified, by virtue 327 of the fact that all CCNxKE messages are based on well-defined names. 328 This enables the producer end-host which partakes in the protocol to 329 change based on the name of the CCNxKE messages. Consequently, to 330 maintain correctness, it is important that a single execution of the 331 protocol operates within the same trusted context; this does not mean 332 that the same producer end-host is required to participate in all 333 three steps of the protocol. Rather, it means that the end-host 334 responding to a CCNxKE message must be trusted by the consumer to 335 complete the exchange. CCNxKE is designed to enable this sort of 336 producer migration. 338 For example, a consumer may use an initial name like '/parc/ 339 index.html' that works like an IP any cast address and could got to 340 one of several systems. CCNxKE allows the responding endpoint to 341 include a localized name to ensure that subsequent messages from the 342 consumer come back to the same producer. CCNxKE also allows the key 343 exchange peer to securely hand-off the session to a content producer 344 peer via another name and session token once the client is 345 authenticated and keying material is exchanged. 347 5.3. Re-Transmissions, Timeouts, and Replay Prevention 349 CCNxKE timeouts and retransmissions are handled using the approach in 350 [RFC6347]. One primary difference is that timer values may need to 351 be adjusted (elongated) due to prefix shifts and the need for a 352 producer to transfer security information between different machines. 354 Replay attack prevention is also an optional feature, and if used, 355 MAY be done using one of the following two approaches at the receiver 356 (producer): 358 - IPSec AH [RFC4302] and ESP [RFC4303] style replay detection based 359 on sliding windows and monotonically increasing sequence numbers 360 for windows. Note that the sliding window inherently limits the 361 performance of the protocol to the window size, since only a 362 finite number of messages may be received within a given window 363 (based on the window size). 365 - The optimized anti-replay algorithm of [RFC6479]. 367 5.4. Loss Sensitivity 369 CCNxKE messages are transferred using standard CCN Interest and 370 Content Objects and are therefore subject to loss as any datagram. 371 This means that traffic encrypted with keys derived from CCNxKE must 372 be stateless. They cannot depend on in-order arrival. This problem 373 is solved by two mechanisms: (1) by prohibiting stream ciphers of any 374 kind and (2) adding sequence numbers to each message that allow the 375 receiver to identify and use the correct cryptographic state to 376 decrypt the message. Moreover, sequence numbers permit anti-replay 377 mechanisms similar to those used in DTLS [DTLS12] as mentioned above. 379 6. The CCNxKE Protocol 381 This section describes the CCNxKE protocol in detail at the message 382 level. The specific encoding of those messages is given later. 383 CCNxKE could be adapted to different wire format encodings, such as 384 those used by the NDN protocol. 386 The following assumptions are made about peers participating in the 387 CCNxKE protocol: 389 - Consumers know the namespace prefix of the producer for which they 390 wish to execute the CCNxKE protocol. 392 - CCNxKE protocol information is carried in a distinguished field 393 outside of the payload of CCN messages. This is done to 394 distinguish key exchange material with application data in a 395 message. This is necessary for 0 RTT packets that carry both 396 keying material and application payload. 398 - CCNxKE does not require any special behavior of intermediate 399 systems to forward packets. 401 - CCNxKE packets generally should not be cached for significant 402 periods of time, as use normal protocol methods to limit caching. 403 Part of this is achieved through the use of consumer-specific 404 nonces in names. 406 6.1. Round Overview 408 CCNxKE is composed of three rounds. The purpose of each round is 409 described below. 411 - Round 1: Perform a bare HELLO exchange to obtain the extensions 412 (parameters) for the key exchange provided by the producer and a 413 source cookie to prove ownership of the "source" of the request. 415 - Round 2: Perform the initial FULL-HELLO exchange to establish a 416 forward-secure key used for future communication, i.e., Interest 417 and Content Object exchanges in the context of the newly 418 established session. 420 - Round 3: Send the first bit of application data and (optionally) 421 transfer resumption cookie(s) from the producer to the consumer. 423 Conceptually, there are two secrets established during a single 424 execution of CCNxKE: 426 - Static Secret (SS): A secret which is derived in one of two ways: 427 (a) from the client and server ephemeral key shares and (b) from 428 the server's semi-static share and the client's ephemeral key 429 share. Keying material derived from SS in option (a) is not 430 forward secure. 432 - Ephemeral Secret (ES): A secret which is derived from both the 433 client and server ephemeral key shares. 435 Depending on the mode in which CCNxKE is used, these secrets can be 436 established in a variety of ways. Key derivation details are 437 outlined in Section Section 9. 439 All secrets are derived with the appropriate amount of randomness 440 [RFC4086]. An overview of the messages sent in each of the three 441 rounds to establish and use these secrets is shown in Figure Figure 1 442 below. This diagram omits some parts of each message for brevity. 444 Consumer Producer 446 HELLO: 447 + SourceChallenge 448 I[/prefix/random-1] 449 --------> 450 HELLO-REJECT: 451 + Timestamp 452 + SourceCookie 453 + pinned-prefix* 454 + ServerChallenge* 455 + ServerConfiguration* 457 CO[/prefix/random-1] 458 <--------- 459 FULL-HELLO: 460 + ClientKeyShare 461 + SourceCookie 462 + SourceProof 463 + Timestamp 464 I[/pinned-prefix/random-2] 465 --------> 466 HELLO-ACCEPT: 467 + ServerKeyShare 468 + SessionID 469 + [CertificateRequest*] 470 + [CertificateVerify*] 471 + [MovePrefix*, MoveToken)*] 472 + [Finished] 473 CO[/pinned-prefix/random-2] 474 <-------- 475 **key exchange complete** 476 Payload: 477 + MoveToken* 478 + MoveProof* 479 + [ConsumerData] 481 I[/prefix/SessionID/[...]] 482 --------> 483 + NewSessionID* 484 + NewSessionIDTag* 485 Payload: 486 [ProducerData] 487 CO[/prefix/SessionID/[...]] 488 <-------- 490 Repeat with data <--------> Repeat with data 492 * Indicates optional or situation-dependent 493 messages that are not always sent. 495 {} Indicates messages protected using keys 496 derived from the short-term secret (SS). 498 () Indicates messages protected using keys 499 derived from the ephemeral secret (ES). 501 [] Indicates messages protected using keys 502 derived from the traffic secret (TS). 504 Figure 1: High-level message flow for full CCNxKE protocol with a 505 maximum 2-RTT delay. 507 In the following sections, we will describe the format of each round 508 in this protocol in more detail. 510 We do not specify the encoding of CCNxKE data sent in Interest and 511 Content Object payloads. Any viable encoding will suffice, so long 512 as both parties agree upon the type. For example, the payload could 513 be structured and encoded as a JSON object, e.g., 515 { "ClientKeyShare" : 0xaa, "SourceCookie" : 0xbb, "SourceProof" : 516 0xbb, ... } 518 For now, we assume some valid encoding mechanism is used to give 519 structure to message payloads. Moreover, we assume that these 520 payloads are carried in a distinguished CCNxKE payload field 521 contained in the Interest and Content Objects. 523 6.2. Round 1 525 The purpose of Round 1 is to acquire a cookie to binding the exchange 526 to the initial consumer and the public configuration information 527 contained in the ServerConfiguration structure. This information is 528 used in the second round when performing the actual key exchange. To 529 that end, the format of the Round 1 message is trivial. First, the 530 client issues an Interest with the following name 532 /prefix/random-1 534 where random-1 is a randomly generated 64-bit nonce. This interest 535 carries a KEPayload with the following information: 537 +-----------------+-------------------------------------+-----------+ 538 | HELLO Field | Description | Optional? | 539 +-----------------+-------------------------------------+-----------+ 540 | SourceChallenge | A random value generated to prove | No | 541 | | ownership of the consumer's | | 542 | | "source" | | 543 +-----------------+-------------------------------------+-----------+ 545 Upon receipt of this interest, the producer responds with a HELLO- 546 REJECT Content Object whose KEPayload has the following fields: 548 +---------------------+---------------------------------+-----------+ 549 | HELLO-REJECT Field | Description | Optional? | 550 +---------------------+---------------------------------+-----------+ 551 | Timestamp | Current server timestamp | No | 552 | | | | 553 | SourceCookie | A cookie that binds the | No | 554 | | consumer's challenge to the | | 555 | | current timestamp | | 556 | | | | 557 | PinnedPrefix | A new prefix that pins the key | Yes | 558 | | exchange to a particular server | | 559 | | | | 560 | ServerConfiguration | The public server configuration | Yes | 561 | | information | | 562 | | | | 563 | ServerChallenge | A random value for the consumer | Yes | 564 | | to include in its | | 565 | | CertificateVerify if the server | | 566 | | requires client authentication | | 567 +---------------------+---------------------------------+-----------+ 569 The Timestamp and SourceCookie are used in Round 2. Their derivation 570 is described later. If the server provides a PinnedPrefix then the 571 consumer must use this prefix in Round 2 in lieu of the Round 1 name 572 prefix. (This is because the PinnedPrefix identifies a particular 573 endpoint that is capable of completing the key exchange.) 575 The ServerConfiguration information is a semi-static catalog of 576 information that consumers may use to complete future key exchanges 577 with the producer. The fields of the ServerConfiguration information 578 are shown below. 580 +---------------------+---------------------------------+-----------+ 581 | ServerConfiguration | Description | Optional? | 582 | Field | | | 583 +---------------------+---------------------------------+-----------+ 584 | KEXS | Supported elliptic-curve key- | No | 585 | | exchange algorithms | | 586 | | | | 587 | AEAD | Supported AEAD algorithms | No | 588 | | | | 589 | PUBS | List of public values (for key | No | 590 | | exchange algorithm) encoded | | 591 | | appropriately for the given | | 592 | | group | | 593 | | | | 594 | EXPRY | Expiration timestamp (i.e., | No | 595 | | longevity of the | | 596 | | ServerConfiguration structure) | | 597 | | | | 598 | VER | Version of the CONFIG structure | Yes | 599 | | | | 600 | CERT | Server certificate | No | 601 | | | | 602 | SIG | Signature produced by the | No | 603 | | server over the entire | | 604 | | ServerConfiguration message | | 605 +---------------------+---------------------------------+-----------+ 607 The KEXS is a data structure that enumerates the elliptic curve key- 608 exchange algorithms that are supported by the producer (see [QUIC] 609 for more details). Currently, only the following curves are 610 supported: 612 - Curve25519 614 - P-256 616 Selection criteria for these curves is given at 617 http://safecurves.cr.yp.to/. 619 The AEAD structure enumerates the supported AEAD algorithms used for 620 symmetric-key authenticated encryption after the session has been 621 established. Currently, the only supported algorithms are: 623 - AES-GCM-(128,192,256) [GCM]: a 12-byte tag is used, where the 624 first four bytes are taken from the FSK key-derivation step and 625 the last eight are taken from the initial consumer nonce. 627 - ChaCha20+Poly1305 [RFC7539]. 629 The key sizes and related parameters are provided with the AEAD tag 630 in the CONFIG structure. 632 The PUBS structure contains the public values for the initial key 633 exchange. Both Curve25519 and P-256 provide their own set of 634 accepted parameters. Thus, the only values provided here are the 635 random curve elements used in the DH operation. 637 The EXPRY value is an absolute timestamp that indicates the longevity 638 of the ServerConfiguration. 640 The CERT and SIG values contain the server's certificate and a 641 signature generated over the entire ServerConfiguration field. This 642 signature is generated with the corresponding private key. 644 6.3. Round 2 646 The purpose of Round 2 is to perform the initial FULL-HELLO exchange 647 to establish a forward-secure key used for future communication. It 648 is assumed that the consumer already has the ServerConfiguration 649 information that is provided from the producer in Round 1. It is 650 also assumed that the consumer has a 652 Moreover, assume that nonce2 is a ephemeral nonce provided by the 653 producer in Round 1. Then, the consumer issues an Interest with the 654 following name: 656 /prefix/random-2 658 and a KEPayload with the following information: 660 +----------------------+--------------------------------+-----------+ 661 | FULL-HELLO Field | Description | Optional? | 662 +----------------------+--------------------------------+-----------+ 663 | ClientKeyShare | The client's key share for the | No | 664 | | key exchange | | 665 | | | | 666 | SourceCookie | SourceCookie provided by the | No | 667 | | server in Round 1 | | 668 | | | | 669 | SourceProof | The SourceCookie construction | No | 670 | | proof provided by the client | | 671 | | | | 672 | Timestamp | The timestamp provided by the | No | 673 | | server in Round 1 | | 674 | | | | 675 | ConsumerPrefix | The consumer's prefix that can | Yes | 676 | | be used for the producer to | | 677 | | send interests to the consumer | | 678 | | | | 679 | PreSharedKey | A pre-shared key that can be | Yes | 680 | | configured between a consumer | | 681 | | and producer | | 682 | | | | 683 | ResumptionCookie | The ResumptionCookie derived | Yes | 684 | | from a past session | | 685 | | | | 686 | {MoveChallenge} | A move challenge generated | Yes | 687 | | identically to the | | 688 | | SourceChallenge | | 689 | | | | 690 | {AlgChoice} | Algorithm (KEXS and AEAD) | No | 691 | | options choice (a list of tags | | 692 | | echoed from the | | 693 | | ServerConfiguration) | | 694 | | | | 695 | {Proof} | Proof of demand (i.e., a | No | 696 | | sorted list of types of proof | | 697 | | the consumer will expect) | | 698 | | | | 699 | {CCS} | Compressed certificate set | No | 700 | | that the consumer possesses | | 701 | | | | 702 | {ConsumerData} | Application data encrypted | Yes | 703 | | under a key derived from SS | | 704 | | (in a 1-RTT exchange) | | 705 | | | | 706 | ServerNameIndication | A server name indication (as a | Yes | 707 | | CCNxName) defined in Section 3 | | 708 | | of [RFC6066] | | 709 | | | | 710 | Certificate | The client's certificate | Yes | 711 | | | | 712 | CertificateVerify | A signature generated over the | Yes | 713 | | entire FULL-HELLO message | | 714 +----------------------+--------------------------------+-----------+ 715 ((TODO: provide more details about each of these fields)) 717 Upon receipt of this interest, the producer performs the DH 718 computation to compute ES and SS, decrypts all protected fields in 719 the consumer's KEPayload, and validates the algorithm choice 720 selection (AlgChoice). If any of these steps fail, the producer 721 replies with with a HELLO-REJECT Content Object whose KEPayload 722 contains a REJ flag and the reason of the error. The REJ flag and 723 value are encrypted by the SS (if possible). 725 If the above steps complete without failure or error, then the 726 producer responds with a Content Object whose KEPayload has the 727 following fields: 729 +--------------------------+----------------------------+-----------+ 730 | HELLO-ACCEPT Field | Description | Optional? | 731 +--------------------------+----------------------------+-----------+ 732 | SessionID | Cleartext session | No | 733 | | identifier | | 734 | | | | 735 | ServerKeyShare | Server's key share for the | No | 736 | | ES derivation | | 737 | | | | 738 | {ServerExtensions} | Additional extensions | Yes | 739 | | provided by the server, | | 740 | | encrypted under ES | | 741 | | | | 742 | [ResumptionCookie] | Resumption cookie | Yes | 743 | | encrypted under a TS- | | 744 | | derived key | | 745 | | | | 746 | {(MovePrefix,MoveToken)} | Third CCNxName prefix and | Yes | 747 | | token to use when moving | | 748 | | to session establishment | | 749 | | | | 750 | CertificateRequest* | Server certificate that | Yes | 751 | | matches the type of proof | | 752 | | provided by the client | | 753 | | | | 754 | CertificateVerify* | Signature generated over | Yes | 755 | | the entire HELLO-ACCEPT | | 756 | | message | | 757 +--------------------------+----------------------------+-----------+ 759 If a MovePrefix and MoveToken tuple is provided then in the HELLO- 760 ACCEPT message then a CertificateVerify (signature) MUST also be 761 provided in the response. 763 6.4. Round 3 765 In Round 3, the consumer sends interests whose name and optional 766 Payload are encrypted using one of the forward-secure keys derived 767 after Round 2. In normal operation, the producer will respond with 768 Content Objects whose Payloads are encrypted using a different 769 forward-secure key. That is, interests and Content Objects are 770 encrypted and authenticated using two separate keys. The producer 771 may also optionally provide a new resumption cookie (RC) with a 772 Content Object response. This is used to keep the consumer's 773 resumption cookie fresh and to also support 0 RTT resumption. In 774 this case, the producer's Content Object response has the following 775 fields: 777 - Payload: the actual Content Object payload data encrypted with the 778 producer's forward-secure key. 780 - ResumptionCookie: A new resumption cookie to be used for resuming 781 this session in the future. 783 The producer is free to choose the frequency at which new resumption 784 cookies are issued to the consumer. 786 The producer may also reply with a new SessionID. This is done if 787 the client presented a MoveToken and MoveProof. A NewSessionID must 788 be accompanied with a NewSessionIDTag, which is equal to the HMAC of 789 NewSessionID computed with the traffic-secret key. A client MUST 790 then use NewSessionID instead of SessionID after verifying the 791 NewSessionIDTag. 793 7. Alternative Exchanges 795 CCNxKE also supports one-round key exchange and session resumption. 796 These variants are outlined below. The key material differences are 797 described later. In these variants, we use message 798 ExchangeSourceCookie to denote the following exchange: 800 Consumer Producer 802 HELLO: 803 + SourceChallenge 804 I[/prefix/random-1] 805 --------> 806 HELLO-REJECT: 807 + Timestamp 808 + SourceCookie 809 ServerChallenge* 810 ServerConfiguration* 812 CO[/prefix/random-1] 813 <--------- 815 Figure 2: SourceCookie exchange -- ExchangeSourceCookie. 817 7.1. One-RTT Exchange 818 Consumer Producer 819 --------> 820 ExchangeSourceCookie 821 <--------- 822 FULL-HELLO: 823 + ClientKeyShare 824 + SourceCookie 825 + SourceProof 826 + Timestamp 827 + Certificate* 828 + CertificateVerify* 829 + {ConsumerData*} 830 I[/prefix/random-2] 831 --------> 832 HELLO-ACCEPT: 833 + ServerKeyShare 834 + SessionID 835 + [ServerExtensions] 836 + [ResumptionCookie] 837 + [CertificateRequest*] 838 + [CertificateVerify*] 839 + [MovePrefix*, MoveToken*] 840 + [Finished] 841 CO[/prefix/random-2] 842 <-------- 843 **key exchange complete** 844 Send encrypted data <--------> Send encrypted data 846 * Indicates optional or situation-dependent 847 messages that are not always sent. 849 {} Indicates messages protected using keys 850 derived from the short-term secret (SS). 852 () Indicates messages protected using keys 853 derived from the ephemeral secret (ES). 855 [] Indicates messages protected using keys 856 derived from the traffic secret (TS). 858 Figure 3: Exchange with 1 RTT. 860 As with TLS, the initial application data is protected with the 862 8. Resumption and PSK Mode 864 In this mode, the client uses its ResumptionCookie to re-create a 865 previous session. The client also provides a key share in case the 866 server opts to fall back and establish a fresh key. If the server 867 accepts the ResumptionCookie then it MUST issue a new SessionID and 868 ResumptionCookie for future use with the client. 870 Consumer Producer 871 --------> 872 ExchangeSourceCookie 873 <--------- 874 FULL-HELLO: 875 + ClientKeyShare 876 + SourceCookie 877 + SourceProof 878 + Timestamp 879 + PreSharedKey 880 + ResumptionCookie 881 I[/prefix/random-2] 882 --------> 883 HELLO-ACCEPT: 884 + ServerKeyShare 885 + SessionID 886 + [ServerExtensions] 887 + [ResumptionCookie] 888 + [MovePrefix*, MoveToken*] 889 + [Finished] 890 CO[/prefix/random-2] 891 <-------- 892 **key exchange complete** 893 Send encrypted data <--------> Send encrypted data 895 * Indicates optional or situation-dependent 896 messages that are not always sent. 898 {} Indicates messages protected using keys 899 derived from the short-term secret (SS). 901 () Indicates messages protected using keys 902 derived from the ephemeral secret (ES). 904 [] Indicates messages protected using keys 905 derived from the traffic secret (TS). 907 Figure 4: Exchange with 1 RTT. 909 9. Secret Derivation 911 In this section we describe how secrets used in the protocol are 912 derived. We cover the SourceCookie, MoveToken, SessionID, 913 ResumptionCookie, and the actual traffic keys. 915 9.1. SourceCookie Derivation 917 The intention of the SourceCookie is to prove that a client is 918 sending interests from a legitimate location before any server 919 computation is done. Without this, a Denial of Service attack could 920 be carried out by sending interests to the server with the intention 921 of triggering wasted computation. TCP-based protocols prevent this 922 with the SYN-flood cookie mechanism. Protocols based on UDP use 923 cookies that bind to the client address [DTLS12]. Since CCN lacks 924 any notion of a source address, these cookie mechanisms do not apply. 925 Instead, we need a way for clients to prove that they initiated a key 926 exchange from the "same origin." We now describe the cookie 927 mechanism that gives us this guarantee. 929 Instead of a source address, a SourceCookie is computed using a 930 challenge provided by a consumer. To create this challenge, a 931 consumer first generates a a randomly generated 256-bit string X. 932 The consumer then computes SourceChallenge = SHA256(X). Upon receipt 933 of this challenge, the producer generates a SourceCookie as follows: 935 SourceCookie = HMAC(k, SourceChallenge || timestamp) 937 where timestamp is the current server timestamp and k is the server's 938 secret key. To prove ownership of the "source," the consumer then 939 provides the SourceCookie and a SourceProof in the round 2 Interest. 940 The SourceProof is set to the value X used to derive the 941 SourceChallenge. Upon receipt of the SourceProof, the server 942 verifies the following equality: 944 SourceCookie = HMAC(k, SHA256(SourceProof) || timestamp) 946 If this check passes, then the server continues with the 947 computationally expensive part of the key exchange protocol. 949 To avoid replays of the SourceProof and SourceCookie, a producer 950 SHOULD keep a sliding window of previously received tuples. 952 9.2. Move Derivation 954 The MoveChallenge and MoveProof are computed identically to the 955 SourceChallenge and SourceProof. The MoveToken, however, is left as 956 an opaque bit string. Extensions may be specified to describe how to 957 compute this value. 959 9.3. SessionID and ResumptionCookie Properties, Derivation, and Usage 961 The purpose of the session identifier SessionID is to uniquely 962 identify a single session for the producer and consumer. A Producer 963 MAY use a random bit string or MAY use the method described in this 964 section or MAY use another proprietary method to distinguish clients. 966 We provide a more secure creation of the SessionID since it is used 967 with the ResumptionCookie derivation (defined later). Specifically, 968 the SessionID is derived as the encryption of the hash digest of a 969 server secret, TS, and an optional prefix (e.g., MovePrefix). 971 Encryption is done by the using a long-term secret key owned by the 972 server used for only this purpose, i.e., it is not used for consumer 973 traffic encryption. Mechanically, this derivation is: 975 SessionID = Enc(k1, H(TS || (Prefix3))), 977 where k1 is the long-term producer key. 979 For the resumption cookie, we require that it must be able to be used 980 to recover the TS for a given session. Without TS, correct session 981 communication is not possible. We derive it as the encryption of the 982 hash digest of the server secret, TS, and the optional (MovePrefix, 983 MoveToken) tuple (if created for the session). The producer must use 984 a long-term secret key for this encryption. Mechanically, this 985 derivation is: 987 ResumptionCookie = Enc(k2, TS || ( (Prefix3 || MoveToken) )), 989 where k2 is again a long-term producer key. Note that it may be the 990 case that k1 = k2 (see above), though this is not required. 992 With this SessionID and ResumptionCookie, the consumer then resumes a 993 session by providing both the SessionID and ResumptionCookie to the 994 producer. This is done to prove to the producer that the consumer 995 who knows the SessionID is also in possession of the correct 996 ResumptionCookie. The producer verifies this by computing 998 (TS || ( (Prefix3 || MoveToken) )) = Dec(k2, ResumptionCookie) 1000 and checking the following equality 1002 SessionID = Enc(k1, H(TS || (Prefix3))) 1003 If equality holds, the producer uses the TS recovered from 1004 ResumptionCookie to re-initialize the previous session with the 1005 consumer. 1007 9.4. Key Derivation 1009 CCNxKE adopts the key schedule and derivation techniques defined in 1010 TLS 1.3 [TLS13]. Specifically, it uses the SS and ES to establish a 1011 common master secret (MS) and, from that, the traffic secret (TS). 1012 These dependencies are shown below. 1014 +------+ +------+ 1015 | KE-1 | | KE-2 | 1016 +------+ +----+-+ 1017 | | 1018 | | 1019 | | 1020 +---v--+ +----v-+ 1021 | SS +---+ +--+ ES | 1022 +------+ | | +------+ 1023 | | 1024 | | 1025 +-v----v-| 1026 | MK | 1027 +---+----+ 1028 | 1029 | 1030 | 1031 +-v--+ 1032 | TS | 1033 +----+ 1035 In this figure, KE-1 and KE-2 are two "sources" of keying material. 1036 The following table shows what these two sources are in different key 1037 exchange scenarios. 1039 +-------------+------------------------------+----------------------+ 1040 | Key | KE-1 | KE-2 | 1041 | Exchange | | | 1042 +-------------+------------------------------+----------------------+ 1043 | Full | ClientKeyShare and | ClientKeyShare and | 1044 | handshake | ServerKeyShare DH | ServerKeyShare DH | 1045 | | | | 1046 | Handshake | ClientKeyShare and | ClientKeyShare and | 1047 | with 1-RTT | ServerConfiguration public | ServerKeyShare DH | 1048 | | share DH | | 1049 | | | | 1050 | PSK | Pre-shared key | Pre-shared key | 1051 +-------------+------------------------------+----------------------+ 1053 Given the values for SS and ES, the remaining derivation steps are 1054 below as defined in [TLS13]. They are repeated here for posterity. 1056 1. xSS = HKDF-Extract(0, SS). Note that HKDF-Extract always 1057 produces a value the same length as the underlying hash function. 1059 2. xES = HKDF-Extract(0, ES) 1061 3. mSS = HKDF-Expand-Label(xSS, "expanded static secret", 1062 handshake_hash, L) 1064 4. mES = HKDF-Expand-Label(xES, "expanded ephemeral secret", 1065 handshake_hash, L) 1067 5. master_secret = HKDF-Extract(mSS, mES) 1069 6. traffic_secret_0 = HKDF-Expand-Label(master_secret, "traffic 1070 secret", handshake_hash, L) 1072 In all computations, the value "handshake_hash" is defined as the 1073 SHA256 hash digest of all CCNxKE messages contained up to the point 1074 of derivation. More details are given in Section 7.3.1 of [TLS13]. 1076 Updating the traffic secret using the re-key message (defined later) 1077 increments traffic_secret_N to traffic_secret_(N+1). This update 1078 procedure works as follows: 1080 traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, "traffic 1081 secret", "", L) 1083 9.5. Secret Generation and Lifecycle 1085 The secrets (keys and IVs) used to encrypt and authenticate traffic 1086 are derived from the traffic secret. The explicit derivation 1087 formula, as is defined in [TLS13], is as follows: 1089 secret = HKDF-Expand-Label(Secret, phase + ", " + purpose, 1090 handshake_context, key_length) 1092 In this context, secret can be a key or IV. This formula is used 1093 when deriving keys based on a non-forward-secure SS and the forward- 1094 secure TS. The following table enumerates the values for "phase", 1095 and "handshake_context" to be used when defining keys for different 1096 purposes. 1098 +-------------+--------+------------------+-------------------------+ 1099 | Record Type | Secret | Phase | Handshake Context | 1100 +-------------+--------+------------------+-------------------------+ 1101 | 1-RTT | xSS | "early handshake | HELLO + | 1102 | Handshake | | key expansion" | ServerConfiguration + | 1103 | | | | Server Certificate | 1104 | | | | | 1105 | 1-RTT Data | xSS | "early | HELLO + | 1106 | | | application data | ServerConfiguration + | 1107 | | | key expansion" | Server Certificate | 1108 | | | | | 1109 | Application | TS | "application | HELLO ... Finished | 1110 | Data | | data key | | 1111 | | | expansion" | | 1112 +-------------+--------+------------------+-------------------------+ 1114 Moreover, the following table indicates the values of "purpose" used 1115 in the generation of each secret. 1117 +------------------+--------------------+ 1118 | Secret | Purpose | 1119 +------------------+--------------------+ 1120 | Client Write Key | "client write key" | 1121 | | | 1122 | Server Write Key | "server write key" | 1123 | | | 1124 | Client Write IV | "client write IV" | 1125 | | | 1126 | Server Write IV | "server write IV" | 1127 +------------------+--------------------+ 1129 (( TODO: should we add examples for each of the above variants? )) 1131 10. Re-Key Message 1133 Either the client and server can trigger a key update by sending an 1134 Interest or Content Object with a KEPayload field containing the flag 1135 KeyUpdate. The KEPayload will be encrypted by the traffic key. Upon 1136 receipt, the recipient MUST update the traffic secret as defined 1137 above and re-compute the traffic encryption and authentication keys. 1138 The previous traffic key must be securely discarded. 1140 11. Application Data Protocol 1142 Once traffic keys and the associated IVs are derived from the CCNxKE 1143 protocol, all subsequent Interest and Content Object messages are 1144 encrypted. Packet encryption uses the TLV encapsulation mechanism 1145 specified in [ESIC]. For Interest encryption, the Salt in [ESIC] is 1146 set to the packet sequence number. The same substitution is done for 1147 Content Object encryption. Similarly, the KeyId field is substituted 1148 with the SessionID derived by the CCNxKE protocol. Packet sequence 1149 numbers are 64-bit numbers initialized to 0 when after the traffic 1150 secret is calculated. Each message increments and uses the sequence 1151 number when sending a new datagram (Interest). The sequence number 1152 for an Interest matches that of the Content Object response. 1154 12. Security Considerations 1156 For CCNxKE to be able to provide a secure connection, both the 1157 consumer and producer systems, keys, and applications must be secure. 1158 In addition, the implementation must be free of security errors. 1160 The system is only as strong as the weakest key exchange and 1161 authentication algorithm supported, and only trustworthy 1162 cryptographic functions should be used. Short public keys and 1163 anonymous servers should be used with great caution. Implementations 1164 and users must be careful when deciding which certificates and 1165 certificate authorities are acceptable; a dishonest certificate 1166 authority can do tremendous damage. 1168 13. References 1170 13.1. Normative References 1172 [CCNxMessages] 1173 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1174 Format", January 2016, . 1177 [DH] Diffie, W. and M. Hellman, "New Directions in 1178 Cryptography", IEEE Transactions on Information Theory, 1179 V.IT-22 n.6 , June 1977. 1181 [DTLS12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1182 Security Version 1.2", January 2012, 1183 . 1185 [ECDSA] American National Standards Institute, "Public Key 1186 Cryptography for the Financial Services Industry: The 1187 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1188 ANSI ANS X9.62-2005, November 2005. 1190 [ESIC] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx 1191 (ESIC)", n.d., . 1194 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 1195 Operation: Galois/Counter Mode (GCM) and GMAC", 1196 NIST Special Publication 800-38D, November 2007. 1198 [QUIC] Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and 1199 Reliable Transport for HTTP/2", December 2015. 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, 1203 DOI 10.17487/RFC2119, March 1997, 1204 . 1206 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1207 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1208 . 1210 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1211 "Randomness Requirements for Security", BCP 106, RFC 4086, 1212 DOI 10.17487/RFC4086, June 2005, 1213 . 1215 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1216 DOI 10.17487/RFC4302, December 2005, 1217 . 1219 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1220 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1221 . 1223 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1224 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1225 . 1227 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1228 Key Derivation Function (HKDF)", RFC 5869, 1229 DOI 10.17487/RFC5869, May 2010, 1230 . 1232 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1233 Extensions: Extension Definitions", RFC 6066, 1234 DOI 10.17487/RFC6066, January 2011, 1235 . 1237 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1238 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1239 January 2012, . 1241 [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm 1242 without Bit Shifting", RFC 6479, DOI 10.17487/RFC6479, 1243 January 2012, . 1245 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1246 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1247 . 1249 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 1250 Obtaining Digital Signatures and Public-Key 1251 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 1252 120-126., February 1978. 1254 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1255 Version 1.3", December 2015, . 1258 13.2. Informative References 1260 [HASHCHAIN] 1261 L. Lamport, "Password Authentication with Insecure 1262 Communication", ANSI Communications of the ACM 24.11, pp 1263 770-772, November 1981. 1265 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1266 "Transport Layer Security (TLS) Session Resumption without 1267 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1268 January 2008, . 1270 Authors' Addresses 1272 M. Mosko 1273 PARC 1275 EMail: marc.mosko@parc.com 1277 Ersin Uzun 1278 PARC 1280 EMail: ersin.uzun@parc.com 1282 Christopher A. Wood 1283 University of California Irvine 1285 EMail: woodc1@uci.edu