idnits 2.17.00 (12 Aug 2021) /tmp/idnits39915/draft-wood-icnrg-esic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 23 characters in excess of 72. ** The abstract seems to contain references ([CCNxKE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2017) is 1705 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5288' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 587, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG Working Group M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Informational C. Wood 5 Expires: March 16, 2018 University of California Irvine 6 September 12, 2017 8 Encrypted Sessions In CCNx (ESIC) 9 draft-wood-icnrg-esic-01 11 Abstract 13 This document describes how to transport CCNx packets inside an 14 encrypted session between peers that share a traffic secret, such as 15 that which is derived from [CCNxKE]. The peers create an outer 16 naming context to identify the encryption session in one direction 17 between the consumer and the producer. The consumer sends encrypted 18 Interest messages to the producer, who responds with encrypted 19 Content Objects. Inside the outer context, the consumer sends 20 Interests with different names, which the producer may respond to or 21 may send InterestReturns for. There does not need to be a naming 22 relationship between the outer names and the inner names. The inner 23 content is still protected by normal CCNx authentication mechanisms 24 and possiby encrypted under other schemes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 16, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 62 2. Stateless packet keys . . . . . . . . . . . . . . . . . . . . 4 63 3. Inner and Outer Contexts . . . . . . . . . . . . . . . . . . 4 64 3.1. Outer Context Names . . . . . . . . . . . . . . . . . . . 5 65 3.2. Outer Packet . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.1. Consumer Outer Packet . . . . . . . . . . . . . . . . 6 67 3.2.2. Producer Outer Packet . . . . . . . . . . . . . . . . 6 68 3.3. Processing Chain . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Transport State Machine . . . . . . . . . . . . . . . . . 7 70 4. Control Channel . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. ESIC Control Packets . . . . . . . . . . . . . . . . . . 9 72 4.2. ESIC Control Messages . . . . . . . . . . . . . . . . . . 11 73 5. The ESIC API . . . . . . . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 7.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13 79 A.1. Sample Encryption TLVs . . . . . . . . . . . . . . . . . 13 80 A.2. Interest Encapsulation Examples . . . . . . . . . . . . . 13 81 A.3. Content Object Encapsulation Examples . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 CCNx packets [MESSAGES] contain a fixed header, optional hop-by-hop 87 headers, a CCNx Message, and a validation section. Encrypted 88 Sessions in CCNx (ESIC) describes how to to transport encrypted CCNx 89 packets inside other CCNx packets. The outer packet (the wrapper) 90 uses a CCNx name that identifies the encrypted session while the 91 inner (encrypted) portion remains hidden and private to an outside 92 observer. 94 ESIC defines a new field Encapsulated (T_ENCAP) that may occur in 95 both an Interest (T_INTEREST) and Content Object (T_OBJECT). The 96 T_ENCAP field contains the encryption of the inner CCNx Packet. 98 Because the use of an outer CCNxPacket, the total packet length of 99 the inner CCNxPacket may need to be limited to less than the maximum 100 of 64 KB. ESIC allows the use of a compressor before the encryptor, 101 so it is likely that a packet that would overflow the 64 KB limit 102 could be compressed by enough to allow for an outer CCNxPacket. This 103 consideration for the PacketLength is separate from concerns about 104 path MTU. 106 It is a requirement of ESIC that one inner packet fit in one outer 107 packet. This is because ESIC does not define a method to issue extra 108 outer interests to fetch extra outer content objects. It relies 109 entirely on Interests generated by the consumer application. 111 ESIC defines a control channel within the outer context by using 112 special names with the inner packets. These names allow signaling 113 between the two encryption endpoints for features such as alerts and 114 rekeying requests. 116 ESIC defines how to use a traffic secret (TS), such as derived from 117 CCNxKE, to encrypt multiple packets in a consumer-producer session. 118 Each direction will use separate derived keys. If one wishes to have 119 a reverse traffic flow (interests from producer fetching content 120 objects from the consumer), then one must share a second TS and use 121 it with the roles reversed, but otherwise it works exactly as in the 122 first case. 124 The mechanism by which this symmetric key is obtained is outside the 125 scope of this document; These keys could be pre-shared or derived 126 from an online key-exchange protocol [CCNxKE]. 128 1.1. Conventions and Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in RFC 133 2119 [RFC2119]. 135 The following terms are used: 137 o Inner Packet: A fully-formed CCNx packet (fixed header through 138 validation) that is carried encrypted inside a T_ENCAP TLV. 140 o Outer Packet: A fully-formed CCNx packet that carries the outer 141 context of an encrypted session. 143 o Outer Name: The name of the outer packet. 145 o Inner Name: The name of the inner packet (not visible in 146 transport). 148 o Control channel: the use of Inner Packets to convey control 149 signaling between encryption endpoints using a special Inner Name. 151 2. Stateless packet keys 153 ESIC assumes that the consumer and producer share a Traffic Secret 154 (TS), usually derived as per CCNxKE. Regardless of how the TS is 155 derived (TODO: it needs to meet some so-far unstated requirements), 156 there are four secrets derived from the TS, as per CCNxKE 157 Section 9.5. This specifies how to generate the Client Write Key, 158 Server Write Key, Client Write IV, and Server Write IV. 160 The AEAD nonce (IV) is derived as specified in [TLS13]. In 161 particular, the length of the IV for each AEAD operation is set to 162 max(8 bytes, N_MAX), where N_MIN must be at least 8 bytes [RFC5116]. 163 With this length, the nonce is initialized by: 165 1. Padding the 64-bit per-packet AEAD sequence number to the left 166 with zeroes so that its length is equal to the IV length. 168 2. This padded sequence number is then XORed with the consumer or 169 producer IV, depending on the role. 171 TODO: Should we allow CCNxKE to specify the starting chunk number so 172 it does not always start at 0? It would need to be encoded in the 173 MoveToken. 175 3. Inner and Outer Contexts 177 The inner context is a CCNx packet with meaning to the consumer and 178 producer. They may be clear text or they make use additional 179 encryption, such as group keying, broadcast encryption, homomorphic 180 encryption, or something else. The consumer sends an Interest packet 181 with an Inner Name (plus other optional fields as normal) and 182 expectes to get back a Content Object or InterestReturn packet with 183 corresponding name and fields. 185 The outer context names the encryption session and sequences packets. 186 ESIC does not expect a one-to-one correspondence of outer name and 187 inner name. If a consumer, for example, sends 3 interests with outer 188 names NO1, NO2, NO3 and inner names NI1, NI2, and NI3, the producer 189 can return those names in any order. It could put content objects 190 with name NI3 in NO1, NI1 in NO2, and NI2 in NO3. ESIC does expect 191 normal CCNx processing rules to be followed for the inner packets, 192 therefore we would expect at most one inner packet returned for each 193 inner Interest. That inner packet could be either a Content Object 194 or Interest Return. 196 3.1. Outer Context Names 198 The outer context name is a routable prefix PREFIX followed by a 199 session ID (SID) followed by a ChunkNumber (Chunk). The chunk number 200 is a monotonically increasing number. The outer name is clear text, 201 visible to all observers. 203 The PREFIX and SID are derived outside of ESIC. In normal use with 204 CCNxKE, the PREFIX is either the same prefix as used in the key 205 exchagne or it is derived from within CCNxKE from Prefix2 or the 206 MoveToken. The SID is created by the producer and given to the 207 consumer inside CCNxKE. 209 OuterName := ccnx:/PREFIX/SID=sid/CHUNK=chunk 211 Chunk numbers are limited to 8 bytes and do not wrap around. When 212 the consumer gets near the end of the sequence number space, it must 213 request a re-keying via the control channel. Because CCNx in a pull- 214 driven model, the consumer is reponsible for the chunk number and 215 thus responsible for requesting the re-keying. The producer may also 216 request a re-keying for its own reasons. 218 3.2. Outer Packet 220 The outer packet will have a Fixed Header, per hop headers, a CCNx 221 Message with the Outer Name, and a Validation section (ValidationAlg 222 and ValidationPayload). The outer packet is visible to 3rd parties 223 in its entirety. Only the 'value' of T_ENCAP TLV field inside the 224 CCNx Message is encrypted. The T_ENCAP TLV Value is the AEAD 225 'plaintext' that will be converted to the 'ciphertext'. In the outer 226 packet, only the CCNx Message and the ValidationAlg are covered by 227 the authentication token 229 The Outer Packet has a Validation section. The ValidationAlg will 230 have a 0-length ValidationType of T_SESSION, which indidates that the 231 encryption context must be derived from the SID in the name. 233 The Associated Data (in AEAD) covered by the validation output is 234 from the beignning of the CCNx Message up to but not including the 235 T_ENCAP Value concatendated with the ValidationAlg TLV. That is, it 236 skips the T_ENCAP TLV Value. 238 The ValidationPayload contains the AEAD authentication token. 240 If the Producer cannot satisfy an Inner Packet Interest, it will 241 encapsualte an InterestReturn inside an OuterPacket of PacketType 242 ContentObject. That is, the InterestReturn is end-to-end signaling 243 about the inner context. 245 If the Producer has an error with the Outer Context, it may return an 246 InterestReturn for the outer context as normal for Interest 247 processing. 249 3.2.1. Consumer Outer Packet 251 The outer packet from the consumer to the producer will always be of 252 PacketType Interest. They may have any of the normal Interest per- 253 hop headers (e.g. InterestLifetime), which will be visible to 3rd 254 parties and not protected by the encryption or authentication. 256 The Outer Context has a T_INTEREST message type, which contains a 257 T_NAME of the Outer Name. It may have other additional metadata in 258 clear text. The T_INTEREST container is protected by the encryption 259 authenticator. Finally, the T_INTEREST has a T_ENCAP field that 260 contains the encryption of the Inner Packet. The encryption will use 261 the algorithm negotiated as part of the SID (i.e. AES-GCM). 263 3.2.2. Producer Outer Packet 265 The producer will only send PacketType ContentObject back to the 266 consumer. The Inner packet may be either an InterestReturn or a 267 ContentObject corresponding to the Inner Packet interest. 269 The outer packet may have per-hop headers (e.g. 270 RecommendedCacheTime) that affect the encrypted packet. These are 271 independent from the inner Per Hop headers. The outer MessageType is 272 always T_OBJECT. It may have normal metadata for a content object, 273 such as ExpiryTime, which affect only the outer packet. Finally, it 274 has a T_ENCAP that contains the wrapped inner Packet. 276 3.3. Processing Chain 278 The processing chain from the Source to the Sink is shown below. The 279 compression/decompression stages are optional and are not strongly 280 tied to the encrypted session. If used, we assume the compression 281 protocol is session specific to avoid state snooping (e.g. such as in 282 CRIME attack). 284 () indicates output of stage 285 +------------+ +-------------+ +-----------------+ +---------+ 286 | Source | - | Compresser | - | Encypter/Framer | - | Channel | 287 |(CCNxPacket)| |(CCNxzPacket)| | (CCNxPacket) | | | 288 +------------+ +-------------+ +-----------------+ +---------+ 290 +------------+ +--------------------+ +-------------+ +------+ 291 | Channel | - | Deframer/Decrypter | - | Decompressor| - | Sink | 292 |(CCNxPacket)| | (CCNxzPacket) | | (CCNxPacket)| | | 293 +------------+ +--------------------+ +-------------+ +------+ 295 o Source: The source of an Inner Packet. 297 o Compressor: Optional component to reduce the size before 298 encryption. 300 o Encrypter/Framer: Creates the ciphertext of the CCNx(z)packet to 301 produce the T_ENCAP, constructs the outer packet, computes the 302 authentication token and generates the ValidationPayload. 304 o Channel: Carries the wireformat outer packet 306 o Deframer/Decrypter: Verifies the authenticator, decrypts the 307 T_ENCAP, and passes the Inner Packet to the Decompressor. 309 o Decompressor: Optional component to expand the inner packet 311 o Sink: The sink of an Inner Packet. 313 The Encrypter/Framer will generate outer names with sequential outer 314 name chunk numbers. 316 The Deframer/Decryptor will extract the SID and chunk number from the 317 outer name and use those to create the packet key (see below). Using 318 the packet key, it will verify the authentication token and if 319 successful decrypt the T_ENCAP. The output of the T_ENCAP will then 320 be passed to the Sink. 322 3.4. Transport State Machine 324 ESIC uses a state machine to manage the ephemeral session such that 325 the Producer knows when the Consumer is finished with the SID. It 326 also will try to re-request packets that fail authentication before 327 sending its own InterestReturn up the Sink. 329 The protocol begins with each side knowing the four keys (see 330 Stateless Packet Keys below), the Session ID (SID), and the routable 331 prefix PREFIX. 333 The receiving process uses a replay buffer to prevent replay attacks. 334 The buffer tracks the last N out-of-order verified chunks plus the 335 cumulative verified chunk number. TODO: Sort this out how to avoid 336 replay attacks without requiring reliable in-order delivery. 338 Protocol of Encrypter/Framer: 340 o Initialize: set NextChunkNumber = 0, State = Waiting 342 o Waiting: Wait for packet from Source (or compressor). On packet 343 receive, State = Send 345 o Send: 347 * Generate packet key for NextChunkNumber 349 * Create outer packet with name /PREFIX/SID=sid/ 350 CHUNK=NextChunkNumber and the input packet as cleartext in the 351 T_ENCAP. 353 * Run the AEAD scheme authenticating and encrypting. Note the 354 prior description of the split Associated Data before and after 355 the plaintext. 357 * Increment NextChunkNumber 359 * Send the packet 361 * State = Waiting 363 Protocol of the Deframer/Decrypter: 365 o Initialize the replay buffer to empty, State = Waiting. 367 o Waiting: wait for packet, on input from channel State = Receive 369 o Receive: 371 * Extract the SID and ChunkNumber from name 373 * If replay, drop 375 * Authenticate the packet 377 + If failed on consumer, send InterestReturn to Source with "X 378 Error" (TBD) 380 + If failed on producer, send failure message to Sink so it 381 can send end-to-end InterestReturn back over channel (if 382 desired) with "Y Error" (TBD) 384 * Add packet to replay buffer 386 * Decrypt packet 388 * Pass decrypted packet to Sink/Source (or decompressor) 390 4. Control Channel 392 The consumer and producer will need to exchange signaling about the 393 encryption context. Control and data traffic should be 394 indistinguishable to an external observer. Therefore, all control 395 signaling is done within the same outer names as data traffic. 397 Control signaling is done with a normal Inner Packet that pushes data 398 to the other side. We use an Interest with an Inner Name of the form 399 shown below, where '_direction_' is 'up' from the consumer to 400 producer or 'down' for the producer to consumer. This allows each 401 side to maintain its own sequence number space in the 'seqnum'. This 402 is similar to the use of the sequence number in the DTLS record 403 layer. 405 Like DTLS, ESIC control messages are unreliable, though they are 406 uniquely named. 408 The payload of the control Interest uses a TLV equivalent of the TLS 409 record format for handshake and alert messages. Application data is 410 never communicated in these records, as they use an Inner Packet with 411 a different Inner Name. Inside the payload, a TLV type of Alert (21) 412 or Handshake (22) indicates the purpose of the TLV value. One may 413 concatenate multiple records in to one payload. 415 ControlName := ccnx:/localhost/esic/_direction_/SID=sid/SEQNUM=seqnum 417 4.1. ESIC Control Packets 419 A control packet is a CCNx Interest Inner Packet. The name of the 420 control packet is as above in the /localhost/esic namesapce. The 421 Payload of the Interest is the actual data. 423 The ESIC control packet SHOULD be padded out to a length that is 424 indistinguishable from other traffic in the given _direction_. 426 The Payload of the Interest contains a set of TLV records using the 427 normal CCNx TLV encoding. The TLV types and values are defined in 428 the next section. 430 In the 'up' direction from the consumer to the producer, a control 431 packet can be inserted into the Interest stream as normal. The 432 producer may use this extra outer name to return its own control 433 message or send a "no-op" back to consume the extra name. 435 In the 'down' direction from the producer to the consumer, there is 436 no pre-allocated outer name available. The producer can only send 437 the consumer a control message if the consumer has outstanding 438 Interests up to the producer. If there is one or more oustanding 439 interests in the outer name space, the producer normally would send a 440 Content Object or Interest Return corresponding to some inner name. 441 In this case, the producer would instead inject a control packet 442 Interest in the downstream. This means the producer is now short one 443 outer Interest in the upstream direction. Therefore, whenever the 444 Deframer/Decrypter sees a control message in the downstream 445 direction, it MUST insert an upstream "no-op" packet, padded out to 446 statistically undetectable length, to give the producer back a 447 missing name slot. 449 We allow one ESIC control packet in one outer packet. However, we 450 allow multiple Alert messages to be encoded in the payload, so long 451 as it remains indistinguishable from other packets in the given 452 _direction_. 454 Example from a consumer to a producer, where "NO" means "name outer" 455 and "NI" means "name inner". 457 Consumer Producer 458 | >------- NO1 : NI1 (Interest) --------> | 459 | >------- NO2 : NI2 (Interest) --------> | 460 | <------- NO1 : NI1 (ContentObject) ---< | 461 | >------- NO3 : NI /local/esic/up/2/1 -> | 462 | <------- NO3 : no-op -----------------< | (no-op) 463 | <------- NO2 : NI2 (ContentObject) ---< | 465 Here is an example from a producer to a consumer. The producer uses 466 the second avaialble name NO2 to send a control message to the 467 consumer. The consumer must then send a no-op packet back up to the 468 producer so it can return the final data packet NI2 inside NO3. 470 Consumer Producer 471 | >------- NO1 : NI1 (Interest) --------> | 472 | >------- NO2 : NI2 (Interest) --------> | 473 | <------- NO1 : NI1 (ContentObject) ---< | 474 | <------- NO2 : NI /local/esic/dn/2/1 -< | 475 | >------- NO3 : -----------------------> | (no-op) 476 | <------- NO3 : NI2 (ContentObject) ---< | 478 TODO: Add examples with loss 480 4.2. ESIC Control Messages 482 ESIC adopts the TLS 1.3 Alert Protocol for its control messages. The 483 TLV type of the message inside the control packet payload is taken 484 from the enum AlertDescription. As per TLS 1.3, fatal Alert messages 485 are an immediate close of the ESIC session. 487 As per TLS 1.3, each party MUST send a close_nofity message closing 488 the write side of the connection. In ESIC, this means that when a 489 consumer is done requesting data, it should send a final 490 close_notify. The producer should then use this outer name to send 491 back its own close_notify. If for some reason the producer must 492 close before the consumer, it should inject its own close_notify 493 discarding all remaining data and the consumer should send back 494 upstream a close_notify. 496 The KeyUpdate messages function as per TLS 1.3 Sec 6.3.5.3. Either 497 side may generate a KeyUpdate message and begin transmitting with the 498 new key. The other side must update their own key and issue its own 499 KeyUpdate message. 501 5. The ESIC API 503 In this section we describe the ESIC API. Before doing so, we 504 highlight some details that molded the API for both consumers and 505 consumers. 507 o Encrypted sessions are bound to names instead of addresses. 508 Consequently, in addition to a set of trusted keys, sessions 509 between a consumer and producer require only a name to be created. 511 o Sessions are created by an active consumer with a passive peer 512 (producer). Thus, the API must reflect these roles. 514 o Consumers send and receive whole CCNx messages over a session. 515 Thus, simple read and write functions must be exposed via the API. 517 o Sessions are not full duplex by default. A producer must specify 518 in its ServerConfiguration construct that it wishes to send 519 interests to the consumer. To maintain transparency, the modality 520 of the resulting session is not reflected in the API. 522 These observations are distilled in the following ESIC API. 524 # @Consumer: create a secure session with a producer 525 CCNxSecureSession *ccnxSecureSession_Connect(CCNxPortal *portal, 526 PARCIdentity *identity, CCNxName *servicePrefix); 528 # @Producer: create a passive listener 529 CCNxSecureSession *ccnxSecureSession_CreateServer(CCNxPortal *portal, 530 CCNxKeyExchangeConfig *config, CCNxName *servicePrefix); 532 # @Producer: accept uni- and bi-directional sessions 533 CCNxSecureSession *ccnxSecureSession_AcceptConnection(CCNxSecureSession *session); 534 CCNxSecureSession *ccnxSecureSession_AcceptBidirectionalConnection(CCNxSecureSession *session); 536 # Send a CCNx message 537 # Override the outer name with the `response` parameter if needed 538 void ccnxSecureSession_SendMessage(CCNxSecureSession *session, 539 CCNxTlvDictionary *message, const CCNxStackTimeout *timeout, CCNxName *response); 541 # Receive and decapsulate a CCNx message 542 # Store the outer name in the `response` parameter. 543 CCNxMetaMessage *ccnxSecureSession_ReceiveMessage(CCNxSecureSession *session, 544 const CCNxStackTimeout *timeout, CCNxName **response); 546 6. Security Considerations 548 It may be possible for an observer to identify which outer packets 549 contain a control (alert) message if the ACK response time shows 550 significant statistical timing different from the normal flow of 551 messages. 553 TODO. 555 7. References 557 7.1. Normative References 559 [CCNxKE] "CCNx Key Exchange Protocol Version 1.0", n.d., 560 . 562 [MESSAGES] 563 "CCNx Messages in TLV Format", n.d., 564 . 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, . 572 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 573 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 574 . 576 [TLS13] RTFM, Inc, ., "The Transport Layer Security (TLS) Protocol 577 Version 1.3", n.d., . 580 7.2. Informative References 582 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 583 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 584 DOI 10.17487/RFC5288, August 2008, . 587 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 588 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 589 DOI 10.17487/RFC5389, October 2008, . 592 Appendix A. Test Vectors 594 A.1. Sample Encryption TLVs 596 TODO 598 A.2. Interest Encapsulation Examples 600 TODO 602 A.3. Content Object Encapsulation Examples 604 TODO 606 Authors' Addresses 608 Marc Mosko 609 PARC, Inc. 611 Email: marc.mosko@parc.com 613 Christopher A. Wood 614 University of California Irvine 616 Email: woodc1@uci.edu