idnits 2.17.1 draft-wood-icnrg-esic-00.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 (March 13, 2017) is 2594 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: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5288' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 531, 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: Experimental C. Wood 5 Expires: September 14, 2017 University of California Irvine 6 March 13, 2017 8 Encrypted Sessions In CCNx (ESIC) 9 draft-wood-icnrg-esic-00 11 Abstract 13 This document describes how to transport CCNx packets inside an 14 encrypted session between peers - a sender and receiver - that share 15 a traffic secret, such as that which is derived from [CCNxKE]. The 16 peers create an outer naming context to identify the encryption 17 session in one direction between the sender and the receiver. The 18 sender issues encrypted Interest messages to the receiver, who 19 responds with encrypted Content Objects. Inside the outer context, 20 the sender sends Interests with different names, for which the 21 receiver may reply to or send InterestReturns in response. There 22 does not need to be a naming relationship between the outer names and 23 the inner names. The inner content is still protected by normal CCNx 24 authentication mechanisms and possibly 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 September 14, 2017. 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. Sender Outer Packet . . . . . . . . . . . . . . . . . 6 67 3.2.2. Receiver 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. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 6.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Appendix A. Sample API . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 CCNx packets [CCNxMessages] contain a fixed header, optional hop-by- 83 hop headers, a CCNx Message, and a validation section. Encrypted 84 Sessions in CCNx (ESIC) describes how to to transport encrypted CCNx 85 packets inside other CCNx packets. The outer packet (the wrapper) 86 uses a CCNx name that identifies the encrypted session while the 87 inner (encrypted) portion remains hidden and private to an outside 88 observer. 90 ESIC defines a new field Encapsulated (T_ENCAP) that may occur in 91 both an Interest (T_INTEREST) and Content Object (T_OBJECT). The 92 T_ENCAP field contains the encryption of the inner CCNx packet, be it 93 an Interest or Content Object. 95 Because the use of an outer CCNxPacket, the total packet length of 96 the inner CCNxPacket may need to be limited to less than the maximum 97 of 64 KB. ESIC allows the use of a compressor before the encryptor, 98 so it is likely that a packet that would overflow the 64 KB limit 99 could be compressed by enough to allow for an outer CCNxPacket. This 100 consideration for the PacketLength is separate from concerns about 101 path MTU. 103 It is a requirement of ESIC that one inner packet fit in one outer 104 packet. This is because ESIC does not define a method to issue extra 105 outer interests to fetch extra outer content objects. It relies 106 entirely on Interests generated by the sender application. 108 ESIC defines a control channel within the outer context by using 109 special names with the inner packets. These names allow signaling 110 between the two encryption endpoints for features such as alerts and 111 rekeying requests. 113 ESIC defines how to use a traffic secret (TS), such as derived from 114 CCNxKE, to encrypt multiple packets in a sender-receiver session. 115 Each direction will use separate derived keys. If one wishes to have 116 a reverse traffic flow (interests from receiver fetching content 117 objects from the sender), then one must share a second TS and use it 118 with the roles reversed, but otherwise it works exactly as in the 119 first case. 121 The mechanism by which this symmetric key is obtained is outside the 122 scope of this document; These keys could be pre-shared or derived 123 from an online key-exchange protocol [CCNxKE]. 125 1.1. Conventions and Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in RFC 130 2119 [RFC2119]. 132 The following terms are used: 134 o Inner Packet: A fully-formed CCNx packet (fixed header through 135 validation) that is carried encrypted inside a T_ENCAP TLV. 137 o Outer Packet: A fully-formed CCNx packet that carries the outer 138 context of an encrypted session. 140 o Outer Name: The name of the outer packet. 142 o Inner Name: The name of the inner packet (not visible in 143 transport). 145 o Control channel: the use of Inner Packets to convey control 146 signaling between encryption endpoints using a special Inner Name. 148 2. Stateless packet keys 150 ESIC assumes that the sender and receiver share a Traffic Secret 151 (TS), usually derived as per CCNxKE. Regardless of how the TS is 152 derived, there are four secrets derived from it, as per [CCNxKE]. 153 This specifies how to generate the Sender Write Key, Receiver Write 154 Key, Sender Write IV, and Receiver Write IV. 156 The AEAD nonce (IV) is derived as specified in [TLS13]. In 157 particular, the length of the IV for each AEAD operation is set to 158 max(8 bytes, N_MAX), where N_MIN must be at least 8 bytes [RFC5116]. 159 With this length, the nonce is initialized by: 161 1. Padding the 64-bit per-packet AEAD sequence number to the left 162 with zeroes so that its length is equal to the IV length. 164 2. This padded sequence number is then XORed with the sender or 165 receiver IV, depending on the role. 167 3. Inner and Outer Contexts 169 The inner context is a CCNx packet with meaning to the sender and 170 receiver. They may be clear text or they make use additional 171 encryption as needed. The sender transmits an Interest packet with 172 an Inner Name (plus other optional fields as normal) and expects to 173 get back a Content Object or InterestReturn packet with corresponding 174 name and fields. 176 The outer context names the encryption session and sequences packets. 177 ESIC does not expect a one-to-one correspondence of outer name and 178 inner name. If a sender, for example, transmits 3 interests with 179 outer names NO1, NO2, NO3 and inner names NI1, NI2, and NI3, the 180 receiver can return those names in any order. It could put content 181 objects with name NI3 in NO1, NI1 in NO2, and NI2 in NO3. ESIC does 182 expect normal CCNx processing rules to be followed for the inner 183 packets, therefore we would expect at most one inner packet returned 184 for each inner Interest. That inner packet could be either a Content 185 Object or Interest Return. 187 3.1. Outer Context Names 189 The outer context name is a routable prefix PREFIX followed by a 190 session ID (SID) followed by a ChunkNumber (Chunk). The chunk number 191 is a monotonically increasing number. 192 The outer name is clear text, visible to all observers. 194 The PREFIX and SID are derived outside of ESIC. In normal use with 195 CCNxKE, the PREFIX is that which is set after the handshake 196 completes, be it the original producer (receiver) prefix or the 197 MovePrefix. The SID is created by the receiver and given to the 198 sender inside CCNxKE. 200 OuterName := ccnx:/PREFIX/SID=sid/CHUNK=chunk 202 Chunk numbers are limited to 8 bytes and do not wrap around. When 203 the sender gets near the end of the sequence number space, it must 204 request a re-keying via the control channel. Because CCNx in a pull- 205 driven model, the sender is responsible for the chunk number and thus 206 responsible for requesting the re-keying. The receiver may also 207 request a re-keying for its own reasons. 209 3.2. Outer Packet 211 The outer packet will have a Fixed Header, per hop headers, a CCNx 212 Message with the Outer Name, and a Validation section (ValidationAlg 213 and ValidationPayload). The outer packet is visible to 3rd parties 214 in its entirety. Only the 'value' of T_ENCAP TLV field inside the 215 CCNx Message is encrypted. The T_ENCAP TLV Value is the AEAD 216 'plaintext' that will be converted to the 'ciphertext'. In the outer 217 packet, only the CCNx Message and the ValidationAlg are covered by 218 the authentication token 220 The Outer Packet has a Validation section. The ValidationAlg will 221 have a 0-length ValidationType of T_SESSION, which indicates that the 222 encryption context must be derived from the SID in the name. 224 The Associated Data (in AEAD) covered by the validation output is 225 from the beignning of the CCNx Message up to but not including the 226 T_ENCAP Value concatenated with the ValidationAlg TLV. That is, it 227 skips the T_ENCAP TLV Value. 229 The ValidationPayload contains the AEAD authentication token. 231 If the receiver cannot satisfy an Inner Packet Interest, it will 232 encapsulate an InterestReturn inside an OuterPacket of PacketType 233 ContentObject. That is, the InterestReturn is end-to-end signaling 234 about the inner context. 236 If the receiver has an error with the Outer Context, it may return an 237 InterestReturn for the outer context as normal for Interest 238 processing. 240 3.2.1. Sender Outer Packet 242 The outer packet from the sender to the receiver will always be of 243 PacketType Interest. They may have any of the normal Interest per- 244 hop headers (e.g. InterestLifetime), which will be visible to 3rd 245 parties and not protected by the encryption or authentication. 247 The Outer Context has a T_INTEREST message type, which contains a 248 T_NAME of the Outer Name. It may have other additional metadata in 249 clear text. The T_INTEREST container is protected by the encryption 250 authenticator. Finally, the T_INTEREST has a T_ENCAP field that 251 contains the encryption of the Inner Packet. The encryption will use 252 the algorithm negotiated as part of the SID (i.e. AES-GCM). 254 3.2.2. Receiver Outer Packet 256 The receiver will only send PacketType ContentObject back to the 257 sender. The Inner packet may be either an InterestReturn or a 258 ContentObject corresponding to the Inner Packet interest. 260 The outer packet may have per-hop headers (e.g. 261 RecommendedCacheTime) that affect the encrypted packet. These are 262 independent from the inner Per Hop headers. The outer MessageType is 263 always T_OBJECT. It may have normal metadata for a content object, 264 such as ExpiryTime, which affect only the outer packet. Finally, it 265 has a T_ENCAP that contains the wrapped inner Packet. 267 3.3. Processing Chain 269 The processing chain from the Source to the Sink is shown below. The 270 compression/decompression stages are optional and are not strongly 271 tied to the encrypted session. If used, we assume the compression 272 protocol is session specific to avoid state snooping (e.g. such as in 273 CRIME attack). 275 () indicates output of stage 276 +------------+ +-------------+ +-----------------+ +---------+ 277 | Source | - | Compresser | - | Encypter/Framer | - | Channel | 278 |(CCNxPacket)| |(CCNxzPacket)| | (CCNxPacket) | | | 279 +------------+ +-------------+ +-----------------+ +---------+ 281 +------------+ +--------------------+ +-------------+ +------+ 282 | Channel | - | Deframer/Decrypter | - | Decompressor| - | Sink | 283 |(CCNxPacket)| | (CCNxzPacket) | | (CCNxPacket)| | | 284 +------------+ +--------------------+ +-------------+ +------+ 286 o Source: The source of an Inner Packet. 288 o Compressor: Optional component to reduce the size before 289 encryption. 291 o Encrypter/Framer: Creates the ciphertext of the CCNx(z)packet to 292 produce the T_ENCAP, constructs the outer packet, computes the 293 authentication token and generates the ValidationPayload. 295 o Channel: Carries the wire format outer packet 297 o Deframer/Decrypter: Verifies the authenticator, decrypts the 298 T_ENCAP, and passes the Inner Packet to the Decompressor. 300 o Decompressor: Optional component to expand the inner packet 302 o Sink: The sink of an Inner Packet. 304 The Encrypter/Framer will generate outer names with sequential outer 305 name chunk numbers. 307 The Deframer/Decryptor will extract the SID and chunk number from the 308 outer name and use those to create the packet key (see below). Using 309 the packet key, it will verify the authentication token and if 310 successful decrypt the T_ENCAP. The output of the T_ENCAP will then 311 be passed to the Sink. 313 3.4. Transport State Machine 315 ESIC uses a state machine to manage the ephemeral session such that 316 the receiver knows when the sender is finished with the SID. It also 317 will try to re-request packets that fail authentication before 318 sending its own InterestReturn up the Sink. 320 The protocol begins with each side knowing the four keys (see 321 Stateless Packet Keys below), the Session ID (SID), and the routable 322 prefix PREFIX. 324 The receiving process uses a replay buffer to prevent replay attacks. 325 The buffer tracks the last N out-of-order verified chunks plus the 326 cumulative verified chunk number. 328 ((TODO: Sort this out how to avoid replay attacks without requiring 329 reliable in-order delivery.)) 331 Protocol of Encrypter/Framer: 333 o Initialize: set NextChunkNumber = 0, State = Waiting 335 o Waiting: Wait for packet from Source (or compressor). On packet 336 receive, State = Send 338 o Send: 340 * Generate packet key for NextChunkNumber 342 * Create outer packet with name /PREFIX/SID=sid/ 343 CHUNK=NextChunkNumber and the input packet as cleartext in the 344 T_ENCAP. 346 * Run the AEAD scheme authenticating and encrypting. Note the 347 prior description of the split Associated Data before and after 348 the plaintext. 350 * Increment NextChunkNumber 352 * Send the packet 354 * State = Waiting 356 Protocol of the Deframer/Decrypter: 358 o Initialize the replay buffer to empty, State = Waiting. 360 o Waiting: wait for packet, on input from channel State = Receive 362 o Receive: 364 * Extract the SID and ChunkNumber from name 366 * If replay, drop 368 * Authenticate the packet 370 + If failed on sender, send InterestReturn to Source with "X 371 Error" (TBD) 373 + If failed on receiver, send failure message to Sink so it 374 can send end-to-end InterestReturn back over channel (if 375 desired) with "Y Error" (TBD) 377 * Add packet to replay buffer 379 * Decrypt packet 381 * Pass decrypted packet to Sink/Source (or decompressor) 383 4. Control Channel 385 The sender and receiver will need to exchange signaling about the 386 encryption context. Control and data traffic should be 387 indistinguishable to an external observer. Therefore, all control 388 signaling is done within the same outer names as data traffic. 390 Control signaling is done with a normal Inner Packet that pushes data 391 to the other side. We use an Interest with an Inner Name of the form 392 shown below, where '_direction_' is 'up' from the sender to receiver 393 or 'down' for the receiver to sender. This allows each side to 394 maintain its own sequence number space in the 'seqnum'. This is 395 similar to the use of the sequence number in the DTLS record layer. 397 Like DTLS, ESIC control messages are unreliable, though they are 398 uniquely named. 400 The payload of the control Interest uses a TLV equivalent of the TLS 401 record format for handshake and alert messages. Application data is 402 never communicated in these records, as they use an Inner Packet with 403 a different Inner Name. Inside the payload, a TLV type of Alert (21) 404 or Handshake (22) indicates the purpose of the TLV value. One may 405 concatenate multiple records into one payload. 407 ControlName := ccnx:/localhost/esic/_direction_/SID=sid/SEQNUM=seqnum 409 4.1. ESIC Control Packets 411 A control packet is a CCNx Interest Inner Packet. The name of the 412 control packet is as above in the /localhost/esic namesapce. The 413 Payload of the Interest is the actual data. 415 The ESIC control packet SHOULD be padded out to a length that is 416 indistinguishable from other traffic in the given _direction_. 418 The Payload of the Interest contains a set of TLV records using the 419 normal CCNx TLV encoding. The TLV types and values are defined in 420 the next section. 422 In the 'up' direction from the sender to the receiver, a control 423 packet can be inserted into the Interest stream as normal. The 424 receiver may use this extra outer name to return its own control 425 message or send a "no-op" back to consume the extra name. 427 In the 'down' direction from the receiver to the sender, there is no 428 pre-allocated outer name available. The receiver can only send the 429 sender a control message if the sender has outstanding Interests up 430 to the receiver. If there is one or more outstanding interests in 431 the outer name space, the receiver normally would send a Content 432 Object or Interest Return corresponding to some inner name. In this 433 case, the receiver would instead inject a control packet Interest in 434 the downstream. This means the receiver is now short one outer 435 Interest in the upstream direction. Therefore, whenever the 436 Deframer/Decrypter sees a control message in the downstream 437 direction, it MUST insert an upstream "no-op" packet, padded out to 438 statistically undetectable length, to give the receiver back a 439 missing name slot. 441 We allow one ESIC control packet in one outer packet. However, we 442 allow multiple Alert messages to be encoded in the payload, so long 443 as it remains indistinguishable from other packets in the given 444 _direction_. 446 Example from a sender to a receiver, where "NO" means "name outer" 447 and "NI" means "name inner". 449 Sender Receiver 450 | >------- NO1 : NI1 (Interest) --------> | 451 | >------- NO2 : NI2 (Interest) --------> | 452 | <------- NO1 : NI1 (ContentObject) ---< | 453 | >------- NO3 : NI /local/esic/up/2/1 -> | 454 | <------- NO3 : no-op -----------------< | (no-op) 455 | <------- NO2 : NI2 (ContentObject) ---< | 457 Here is an example from a receiver to a sender. The receiver uses 458 the second available name NO2 to send a control message to the 459 sender. The sender must then send a no-op packet back up to the 460 receiver so it can return the final data packet NI2 inside NO3. 462 Sender Receiver 463 | >------- NO1 : NI1 (Interest) --------> | 464 | >------- NO2 : NI2 (Interest) --------> | 465 | <------- NO1 : NI1 (ContentObject) ---< | 466 | <------- NO2 : NI /local/esic/dn/2/1 -< | 467 | >------- NO3 : -----------------------> | (no-op) 468 | <------- NO3 : NI2 (ContentObject) ---< | 469 ((TODO: Add examples with loss)) 471 4.2. ESIC Control Messages 473 ESIC adopts the TLS 1.3 Alert Protocol for its control messages. The 474 TLV type of the message inside the control packet payload is taken 475 from the enum AlertDescription. As per TLS 1.3, fatal Alert messages 476 are an immediate close of the ESIC session. 478 As per TLS 1.3, each party MUST send a close_notify message closing 479 the write side of the connection. In ESIC, this means that when a 480 sender is done requesting data, it should send a final close_notify. 481 The receiver should then use this outer name to send back its own 482 close_notify. If for some reason the receiver must close before the 483 sender, it should inject its own close_notify discarding all 484 remaining data and the receiver should send back upstream a 485 close_notify. 487 The KeyUpdate messages function as per TLS 1.3 Sec 6.3.5.3. Either 488 side may generate a KeyUpdate message and begin transmitting with the 489 new key. The other side must update their own key and issue its own 490 KeyUpdate message. 492 5. Security Considerations 494 It may be possible for an observer to identify which outer packets 495 contain a control (alert) message if the ACK response time shows 496 significant statistical timing different from the normal flow of 497 messages. 499 6. References 501 6.1. Normative References 503 [CCNxKE] "CCNx Key Exchange Protocol Version 1.0", n.d., 504 . 506 [CCNxMessages] 507 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", n.d., 508 . 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 517 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 518 . 520 [TLS13] RTFM, Inc, ., "The Transport Layer Security (TLS) Protocol 521 Version 1.3", n.d., . 524 6.2. Informative References 526 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 527 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 528 DOI 10.17487/RFC5288, August 2008, 529 . 531 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 532 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 533 DOI 10.17487/RFC5389, October 2008, 534 . 536 Appendix A. Sample API 538 In this section we describe the ESIC API. Before doing so, we 539 highlight some details that molded the API for both senders and 540 receivers. 542 o Encrypted sessions are bound to names instead of addresses. 543 Consequently, in addition to a set of trusted keys, sessions 544 between a sender and receiver require only a name to be created. 546 o Sessions are created by an active sender with a passive peer 547 (receiver). Thus, the API must reflect these roles. 549 o Senders transmit and receive whole CCNx messages over a session. 550 Thus, simple read and write functions must be exposed via the API. 552 o Sessions are not full duplex by default. A receiver must specify 553 in its ServerConfiguration construct that it wishes to send 554 interests to the sender. To maintain transparency, the modality 555 of the resulting session is not reflected in the API. 557 These observations are distilled in the following ESIC API. 559 # @Sender: create a secure session with a receiver 560 CCNxSecureSession *ccnxSecureSession_Connect(CCNxPortal *portal, 561 PARCIdentity *identity, CCNxName *servicePrefix); 563 # @Receiver: create a passive listener 564 CCNxSecureSession *ccnxSecureSession_CreateServer(CCNxPortal *portal, 565 CCNxKeyExchangeConfig *config, CCNxName *servicePrefix); 567 # @Receiver: accept uni- and bi-directional sessions 568 CCNxSecureSession *ccnxSecureSession_AcceptConnection(CCNxSecureSession *session); 569 CCNxSecureSession *ccnxSecureSession_AcceptBidirectionalConnection(CCNxSecureSession *session); 571 # Send a CCNx message 572 # Override the outer name with the `response` parameter if needed 573 void ccnxSecureSession_SendMessage(CCNxSecureSession *session, 574 CCNxTlvDictionary *message, const CCNxStackTimeout *timeout, CCNxName *response); 576 # Receive and decapsulate a CCNx message 577 # Store the outer name in the `response` parameter. 578 CCNxMetaMessage *ccnxSecureSession_ReceiveMessage(CCNxSecureSession *session, 579 const CCNxStackTimeout *timeout, CCNxName **response); 581 Authors' Addresses 583 Marc Mosko 584 PARC, Inc. 586 Email: marc.mosko@parc.com 588 Christopher A. Wood 589 University of California Irvine 591 Email: woodc1@uci.edu