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