idnits 2.17.1 draft-elkins-ippm-encrypted-pdmv2-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 February 2022) is 788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Elkins 3 Internet-Draft Inside Products, Inc. 4 Intended status: Proposed Standard M. Ackermann 5 Expires: 29 August 2022 BCBS Michigan 6 A. Deshpande 7 NITK Surathkal 8 T. Pecorella 9 A. Rashid 10 University of Florence 11 25 February 2022 13 IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination 14 Option 15 draft-elkins-ippm-encrypted-pdmv2-02.txt 17 Abstract 19 RFC8250 describes an optional Destination Option (DO) header embedded 20 in each packet to provide sequence numbers and timing information as 21 a basis for measurements. As this data is sent in clear- text, this 22 may create an opportunity for malicious actors to get information for 23 subsequent attacks. This document defines PDMv2 which has a 24 lightweight handshake (registration procedure) and encryption to 25 secure this data. Additional performance metrics which may be of use 26 are also defined. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 29 August 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Current Performance and Diagnostic Metrics (PDM) . . . . 3 63 1.2. PDMv2 Introduction . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Registration Phase . . . . . . . . . . . . . . . . . . . 5 68 4.1.1. Rationale of Primary (Writer) and Secondary (Reader) 69 Roles . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1.2. Diagram of Registration Flow . . . . . . . . . . . . 5 71 4.2. Primary (Writer) Client - Primary (Writer) Server 72 Negotiation Phase . . . . . . . . . . . . . . . . . . . . 5 73 4.3. Primary (Writer) Server / Client - Secondary (Reader) 74 Server / Client Registration Phase . . . . . . . . . . . 6 75 4.4. Secondary (Reader) Client - Secondary (Reader) Server 76 communication . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. Security Goals for Confidentiality . . . . . . . . . . . 7 79 5.2. Security Goals for Integrity . . . . . . . . . . . . . . 7 80 5.3. Security Goals for Authentication . . . . . . . . . . . . 7 81 5.4. Cryptographic Algorithm . . . . . . . . . . . . . . . . . 8 82 6. PDMv2 Destination Options . . . . . . . . . . . . . . . . . . 8 83 6.1. Destinations Option Header . . . . . . . . . . . . . . . 8 84 6.2. Metrics information in PDMv2 . . . . . . . . . . . . . . 8 85 6.3. PDMv2 Layout . . . . . . . . . . . . . . . . . . . . . . 9 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 11.1. References . . . . . . . . . . . . . . . . . . . . . . . 12 92 11.2. Normative References . . . . . . . . . . . . . . . . . . 12 93 11.3. Informative References . . . . . . . . . . . . . . . . . 13 94 Appendix A. Rationale for Primary (Writer) Server / Primary 95 (Writer) Client . . . . . . . . . . . . . . . . . . . . . 13 96 A.1. One Client / One Server . . . . . . . . . . . . . . . . . 13 97 A.2. Multiple Clients / One Server . . . . . . . . . . . . . . 14 98 A.3. Multiple Clients / Multiple Servers . . . . . . . . . . . 15 99 A.4. Primary (Writer) Client / Primary (Writer) Server . . . . 15 100 Appendix B. Sample Implementation of Registration . . . . . . . 15 101 B.1. Overall summary . . . . . . . . . . . . . . . . . . . . . 15 102 B.2. High level flow . . . . . . . . . . . . . . . . . . . . . 15 103 B.3. Commands used . . . . . . . . . . . . . . . . . . . . . . 16 104 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 105 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 16 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 108 1. Introduction 110 1.1. Current Performance and Diagnostic Metrics (PDM) 112 The current PDM is an IPv6 Destination Options header which provides 113 information based on the metrics like Round-trip delay and Server 114 delay. This information helps to measure the Quality of Service 115 (QoS) and to assist in diagnostics. However, there are potential 116 risks involved transmitting PDM data during a diagnostics session. 118 PDM metrics can help an attacker understand about the type of machine 119 and its processing capabilities. Inferring from the PDM data, the 120 attack can launch a timing attack. For example, if a cryptographic 121 protocol is used, a timing attack may be launched against the keying 122 material to obtain the secret. 124 Along with this, PDM does not provide integrity. It is possible for 125 a Man-In-The-Middle (MITM) node to modify PDM headers leading to 126 incorrect conclusions. For example, during the debugging process 127 using PDM header, it can mislead the person showing there are no 128 unusual server delays. 130 1.2. PDMv2 Introduction 132 PDMv2 introduces confidential, integrity and authentication. 134 TBD 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [RFC2119] . 143 In this document, these words will appear with that interpretation 144 only when in ALL CAPS. Lower case uses of these words are not to be 145 interpreted as carrying significance described in RFC 2119. 147 3. Terminology 149 * Primary (Writer) Client (WC): An authoritative node that creates 150 cryptographic keys for multiple reader clients. 152 * Primary (Writer) Server (WS): An authoritative node that creates 153 cryptographic keys for multiple reader servers. 155 * Secondary (Reader) Client (RC): An endpoint node which initiates a 156 session with a listening port and sends PDM data. Connects to the 157 Primary (Writer) Client to get cryptographic key material. 159 * Secondary (Reader) Server (RS): An endpoint node which has a 160 listening port and sends PDM data. Connects to the Primary 161 (Writer) Server to get cryptographic key material. 163 Note: a client may act as a server (have listening ports). 165 * Symmetric Key (K): A uniformly random bitstring as an input to the 166 encryption algorithm, known only to Secondary (Reader) Clients and 167 Secondary (Reader) Servers, to establish a secure communication. 169 * Public and Private Keys: A pair of keys that is used in asymmetric 170 cryptography. If one is used for encryption, the other is used 171 for decryption. Private Keys are kept hidden by the source of the 172 key pair generator, but Public Key is known to everyone. pkX 173 (Public Key) and skX (Private Key). Where X can be, any client or 174 any server. 176 * Pre-shared Key (PSK): A symmetric key. Uniformly random 177 bitstring, shared between any client or any server or a key shared 178 between an entity that forms client-server relationship. This 179 could happen through an out-of band mechanism: e.g., a physical 180 meeting or use of another protocol. 182 * Session Key: A temporary key which acts as a symmetric key for the 183 whole session. 185 4. Protocol Flow 187 The protocol will proceed in 3 steps. 189 Step 1: Negotiation between Primary (Writer) Server and Primary 190 (Writer) Client. 192 Step 2: Registration between Primary (Writer) Server / Client and 193 Secondary (Reader) Server / Client 195 Step 3: PDM data flow between Secondary (Reader) Client and 196 Secondary (Reader) Server 198 After-the-fact (or real-time) data analysis of PDM flow may occur by 199 network diagnosticians or network devices. The definition of how 200 this is done is out of scope for this document. 202 4.1. Registration Phase 204 4.1.1. Rationale of Primary (Writer) and Secondary (Reader) Roles 206 Enterprises have many servers and many clients. These clients and 207 servers may be in multiple locations. It may be less overhead to 208 have a secure location (ex. Shared database) for servers and clients 209 to share keys. Otherwise, each client needs to keep track of the 210 keys for each server. 212 Please view Appendix 1 for some sample topologies and further 213 explanation. 215 4.1.2. Diagram of Registration Flow 217 +------------+ +------------+ 218 | Writer |<--------------------->| Writer | 219 | Client | | Server | 220 +------+-----+ +------+-----+ 221 | | 222 +----------+----------+ +----------+----------+ 223 | | | | | | 224 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 225 | Reader| | Reader| | Reader| | Reader| | Reader| | Reader| 226 | 1 | | 2 | | 3 | | 1 | | 2 | | 3 | 227 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 228 | | | | | | 229 | | +--------------+ | | 230 | +------------------------------------+ | 231 +----------------------------------------------------------+ 233 4.2. Primary (Writer) Client - Primary (Writer) Server Negotiation 234 Phase 236 The two entities exchange a set of data to ensure the respective 237 identities. 239 They use HPKE KEM to negotiate a "SharedSecret". 241 4.3. Primary (Writer) Server / Client - Secondary (Reader) Server / 242 Client Registration Phase 244 The "SharedSecret" is shared securely: 246 * By the Primary (Writer) Client to all the Secondary (Reader) 247 Clients under its control. How this is achieved is beyond the 248 scope of the present specification. 250 * By the Primary (Writer)Server to all the Secondary (Reader) 251 Servers under its control. How this is achieved is beyond the 252 scope of the present specification. 254 4.4. Secondary (Reader) Client - Secondary (Reader) Server 255 communication 257 Each Client and Server derive a "SessionTemporaryKey" by using HPKE 258 KDF, using the following inputs: 260 * The "SharedSecret". 262 * The 5-tuple (SrcIP, SrcPort, DstIP, DstPort, Protocol) of the 263 communication. 265 * A Key Rotation Index (Kri). 267 The Kri SHOULD be initialized to zero. 269 The server and client initialize (separately) a pseudo-random non- 270 repeating sequence between 1 and 2^15-1. How to generate this 271 sequence is beyond the scope of this document, and does not affect 272 the rest of the specification. When the sequence is used fully, or 273 earlier if appropriate, the sender signals the other party that a key 274 change is necessary. This is achieved by flipping the "F bit" and 275 resetting the PRSEQ. The receiver increments the Kri of the sender, 276 and derives another SessionTemporaryKey to be used for decryption. 278 It shall be stressed that the two SessionTemporaryKeys used in the 279 communication are never the same, as the 5-tuple is reversed for the 280 Server and Client. Moreover, the time evolution of the respective 281 Kri can be different. As a consequence, each entity must maintain a 282 table with (at least) the following informations: 284 * Flow 5-tuple, Own Kri, Other Kri 286 An implementation might optimize this further by caching the 287 OwnSessionTemporaryKey (used in Encryption) and 288 OtherSessionTemporaryKey (used in Decryption). 290 5. Security Goals 292 As discussed in the introduction, PDM data can represent a serious 293 data leakage in presence of a malicious actor. 295 In particular, the sequence numbers included in the PDM header allows 296 correlating the traffic flows, and the timing data can highlight the 297 operational limits of a server to a malicious actor. Moreover, 298 forging PDM headers can lead to unnecessary, unwanted, or dangerous 299 operational choices, e.g., to restore an apparently degraded Quality 300 of Service (QoS). 302 Due to this, it is important that the confidentiality and integrity 303 of the PDM headers is maintained. PDM headers can be encrypted and 304 authenticated using the methods discussed in section [x], thus 305 ensuring confidentiality and integrity. However, if PDM is used in a 306 scenario where the integrity and confidentiality is already ensured 307 by other means, they can be transmitted without encryption or 308 authentication. This includes, but is not limited to, the following 309 cases: 311 a) PDM is used over an already encrypted medium (For example VPN 312 tunnels). 314 b) PDM is used in a link-local scenario. 316 c) PDM is used in a corporate network where there are security 317 measures strong enough to consider the presence of a malicious 318 actor a negligible risk. 320 5.1. Security Goals for Confidentiality 322 PDM data must be kept confidential between the intended parties, 323 which includes (but is not limited to) the two entities exchanging 324 PDM data, and any legitimate party with the proper rights to access 325 such data. 327 5.2. Security Goals for Integrity 329 PDM data must not be forged or modified by a malicious entity. In 330 other terms, a malicious entity must not be able to generate a valid 331 PDM header impersonating an endpoint, and must not be able to modify 332 a valid PDM header. 334 5.3. Security Goals for Authentication 336 TBD 338 5.4. Cryptographic Algorithm 340 Symmetric key cryptography has performance benefits over asymmetric 341 cryptography; asymmetric cryptography is better for key management. 342 Encryption schemes that unite both have been specified in [RFC1421], 343 and have been participating practically since the early days of 344 public-key cryptography. The basic mechanism is to encrypt the 345 symmetric key with the public key by joining both yields. Hybrid 346 public-key encryption schemes (HPKE) [RFC9180] used a different 347 approach that generates the symmetric key and its encapsulation with 348 the public key of the receiver. 350 Our choice is to use the HPKE framework that incorporates key 351 encapsulation mechanism (KEM), key derivation function (KDF) and 352 authenticated encryption with associated data (AEAD). These multiple 353 schemes are more robust and significantly efficient than the 354 traditional schemes and thus lead to our choice of this framework. 356 6. PDMv2 Destination Options 358 6.1. Destinations Option Header 360 The IPv6 Destination Options extension header [RFC8200] is used to 361 carry optional information that needs to be examined only by a 362 packet's destination node(s). The Destination Options header is 363 identified by a Next Header value of 60 in the immediately preceding 364 header and is defined in RFC 8200 [RFC8200]. The IPv6 PDMv2 365 destination option is implemented as an IPv6 Option carried in the 366 Destination Options header. 368 6.2. Metrics information in PDMv2 370 The IPv6 PDMv2 destination option contains the following base fields: 372 SCALEDTLR: Scale for Delta Time Last Received 373 SCALEDTLS: Scale for Delta Time Last Sent 374 GLOBALPTR: Global Pointer 375 PSNTP: Packet Sequence Number This Packet 376 PSNLR: Packet Sequence Number Last Received 377 DELTATLR: Delta Time Last Received 378 DELTATLS: Delta Time Last Sent 380 PDMv2 adds a new metric to the existing PDM [RFC8250] called the 381 Global Pointer. The existing PDM fields are identified with respect 382 to the identifying information called a "5-tuple". 384 The 5-tuple consists of: 386 SADDR: IP address of the sender 387 SPORT: Port for the sender 388 DADDR: IP address of the destination 389 DPORT: Port for the destination 390 PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.) 392 Unlike PDM fields, Global Pointer (GLOBALPTR) field in PDMv2 is 393 defined for the SADDR type. Following are the SADDR address types 394 considered: 396 a) Link-Local 398 b) Global Unicast 400 The Global Pointer is treated as a common entity over all the 401 5-tuples with the same SADDR type. It is initialised to the value 1 402 and increments for every packet sent. Global Pointer provides a 403 measure of the amount of IPv6 traffic sent by the PDMv2 node. 405 When the SADDR type is Link-Local, the PDMv2 node sends Global 406 Pointer defined for Link-Local addresses, and when the SADDR type is 407 Global Unicast, it sends the one defined for Global Unicast 408 addresses. 410 6.3. PDMv2 Layout 412 PDMv2 has two different header formats corresponding to whether the 413 metric contents are encrypted or unencrypted. The difference between 414 the two types of headers is determined from the Options Length value. 416 Following is the representation of the unencrypted PDMv2 header: 418 0 1 2 3 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Option Type | Option Length | Vrsn | Reserved Bits | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Random Number |f| ScaleDTLR | ScaleDTLS | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Global Pointer | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | PSN This Packet | PSN Last Received | 428 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Delta Time Last Received | Delta Time Last Sent | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Following is the representation of the encrypted PDMv2 header: 434 0 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Option Type | Option Length | Vrsn | Reserved Bits | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Random Number |f| | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 441 | Encrypted PDM Data : 442 : (30 bytes) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Option Type 447 0x0F 449 8-bit unsigned integer. The Option Type is adopted from RFC 450 8250 [RFC8250]. 452 Option Length 454 0x12: Unencrypted PDM 456 0x22: Encrypted PDM 458 8-bit unsigned integer. Length of the option, in octets, 459 excluding the Option Type and Option Length fields. The 460 options length is used for differentiating PDM [RFC8250], 461 unencrypted PDMv2 and encrypted PDMv2. 463 Version Number 465 0x2 467 4-bit unsigned number. 469 Reserved Bits 471 12-bits. 473 Reserved bits for future use. They are initialised to 0 for 474 PDMv2. 476 Random Number 477 15-bit unsigned number. 479 TBD 481 Flag Bit 483 1-bit field. 485 TBD 487 Scale Delta Time Last Received (SCALEDTLR) 489 8-bit unsigned number. 491 This is the scaling value for the Delta Time Last Sent 492 (DELTATLS) field. 494 Scale Delta Time Last Sent (SCALEDTLS) 496 8-bit unsigned number. 498 This is the scaling value for the Delta Time Last Sent 499 (DELTATLS) field. 501 Global Pointer 503 32-bit unsigned number. 505 Global Pointer is initialized to 1 for the different source 506 address types and incremented monotonically for each packet 507 with the corresponding source address type. 509 This field stores the Global Pointer type corresponding to the 510 SADDR type of the packet. 512 Packet Sequence Number This Packet (PSNTP) 514 16-bit unsigned number. 516 This field is initialized at a random number and is incremented 517 monotonically for each packet of the 5-tuple. 519 Packet Sequence Number Last Recieved (PSNLR) 521 16-bit unsigned number. 523 This field is the PSNTP of the last received packet on the 524 5-tuple. 526 Delta Time Last Received (DELTATLR) 528 16-bit unsigned integer. 530 The value is set according to the scale in SCALEDTLR. 532 Delta Time Last Received = 533 (send time packet n - receive time packet (n - 1)) 535 Delta Time Last Sent (DELTATLS) 537 16-bit unsigned integer. 539 The value is set according to the scale in SCALEDTLS. 541 Delta Time Last Sent = 542 (receive time packet n - send time packet (n - 1)) 544 7. Security Considerations 546 TBD 548 8. Privacy Considerations 550 TBD 552 9. IANA Considerations 554 This memo includes no request to IANA. 556 10. Contributors 558 TBD 560 11. References 562 11.1. References 564 11.2. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 572 Performance and Diagnostic Metrics (PDM) Destination 573 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 574 . 576 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 577 (IPv6) Specification", STD 86, RFC 8200, 578 DOI 10.17487/RFC8200, July 2017, 579 . 581 11.3. Informative References 583 [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 584 Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, 585 February 2022, . 587 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 588 Mail: Part I: Message Encryption and Authentication 589 Procedures", RFC 1421, DOI 10.17487/RFC1421, February 590 1993, . 592 Appendix A. Rationale for Primary (Writer) Server / Primary (Writer) 593 Client 595 A.1. One Client / One Server 597 Let's start with one client and one server. 599 +------------+ Derived Shared Secret +------------+ 600 | Client | -----------------> | Server | 601 +------+-----+ +------+-----+ 602 | | 603 V V 604 Client Secret Server Secret 606 The Client and Server create public / private keys and derive a 607 shared secret. Let's not consider Authentication or Certificates at 608 this point. 610 What is stored at the Client and Server to be able to encrypt and 611 decrypt packets? The shared secret or private key. 613 Since we only have one Server and one Client, then we don't need to 614 have any kind of identifier for which private key to use for which 615 Server or Client because there is only one of each. 617 Of course, this is a ludicrous scenario since no real organization of 618 interest has only one server and one client. 620 A.2. Multiple Clients / One Server 622 So, let's try with multiple clients and one Primary (Writer) server 624 +------------+ 625 | Client 1 | --------+ 626 +------------+ | 627 +------------+ +---> 628 | Client 2 | ----------> +------------+ 629 +------+-----+ : | Server | 630 : : +------+-----+ 631 : +----> 632 +------------+ | 633 | Client n | -------+ 634 +------+-----+ 636 The Clients and Server create public / private keys and derive a 637 shared secret. Each Client has a unique private key. 639 What is stored at the Client and Server to be able to encrypt and 640 decrypt packets? 642 Clients each store a private key. Server stores: Client Identifier 643 and Private Key. 645 Since we only have one Server and multiple Clients, then the Clients 646 don't need to have any kind of identifier for which private key to 647 use for which Server but the Server needs to know which private key 648 to use for which Client. So, the Server has to store an identifier 649 as well as the Key. 651 But, this also is a ludicrous scenario since no real organization of 652 interest has only one server. 654 A.3. Multiple Clients / Multiple Servers 656 When we have multiple clients and multiple servers, then each not 657 only does the Server need to know which key to use for which Client, 658 but the Client needs to know which private key to use for which 659 Server. 661 A.4. Primary (Writer) Client / Primary (Writer) Server 663 Based on this rationale, we have chosen a Primary (Writer) Server / 664 Primary (Writer) Client topology. 666 Appendix B. Sample Implementation of Registration 668 B.1. Overall summary 670 In the Registration phase, the objective is to generate a shared 671 secret that will be used in encryption and decryption during the Data 672 Transfer phase. We have adopted a Primary-Secondary architecture to 673 represent the clients and servers (see Section 4.1.1). The primary 674 server and primary client perform Key Encapsulation Mechanism (KEM) 675 [RFC9180] to generate a primary shared secret. The primary server 676 shares this secret with secondary servers, whereas the primary client 677 performs Key Derivation Function (KDF) [RFC9180] to share client- 678 specific secrets to corresponding secondary clients. During the Data 679 Transfer phase, the secondary servers generate the client-specific 680 secrets on the arrival of the first packet from the secondary client. 682 B.2. High level flow 684 The following steps describe the protocol flow: 686 1. Primary client initiates a request to the primary server. The 687 request contains a list of available ciphersuites for KEM, KDF, 688 and AEAD. 690 2. Primary server responds to the primary client with one of the 691 available ciphersuites and shares its public key. 693 3. Primary client generates a secret and its encapsulation. The 694 primary client sends the encapsulation and a salt to the primary 695 server. The salt is required during KDF in the Data Transfer 696 phase. 698 4. Primary Server generates the secret with the help of the 699 encapsulation and responds with a status message. 701 5. Primary server shares this key with secondary servers over TLS. 703 6. Primary client generates the client-specific secrets with the 704 help of KDF by using the info parameter as the Client IP address. 705 The primary client shares these keys with the corresponding 706 secondary clients over TLS. 708 B.3. Commands used 710 Two commands are used between the primary client and the primary 711 server to denote the setup and KEM phases. Along with this, we have 712 a "req / resp" to indicate whether it's a request or response. 714 Between primary and secondary entities, we have one command to denote 715 the sharing of the secret keys. 717 Appendix C. Change Log 719 Note to RFC Editor: if this document does not obsolete an existing 720 RFC, please remove this appendix before publication as an RFC. 722 Appendix D. Open Issues 724 Note to RFC Editor: please remove this appendix before publication as 725 an RFC. 727 Authors' Addresses 729 Nalini Elkins 730 Inside Products, Inc. 731 36A Upper Circle 732 Carmel Valley, CA, 93924 733 United States of America 735 Phone: +1 831 234 4232 736 Email: nalini.elkins@insidethestack.com 738 Michael Ackermann 739 BCBS Michigan 740 P.O. Box 2888 741 Detroit, Michigan, 48231 742 United States of America 744 Phone: +1 248 703 3600 745 Email: mackermann@bcbsm.com 746 URI: http://www.bcbsm.com 747 Ameya Deshpande 748 NITK Surathkal 749 Pashan-Baner Link Road, Pashan 750 Pune, Maharashtra, 411021 751 India 753 Phone: +91 96893 26060 754 Email: ameyanrd@gmail.com 755 URI: https://www.nitk.ac.in/ 757 Tommaso Pecorella 758 University of Florence 759 Dept. of Information Engineering, Via di Santa Marta, 3, 50139 760 Firenze 761 Italy 763 Phone: +39 055 2758540 764 Email: tommaso.pecorella@unifi.it 765 URI: https://www.unifi.it/ 767 Adnan Rashid 768 University of Florence 769 Dept. of Information Engineering, Via di Santa Marta, 3, 50139 770 Firenze 771 Italy 773 Phone: +39 347 9821 467 774 Email: adnan.rashid@unifi.it 775 URI: https://www.unifi.it/