draft-schanzen-cake.xml (39880B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"> 4 <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"> 5 <!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml"> 6 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 7 <!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">--> 8 <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> 9 <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> 10 <!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 11 <!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 12 <!ENTITY RFC4033 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"> 13 <!ENTITY RFC5237 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5237.xml"> 14 <!--<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">--> 15 <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> 16 <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 17 <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> 18 <!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"> 19 <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> 20 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> 21 <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> 22 <!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml"> 23 <!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml"> 24 <!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml"> 25 <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 26 <!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 27 <!ENTITY RFC8244 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8244.xml"> 28 <!ENTITY RFC8324 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml"> 29 <!ENTITY RFC8439 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8439.xml"> 30 <!ENTITY RFC8446 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml"> 31 <!ENTITY RFC8499 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml"> 32 <!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml"> 33 <!ENTITY RFC9147 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9147.xml"> 34 <!ENTITY RFC9180 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9180.xml"> 35 <!ENTITY I-D.ietf-dnsop-alt-tld PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-alt-tld.xml"> 36 ]> 37 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 38 <?rfc strict="yes" ?> 39 <?rfc toc="yes" ?> 40 <?rfc symrefs="yes"?> 41 <?rfc sortrefs="yes" ?> 42 <?rfc compact="yes" ?> 43 <?rfc subcompact="no" ?> 44 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 45 category="info" 46 docName="draft-schanzen-cake-00" 47 ipr="trust200902" 48 obsoletes="" updates="" 49 submissionType="independent" 50 xml:lang="en" 51 version="3"> 52 <!-- xml2rfc v2v3 conversion 2.26.0 --> 53 <front> 54 <title abbrev="CORE Authenticated Key Exchange (CAKE)"> 55 CORE Authenticated Key Exchange (CAKE) 56 </title> 57 <seriesInfo name="Internet-Draft" value="draft-schanzen-cake-00"/> 58 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 59 <organization>Fraunhofer AISEC</organization> 60 <address> 61 <postal> 62 <street>Lichtenbergstrasse 11</street> 63 <city>Garching</city> 64 <code>85748</code> 65 <country>DE</country> 66 </postal> 67 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 68 </address> 69 </author> 70 <author fullname="ch3" initials="" surname="ch3"> 71 <organization>GNUnet e.V.</organization> 72 <address> 73 <postal> 74 <street></street> 75 <city>Lenggries</city> 76 <code></code> 77 <country>DE</country> 78 </postal> 79 <email>ch3@mailbox.org</email> 80 </address> 81 </author> 82 <!-- Meta-data Declarations --> 83 <area>General</area> 84 <workgroup>Independent Stream</workgroup> 85 <keyword>transport protocols</keyword> 86 <abstract> 87 <t> 88 This document contains the GNUnet CORE AKE (CAKE). 89 </t> 90 <t> 91 This document defines the normative wire format of the protocol, 92 cryptographic routines and security 93 considerations for use by implementers. 94 </t> 95 <t> 96 This specification was developed outside the IETF and does not have 97 IETF consensus. It is published here to inform readers about the 98 function of GNUnet communicators, guide future implementations, and ensure 99 interoperability including with the pre-existing 100 GNUnet implementation. 101 </t> 102 </abstract> 103 </front> 104 <middle> 105 <section anchor="introduction" numbered="true" toc="default"> 106 <name>Introduction</name> 107 <t> 108 This specification was developed outside the IETF and does not have 109 IETF consensus. It is published here to guide implementers of GNS 110 and to ensure interoperability among implementations. 111 </t> 112 <section numbered="true" toc="default"> 113 <name>Requirements Notation</name> 114 <t> 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 119 when, they appear in all capitals, as shown here. 120 </t> 121 </section> 122 </section> 123 <section anchor="terminology"> 124 <name>Conventions and Terminology</name> 125 <t> 126 While some of the terminology is explicitly re-defined here, the reader is expected 127 to be familiar with TLS 1.3 (<xref target="RFC8446"/>), DTLS 1.3 (<xref target="RFC9147"/>) and HPKE 128 (<xref target="RFC9180"/>). 129 </t> 130 <dl> 131 <dt>inititator:</dt><dd>See client in <xref target="RFC9147"/> Section 2.</dd> 132 <dt>responder:</dt><dd>See server in <xref target="RFC9147"/> Section 2.</dd> 133 <dt>epoch:</dt><dd>See <xref target="RFC9147"/> Section 2.</dd> 134 <dt>IATS:</dt> 135 <dd>Initiator Application Traffic Secret Key</dd> 136 <dt>RATS:</dt> <dd>Responder Application Traffic Secret Key</dd> 137 <dt>ES:</dt> <dd>Early Secret Key</dd> 138 <dt>ETS:</dt> <dd>Early Traffic Secret Key</dd> 139 <dt>HS:</dt> <dd>Handshake Secret Key</dd> 140 <dt>MS:</dt> <dd>Main Secret Key</dd> 141 <dt>ES:</dt> <dd>Early Secret Key</dd> 142 <dt>IHTS:</dt> <dd>Initiator Handshake Secret Key</dd> 143 <dt>RHTS:</dt> <dd>Responder Handshake Secret Key</dd> 144 <dt>H(D):</dt> <dd>A 512-bit hash over D. The hash function is TBD (Blake2b or SHA-512).</dd> 145 <dt>T(M):</dt> <dd>means the transcript as a concatenation of received/sent messages starting from and including the InitiatorHello pk_e until and including M. Note that the transcript refers to everything that is seen on the wire, including potentially encrypted messages or fields and metadata.</dd> 146 <dt>'{}K'</dt> <dd>indicates encryption with a handshake traffic key K and a modified <xref target="RFC8439"/>, the XChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) construction.</dd> 147 <dt>'[]K'</dt> <dd>indicates encryption with an application traffic key K using the XChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) construction.</dd> 148 </dl> 149 </section> 150 <section anchor="rationale" numbered="true" toc="default"> 151 <name>Design Rationale</name> 152 <t> 153 The design rationale for CAKE is similar to DTLS 1.3 (cf. <xref target="RFC9147" section="3"/>). 154 Except that CAKE does not consider Fragmentation as this is expected to be provided by the 155 transport underlay layer of GNUnet. 156 </t> 157 </section> 158 <section anchor="protocol_flow" numbered="true" toc="default"> 159 <name>Protocol Flow</name> 160 <t> 161 This protocol is heavily inspired by <xref target="KEMTLS"/>. 162 </t> 163 <t> 164 We assume that the peers have semi-static (as opposed to ephemeral) key pairs. Let (pk<sub>A</sub>,sk<sub>A</sub>) be the key pair of peer PID<sub>A</sub> and (pk<sub>B</sub>,sk<sub>B</sub>) the key pair of peer PID<sub>B</sub>. 165 </t> 166 <t> 167 For any secure handshake protocol, we have to dermine an initiator and a responder in the protocol. We use <tt>GNUNET_CRYPTO_hash_cmp</tt> to determine which peer is the responder R and which peer the initiator I: 168 </t> 169 <sourcecode> 170 <![CDATA[ 171 if (GNUNET_CRYPTO_hash_cmp (pk_A, pk_B)) 172 { 173 pk_I = pk_A 174 pk_R = pk_B 175 } 176 else 177 { 178 pk_I = pk_B 179 pk_R = pk_A 180 } 181 ]]> 182 </sourcecode> 183 <t> 184 It is possible that the designated initiator does not initiate the handshake. After a pre-determined timeout, the respective other peer may initiate. 185 We assume that the initiator knows pk<sub>R</sub> (pre-distributed through <tt>HELLO</tt>, for example). 186 </t> 187 <t> 188 Below is a swimlane of the protocol messages. 189 On the left and right side of the swimlanes the secrets known to the Initiator and Responder are 190 shown respectively. 191 If a private key of a key pair is known it is implied that the public key is also known. 192 Messages in brackets are optional. 193 Messages in braces are encrypted. 194 </t> 195 <figure anchor="figure_swimlane" title="Overview over the Handshake Protocol Flow."> 196 <artwork name="" type="" align="left" alt=""><![CDATA[ 197 Initiator Responder 198 sk_I | | sk_R 199 sk_e | | 200 r_I | | 201 pk_R | | 202 c_R | | 203 ss_e | | 204 ss_R | | 205 | | 206 | InitiatorHello: | 207 | r_I | 208 | pk_e | 209 | c_R | 210 | H(pk_R) | 211 | {pk_I,pc_I,svcinfo_I}ETS | 212 +---------------------------------------------->| 213 | | r_R 214 | | r_I 215 | | pk_I 216 | | c_R 217 | | c_I 218 | | c_e 219 | | ss_R 220 | | ss_I 221 | | ss_e 222 | ResponderHello: | 223 | r_R | 224 | c_e | 225 | {c_I,pc_R,svcinfo_R}RHTS | 226 | {finished_R}RHTS | 227 r_R | | 228 c_I | | 229 c_e | | 230 ss_I | | 231 ss_e | | 232 | InitiatorDone: | 233 | {finished_I}IHTS | 234 | [ACK]IATS | 235 +---------------------------------------------->| 236 | | 237 | | 238 | [ACK]RATS | 239 |<----------------------------------------------+ 240 | | 241 | | 242 | [Application Payload] | 243 |<--------------------------------------------->| 244 | | 245 v v 246 ]]></artwork> 247 </figure> 248 <t> 249 Notice how we do not need any acknowledgement messages until after finished<sub>R</sub> (after 1 RTT). 250 We use the ACKs in the handshake as explicit key confirmations. 251 The InitiatorHello message is a single flight that is implicitly ack'ed with ResponderHello. 252 ResponderHello is a single flight that is implicitly ack'ed with finished<sub>I</sub>. 253 The reason why this works is because CAKE groups the messages in row 3 of Table 1 in <xref target="RFC9147" section="5.7"/> into a single message (ResponderHello). 254 Hence the only message that is sent without any expected response (and consequently requiring an explicit ACK) is finished<sub>I</sub> (and Heartbeats). 255 pc<sub>X</sub> are 16 bit fields that indicate the peer class (FIXME peer class section). 256 N<sub>I</sub> is a nonce generated by the initiator. 257 N<sub>R</sub> is a nonce generated by the responder. 258 </t> 259 <t> 260 The Initiator creates the InitiatorHello message which includes the encrypted tuple (pk<sub>I</sub>,svcinfo_I). 261 The fields are encrypted using a key derived from the ETS according to <xref target="figure_swimlane"/> 262 and <xref target="figure_key_schedule"/>. 263 The so-called Responder KEM Challenge c<sub>R</sub> and the nonce r<sub>I</sub> are computed as: 264 </t> 265 <ol> 266 <li>(ss<sub>R</sub>,c<sub>R</sub>) <- Encaps(pk<sub>R</sub>). Reciver KEM Challenge.</li> 267 <li>r<sub>I</sub> <- RandomUInt64(). Initiator nonce.</li> 268 <li>Encrypt pk<sub>I</sub> and svcinfo<sub>I</sub> using ETS (seq=0).</li> 269 </ol> 270 <t> 271 R processes the InitiatorHello as follows: 272 </t> 273 <ol> 274 <li>Verify that the message type is CORE_INITIATOR_HELLO. See Message Header.</li> 275 <li>Verify that H(pk_R) matches R's pk_R.</li> 276 <li>(ss<sub>R</sub>,c<sub>R</sub>) <- Decaps(sk<sub>R</sub>, c<sub>R</sub>). Response to Responder KEM Challenge.</li> 277 <li>(ss<sub>e</sub>,c<sub>e</sub>) <- Encaps(pk<sub>e</sub>). Ephemeral shared secret.</li> 278 <li>Generate ETS from <xref target="key_schedule"/> and decrypt pk<sub>I</sub>. pk<sub>I</sub> and svcinfo_I may be processed now.</li> 279 <li>(ss<sub>I</sub>,c<sub>I</sub>) <- Encaps(pk<sub>I</sub>). Initiator KEM Challenge.</li> 280 <li>Generate RHTS and RATS from <xref target="key_schedule"/>.</li> 281 </ol> 282 <t> 283 The ETS, the Handshake and Master Secrets are generated according to <xref target="figure_key_schedule"/>. 284 Note that IATS cannot be derived (yet) at this point. 285 R may now generate its ResponderHello message: 286 </t> 287 <ol> 288 <li>r<sub>R</sub> <- RandomUInt64(). Responder nonce.</li> 289 <li>Encrypt svcinfo_R and c<sub>I</sub> (Initiator KEM Challenge) using RHTS (seq=0).</li> 290 <li>Create finished<sub>R</sub> as per <xref target="cake_hs_proto"/>.</li> 291 <li>Encrypt finished<sub>R</sub> with RHTS (seq=1).</li> 292 <li>Optionally, R may now already send application data encrypted with RATS.</li> 293 </ol> 294 <t> 295 I processes the message received by R: 296 </t> 297 <ol> 298 <li>Verify that the message type is CORE_Responder_HELLO. See Message Header</li> 299 <li>ss<sub>e</sub> <- Decaps(sk<sub>e</sub>,c<sub>e</sub>). Ephemeral shared secret.</li> 300 <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt svcinfo_R, c<sub>I</sub> and finished<sub>R</sub>.</li> 301 <li>ss<sub>I</sub> <- Decaps(sk<sub>I</sub>,c<sub>I</sub>). Response to KEM Challenge</li> 302 <li>Create finished<sub>R</sub> as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li> 303 <li>Create finished<sub>I</sub> as per <xref target="cake_hs_proto"/>.</li> 304 <li>Send finished<sub>I</sub> message encrypted with the key derived from IHTS (seq=0) to R</li> 305 </ol> 306 <t> 307 At this point we have a secure channel. 308 </t> 309 <t> 310 Note that for the handshake we do not use epochs or sequence numbers. 311 The reason for this is simple: DTLS uses epoch 0 for plaintext messages. 312 Epoch 1 is reserved for payload encrypted with a key derived from ETS. 313 However, we only have a single message that contains such a payload: InitiatorHello. 314 Epoch 2 is reserved for payload encrypted with a key derived from *HTS. 315 But we only have a single message that contains a payload encrypted with a key 316 derived from RHTS: ResponderHello. 317 We also only have a single message that contains a payload encrypted with a key 318 derived from IHTS: finished<sub>I</sub>. 319 Consequently, we do not need any signalling of Epochs until we encrypt data using 320 *ATS secrets. 321 The optional application data that may already be sent by the responder after its first 322 handshake message or by the initiator after its second handshake message, are 323 already wrapped inside an EncryptedMessage and have both Epoch and sequence numbers set. 324 </t> 325 </section> 326 <section anchor="key_schedule" numbered="true" toc="default"> 327 <name>Key Schedule</name> 328 <t> 329 The key schedule is very similar to <xref target="RFC8446"/> Section 7.1: 330 </t> 331 <figure anchor="figure_key_schedule" title="The Key Schedule."> 332 <artwork name="" type="" align="left" alt=""><![CDATA[ 333 HKDF-Extract(ss_R,0) = Early Secret (ES) 334 | 335 +-----> HKDF-Expand-Label(., 336 | "early data", 337 | H(T(H(pk_R)))) 338 | = Early Transport Secret (ETS) 339 | 340 v 341 HKDF-Expand-Label(., 342 | "derived", 343 | "") = derived Early Secret (dES) 344 | 345 v 346 HKDF-Extract(ss_e,.) = Handshake Secret (HS) 347 | 348 +-----> HKDF-Expand-Label(., 349 | "i hs traffic", 350 | H(T(r_R))) 351 | = IHTS 352 | 353 +-----> HKDF-Expand-Label(., 354 | "r hs traffic", 355 | H(T(r_R))) 356 | = RHTS 357 v 358 HKDF-Expand-Label(., 359 | "derived", 360 | "") = derived Handshake Secret (dHS) 361 | 362 v 363 HKDF-Extract(ss_I,.) = Master Secret (MS) 364 | 365 +-----> HKDF-Expand-Label(., 366 | "i ap traffic", 367 | H(T({finished_I}))) 368 | = IATS_0 369 | 370 +-----> HKDF-Expand-Label(., 371 "r ap traffic", 372 H(T({finished_R}))) 373 = RATS_0 374 ]]></artwork> 375 </figure> 376 <t> 377 "." shows the argument position of the input variable from the incoming arrow. 378 </t> 379 <t> 380 In general the transcript hashes are part of the HKDF-Expand calls. 381 The transcript hash is defined as the hash over the message parts sent (or to be sent) and received on the wire 382 up until that point. 383 </t> 384 <t> 385 Notice that from the very beginning ss<sub>R</sub> is required for the key schedule. 386 This means that R must be able to solve the Responder KEM Challenge c<sub>R</sub>. 387 Similarly, the master secret (MS) requires knowledge of ss<sub>I</sub>. 388 This means that I must be able to solve the Initiator KEM Challenge c<sub>I</sub>. 389 The KEM Challenges provide the underlying public key authentication mechanism. 390 </t> 391 <t> 392 When a traffic secret ([I,R][A,H]TS or ETS) is used to encrypt data, the respective 393 encryption key and starting nonce is generated as follows: 394 </t> 395 <figure anchor="figure_traffic_key_derivation" title="Traffic Key Generation."> 396 <artwork name="" type="" align="left" alt=""><![CDATA[ 397 key = HKDF-Expand-Label [I,R][A,H]TS, "key", 32) 398 nonce = HKDF-Expand-Label ([I,R][A,H]TS, "iv", 24) 399 ]]></artwork> 400 </figure> 401 <t> 402 Notice that the per-message nonce is generated from the nonce above 403 as defined in <xref target="RFC8446" section="5.3"/> from the sequence number. 404 </t> 405 <t> 406 After a successful initial handshake, both initiator and responder may 407 update the application traffic secrets ([A,I]ATS) and generate new keys. 408 Let [I,R]ATS<sub>0</sub> be the initial secrets with index 0. 409 The next secret is derived as: 410 </t> 411 <figure anchor="figure_traffic_key_derivation_next" title="Traffic Secret Update."> 412 <artwork name="" type="" align="left" alt=""><![CDATA[ 413 [I,R]ATS_N+1 = HKDF-Expand-Label ([I,R]ATS_N, 414 "traffic_upd", 415 secret_len) 416 ]]></artwork> 417 </figure> 418 <t> 419 When a peer wants to update keys, it sends a key update message <xref target="heartbeat_msg"/>. 420 Implementations <bcp14>SHOULD</bcp14> delete old traffic secrets and their derived keys. 421 </t> 422 </section> 423 <section anchor="cake_hs_proto" numbered="true" toc="default"> 424 <name>The CAKE Handshake Protocol</name> 425 <t> 426 This section is named and structured to mimic <xref target="RFC9147" section="5"/>. 427 </t> 428 <section anchor="timeout_retransmission" numbered="true" toc="default"> 429 <name>Timeout and Retransmission</name> 430 <t> 431 CAKE reuses the logic for timeout and retransmission from <xref target="RFC9147" section="5.8"/>. 432 It differs in that large flight sizes are not of concern for CAKE. 433 Similarly, the only Post-Handshake message relevant for CAKE is the KeyUpdate message. 434 </t> 435 </section> 436 <section anchor="crypto_label" numbered="true" toc="default"> 437 <name>Cryptographic Label Prefix</name> 438 <t> 439 <xref target="RFC8446" section="7.1"/> specifies that HKDF-Expand-Label uses a label prefix of "tls13 ". 440 For CAKE, that label <bcp14>SHALL</bcp14> be "cake10". 441 This ensures key separation between CAKE, DTLS 1.3 and TLS 1.3. 442 </t> 443 </section> 444 <section anchor="svcinfo" numbered="true" toc="default"> 445 <name>Services Info Field</name> 446 <t> 447 The svcinfo field is a string consisting of key-value pairs separated by 448 a separator indicating supported services and their versions. 449 E.g. "dht:1.1;cadet:0.4". 450 The field is zero terminated. 451 </t> 452 </section> 453 <section anchor="finished_field" numbered="true" toc="default"> 454 <name>Finished Field</name> 455 <t> 456 The HandshakeFinished field contains either finished<sub>I</sub> 457 or finished<sub>R</sub> value: 458 </t> 459 <ol> 460 <li>fk<sub>I</sub> <- HKDF-Expand-Label(MS, "i finished", NULL)</li> 461 <li>finished<sub>I</sub> <- HMAC(fk<sub>I</sub>, H(T({finished<sub>R</sub>})))</li> 462 </ol> 463 <ol> 464 <li>fk<sub>R</sub> <- HKDF-Expand-Label(MS, "r finished", NULL)</li> 465 <li>finished<sub>R</sub> <- HMAC(fk<sub>R</sub>, H(T({svcinfo_R,c_I}))</li> 466 </ol> 467 </section> 468 <section anchor="cake_hs_msg_fmt" numbered="true" toc="default"> 469 <name>CAKE Message Format</name> 470 <t> 471 Any sent message starts with a <tt>MessageHeader</tt>: 472 </t> 473 <figure anchor="figure_msghdr" title="The Wire Format of the Message Header."> 474 <artwork name="" type="" align="left" alt=""><![CDATA[ 475 0 8 16 24 32 40 48 56 476 +-----+-----+-----+-----+-----+-----+-----+-----+ 477 | Size | Type (0xXX) | 478 +-----+-----+-----+-----+-----+-----+-----+-----+ 479 ]]></artwork> 480 </figure> 481 <dl> 482 <dt>size:</dt> <dd>The size of the message including the Size and Type fields.</dd> 483 <dt>type:</dt> <dd>The message type.</dd> 484 </dl> 485 <t> 486 The possible types of messages are: 487 </t> 488 <ul> 489 <li>InitiatorHello</li> 490 <li>ResponderHello</li> 491 <li>InitiatorDone</li> 492 <li>EncryptedMessage</li> 493 </ul> 494 <t> 495 An encrypted message also always starts with a MessageHeader 496 and the allowed types are: 497 </t> 498 <ul> 499 <li>Hearbeat</li> 500 <li>Ack</li> 501 <li>ApplicationData</li> 502 </ul> 503 </section> 504 <section anchor="initiator_hello" numbered="true" toc="default"> 505 <name>InitiatorHello Message</name> 506 <t> 507 The InitiatorHello: 508 </t> 509 <figure anchor="figure_inithello" title="The Wire Format of the InitiatorHello."> 510 <artwork name="" type="" align="left" alt=""><![CDATA[ 511 0 8 16 24 32 40 48 56 512 +-----+-----+-----+-----+-----+-----+-----+-----+ 513 | r_I | 514 +-----+-----+-----+-----+-----+-----+-----+-----+ 515 | pk_e | 516 | | 517 | | 518 +-----+-----+-----+-----+-----+-----+-----+-----+ 519 | c_R | 520 | | 521 | | 522 | | 523 +-----+-----+-----+-----+-----+-----+-----+-----+ 524 | H(pk_R) (512 bit) | 525 / / 526 | | 527 +-----+-----+-----+-----+-----+-----+-----+-----+ 528 / {pk_I,pc_I,svcinfo_I} / 529 ]]></artwork> 530 </figure> 531 <t> 532 The initiator kem challenge c<sub>R</sub> is generated according to <xref target="figure_key_schedule"/> using: 533 </t> 534 <ol> 535 <li>(ss<sub>R</sub>,c<sub>R</sub>) <- Encaps(pk<sub>R</sub>)</li> 536 </ol> 537 <t> 538 The pk<sub>I</sub> and <tt>ServiceInfo</tt> are encrypted using XChaCha20-Poly1305 <xref target="RFC8439"/> 539 with key and IV derived from the ETS. 540 <!-- FIXME: Discuss IV. We may be able to use data from HKDF-Expand for that --> 541 </t> 542 </section> 543 <section anchor="responder_hello" numbered="true" toc="default"> 544 <name>ResponderHello Message</name> 545 <t> 546 The ResponderHello: 547 </t> 548 <figure anchor="figure_recvhello" title="The Wire Format of the ResponderHello."> 549 <artwork name="" type="" align="left" alt=""><![CDATA[ 550 0 8 16 24 32 40 48 56 551 +-----+-----+-----+-----+-----+-----+-----+-----+ 552 | r_R | 553 +-----+-----+-----+-----+-----+-----+-----+-----+ 554 | c_e | 555 | | 556 | | 557 | | 558 +-----+-----+-----+-----+-----+-----+-----+-----+ 559 / {c_I,pc_I,svcinfo_R}{finished_R} / 560 ]]></artwork> 561 </figure> 562 <t> 563 The protected fields after the nonce are encrypted using a key derived from AHTS. 564 The finished<sub>R</sub> is encrypted individually. 565 This is because the transcript of the ResponderHello to generate the 566 finished<sub>R</sub> must end before it. 567 </t> 568 </section> 569 <section anchor="handshake_finished" numbered="true" toc="default"> 570 <name>InitiatorDone Message</name> 571 <t> 572 The InitiatorDone message contains the finished<sub>I</sub> field 573 encrypted with a key derived from the IHTS. 574 The message type <bcp14>MUST</bcp14> be CORE_INITIATOR_DONE. 575 </t> 576 </section> 577 <section anchor="encrypted_message" numbered="true" toc="default"> 578 <name>EncryptedMessage</name> 579 <t> 580 The EncryptedMessage follows a message header with type <tt>CORE_ENCRYPTED_MESSAGE</tt>: 581 </t> 582 <figure anchor="figure_encryptedmsg" title="The Wire Format of the EncryptedMessage header."> 583 <artwork name="" type="" align="left" alt=""><![CDATA[ 584 0 8 16 24 32 40 48 56 585 +-----+-----+-----+-----+-----+-----+-----+-----+ 586 | Epoch | 587 +-----+-----+-----+-----+-----+-----+-----+-----+ 588 | Sequence Number | 589 +-----+-----+-----+-----+-----+-----+-----+-----+ 590 | Tag | 591 | | 592 +-----+-----+-----+-----+-----+-----+-----+-----+ 593 ]]></artwork> 594 </figure> 595 <t> 596 The epoch starts at 0 after the handshake with the first *ATS secret. 597 Any peer may at any time update to a new epoch. 598 Peers may keep a history of secrets for respective epochs at their own discretion in 599 order to handle out-of-order message deliveries. 600 Unlike DTLS1.3 in CAKE does not truncate the epoch and no reconstruction is 601 necessary, hence the epoch may be bumped by peers at their own discretion without 602 explicit key update mechanisms. 603 A peer may consider the epoch too old or too far in the future and reject description. 604 For this purpose, a peer may manage a sliding window of epochs that can be used 605 by the other peer. 606 </t> 607 <t> 608 The sequence number is encrypted as defined in <xref target="RFC9147" section="4.2.3"/> 609 for ChaCha20-based AEAD schemes. 610 For clarity, the XOR-based encryption using the 64 byte output of ChaCha20 is as follows: 611 The Tag is divided into a 32-bit counter and 96-bit nonce for use with ChaCha20. 612 The key is derived from the *ats as follows: 613 </t> 614 <figure anchor="figure_sn_key_derivation" title="Traffic Key Generation."> 615 <artwork name="" type="" align="left" alt=""><![CDATA[ 616 sn_secret = HKDF-Expand-Label [I,R]ATS_N, "sn", 32) 617 ]]></artwork> 618 </figure> 619 <t> 620 Where [I,R]ATS_N is the respective ATS secret of epoch N. 621 The leading 8 bytes of the 64 byte output of ChaCha20 are then 622 XORed with the sequence number in network byte order: 623 </t> 624 <figure anchor="figure_sn_xor" title="Traffic Key Generation."> 625 <artwork name="" type="" align="left" alt=""><![CDATA[ 626 sn_key = HKDF-Expand-Label(Secret, "sn", "", 8) 627 mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 628 sn_enc = mask[0..8] XOR sn_nbo 629 ]]></artwork> 630 </figure> 631 <t> 632 Notice how this requires a ciphertext of at least 16 bytes. 633 But our ciphertexts are always at least 16 bytes due to the Poly1305 634 atuthentication tag. In fact, since the authentication tag is considered 635 part of the ciphertext, and is prepended in front of the encrypted plaintext, 636 the mask is always computed on the authentication tag only. 637 </t> 638 <t> 639 The Tag is followed by encrypted application data. 640 The length of the data is included in the size field of the MessageHeader 641 preceeding the EncryptedMessage header. 642 </t> 643 <t> 644 The per-message nonce is not transmitted and instead generated as defined in <xref target="RFC8446" section="5.3"/>. 645 <!-- FIXME the records/encryptions apply to all messages(?)--> 646 </t> 647 </section> 648 <section anchor="heartbeat_msg" numbered="true" toc="default"> 649 <name>Heartbeat</name> 650 <t> 651 The HEARTBEAT message is a simple MessageHeader inside an EncryptedMessage with type <tt>CORE_HEARTBEAT</tt> followed by an UpdateRequested indicator. 652 This means that for every received EncryptedMessage 653 the peer <bcp14>MUST</bcp14> check if this is a Heartbeat. 654 A Heartbeat message may implicitlyindicate that the sender has switched its 655 traffic secrets according to the key schedule in <xref target="key_schedule"/>. 656 If any bit in the UpdateRequested field is set, this means that the responder 657 of the Heartbeat <bcp14>SHOULD</bcp14> increment its epoch. 658 Any bytes following the UpdateRequested field are updated services info 659 svcinfo (<xref target="svcinfo"/>). 660 Services info updates are optional. 661 <!-- TODO: Incremental or full ServicesInfo --> 662 </t> 663 <figure anchor="figure_keyupdate_msg" title="The Wire Format of the EncryptedMessage header."> 664 <artwork name="" type="" align="left" alt=""><![CDATA[ 665 0 8 16 24 32 666 +-----+-----+-----+-----+ 667 | UpdateRequested | 668 +-----+-----+-----+-----+ 669 | svcinfo / 670 / / 671 ]]></artwork> 672 </figure> 673 </section> 674 <section anchor="ack_msg" numbered="true" toc="default"> 675 <name>ACK</name> 676 <t> 677 The ACK message is a simple MessageHeader inside an EncryptedMessage with 678 type <tt>CORE_ACK</tt>. 679 This means that for every received EncryptedMessage 680 the peer <bcp14>MUST</bcp14> check if this is an ACK message after decryption. 681 The peer may use the ACK in order to ensure liveliness of connected peers in 682 combination with Heartbeats. 683 </t> 684 </section> 685 </section> 686 <section anchor="open" numbered="true" toc="default"> 687 <name>Open Issues</name> 688 <t> 689 We must discuss EdDSA vs X25519 KEM usage. Maybe see Communicator draft for this. 690 Basically, since we also use the EdDSA peer ID key for signing (HELLOs), we offer 691 any attacker a signing oracle against our X25519 public keys. 692 This should be safe, but it is not clean. 693 To solve this, we would have to separate HELLO signing keys and PID KX keys. 694 This issue did not arise before, because we used signed semi-statix DH keys. 695 </t> 696 <t> 697 The IETF ChaCha20 version is basically only recommended for use when a specification 698 or compatibility specifically requires it. 699 With ChaCha20, we would have to increment the nonce as it cannot be chosen securely at random 700 (not long enough). 701 XChaCha20 is the generally recommended cipher for any use case and we use it. 702 The only downside seems to be that XChaCha20 is practically not specified anywhere 703 (although it can be trivially defined in this document based on HChaCha) and only really implemented in libsodium. 704 </t> 705 <t> 706 We must define which KEM is to be used. 707 We may want to use our HPKE Elligator KEM <xref target="LSD0011"/>. 708 Using Elligator on this level may not be useful unless we also get rid of the plaintext message headers since 709 those definitely do not look random. 710 Ergo, the use of elligator probably makes more sense on the communicator level. 711 </t> 712 <t> 713 The Initiator/Responder selection logic may require a timed fallback: The designates Initiator may never initiate (NAT, already has sufficient connections, learns about responder later than responder about initiator etc.). 714 715 This may result in edge cases where the Initiator initiates a handshake and the Responder also initiates a handshake at the same time switching roles. 716 717 In such cases we may simply do both key exchanges. If both succeed, we drop the key exchange that was not initiated by the designated initiator on both peers. Otherwise we use the successful key exchange and the roles are swapped. 718 </t> 719 </section> 720 <section anchor="security" numbered="true" toc="default"> 721 <name>Security and Privacy Considerations</name> 722 <t> 723 TODO 724 </t> 725 </section> 726 <!-- gana --> 727 <section> 728 <name>GANA Considerations</name> 729 <t> 730 - 731 </t> 732 </section> 733 <section> 734 <name>Implementation and Deployment Status</name> 735 <t> 736 The CAKE handshake is currently implemented in a branch. 737 Open tasks include: 738 </t> 739 <ol> 740 <li>Requesting key updates</li> 741 <li>Use KDF/Hash Function, SHA2 vs Blake2b</li> 742 <li>Services info transmission (currently empty/unused)</li> 743 <li>Integrate and test PILS PID changes (potentially requires in-band signalling of new PIDs in CORE, not really that much related to CAKE)</li> 744 </ol> 745 </section> 746 <!-- <section> 747 <name>Acknowledgements</name> 748 <t> 749 FIXME 750 </t> 751 </section>--> 752 </middle> 753 <back> 754 <references> 755 <name>Normative References</name> 756 &RFC2119; 757 &RFC8174; 758 &RFC8439; 759 &RFC8446; 760 &RFC9147; 761 &RFC9180; 762 763 <reference anchor="LSD0011" target="https://lsd.gnunet.org/lsd0011"> 764 <front> 765 <title>The HPKE Elligator KEM</title> 766 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"> 767 <organization>Fraunhofer AISEC</organization> 768 </author> 769 <author initials="P." surname="Fardzadeh" fullname="Pedram Fardzadeh"> 770 <organization>Technische Universität München</organization> 771 </author> 772 <date year="2024"/> 773 </front> 774 </reference> 775 </references> 776 <references> 777 <name>Informative References</name> 778 <reference anchor="KEMTLS" target="https://thomwiggers.nl/publication/thesis/"> 779 <front> 780 <title>Post-Quantum TLS</title> 781 <author initials="T." surname="Wiggers" fullname="Thom Wiggers"> 782 <organization>Radboud University</organization> 783 </author> 784 <date year="2024"/> 785 </front> 786 </reference> 787 </references> 788 </back> 789 </rfc>