idnits 2.17.1 draft-ietf-trill-group-keying-08.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 (July 7, 2021) is 1018 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) ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- No information found for draft-eastlake-chacha20-key-wrap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ChaChaKW' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei 3 Dacheng Zhang 4 Huawei 5 Expires: January 6, 2022 July 7, 2021 7 Simple Group Keying Protocol (SGKP) 8 10 Abstract 12 This document specifies a simple general group keying protocol that 13 provides for the distribution of shared secret keys to group members 14 and the management of such keys. It assumes that secure pairwise keys 15 can be created between any two group members. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the authors or the TRILL mailing list: trill@ietf.org. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 https://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Terminology and Acronyms..............................3 45 2. Simple Group Keying Protocol............................4 46 2.1 Assumptions............................................4 47 2.2 Group Keying Procedure Overview........................4 48 2.3 Transmission and Receipt of Group Data Messages........5 49 2.4 Changes in Group Membership or GKd.....................6 51 3. Group Keying Messages...................................7 52 3.1 Set Key Message........................................9 53 3.2 Use, Delete, Disuse, or Deleted Key Messages..........11 54 3.3 Response Message......................................12 55 3.3.1 Response Codes......................................13 56 3.4 No-Op Message.........................................15 58 4. Security Considerations................................16 59 5. IANA Considerations....................................17 61 Normative References......................................19 62 Informative References....................................19 64 Acknowledgements..........................................20 66 Authors' Addresses........................................21 68 1. Introduction 70 This document specifies a simple general group keying protocol that 71 provides for the distribution of shared secret keys to group members 72 and for the management of such keys. It assumes that secure pairwise 73 keys can be created between any two group members. 75 A companion document specifies two profiles for the use of this group 76 keying protocol in a case using DTLS and a case using IPsec payload 77 formats. It is anticipated that there will be other uses for this 78 group keying protocol. 80 1.1 Terminology and Acronyms 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119] [RFC8174] 85 when, and only when, they appear in all capitals, as shown here. 87 This document uses the following terms and acronyms: 89 AES - Advanced Encryption Standard. 91 DTLS - Datagram Transport Level Security [RFC6347]. 93 GKd - A distinguished station in a group that is in charge of 94 which group key (Section 2) is in use. 96 GKs - Stations in a group other than GKd (Section 2). 98 IS-IS - Intermediate System to Intermediate System [RFC7176]. 100 keying material - The set of a Key ID, a secret key, and a cypher 101 suite. 103 QoS - Quality of Service. 105 RBridge - An alternative term for a TRILL switch. 107 TRILL - Transparent Interconnection of Lots of Links or Tunneled 108 Routing in the Link Layer [RFC6325] [RFC7780]. 110 TRILL switch - A device that implements the TRILL protocol 111 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 113 2. Simple Group Keying Protocol 115 This section gives an overview of the assumptions and capabilities of 116 the Simple Group Keying Protocol (SGKP) that provides shared secret 117 group keys. Further details of the messages used for this protocol 118 are give in Section 3. 120 Any particular use of this protocol will require profiling giving 121 further details and specifics for that use. For example, the envelope 122 used for addressing and transmitting the messages of this protocol 123 must be specified for any particular use. This protocol is not 124 suitable for discovery messages but is intended for use between 125 members of a group that have already established or can establish 126 pair-wise security. 128 2.1 Assumptions 130 The following are assumed: 131 - All pairs of stations in the group can engage in pairwise 132 communication with unicast messages and each can groupcast a 133 message to the other group members. 134 - At any particular time, there is a distinguished station GKd in 135 the group that is in charge of keying for the groupcast data 136 messages to be sent to the group. The group wide shared secret 137 keys established by GKd are referred to herein as "dynamic" 138 keys. 139 - Pairwise keying has been negotiated between GKd and each other 140 station GKs1, GKs2, ... GKsN in the group. These keys are 141 referred to in this protocol as "pairwise" keys. 142 - There are one or more keys, other than the dynamic or pairwise 143 keys, which are already in place at all group member stations 144 and may be present at other stations. These are referred to as 145 "stable" keys. 147 When keying material is stored by a station, it is accompanied by a 148 "use flag" indicating whether or not that keying material is usable 149 for groupcast transmissions. 151 2.2 Group Keying Procedure Overview 153 GKd sends unicast keying messages to the other stations in the group 154 and they respond as specified below and in further detail in the 155 particular use profiles of SGKP. All such keying messages MUST be 156 encrypted and authenticated using the pairwise keys as further 157 specified in the use profile. 159 Typically, GKd sends a keying message to each GKs with keying 160 material. After successful acknowledgement of receipt from each GKs, 161 GKd sends a keying message to each GKs instructing it to use the 162 dynamic key GKd has set. It would be common for GKd to set a new 163 dynamic key at each GKs while an older dynamic key is in use so that 164 GKd can more promptly roll over to the new dynamic key when 165 appropriate. 167 To avoid an indefinite build up of keying material at a GKs, keys 168 have a lifetime specified by GKd and GKd can send a message deleting 169 a key. (GKd can also send a message indicating that a key is no 170 longer to be used but leaving it set.) Should the space available at 171 a GKs for keying material be exhausted, on receipt of a Set Key 172 keying message from GKd for a new key ID, GKs discards a dynamic key 173 it has and originates a Delete Key message to the source of that 174 dynamic key. 176 2.3 Transmission and Receipt of Group Data Messages 178 If a group has only one member, transmission of data between group 179 members is a moot question and any messages that would be so 180 transmitted if the group had more members are discarded. 182 If a group has only two members, then pairwise security is used 183 between them. 185 When a group has more than two members and a station in the group 186 transmits a data message to the group, if the transmitter has one or 187 more keys set by GKd that it has been instructed to use, it uses one 188 of those keys and its associated cypher suite to groupcast the data 189 message. If it has no such key, then it uses serial unicast to send 190 the data message to each other member of the group, negotiating 191 pairwise keys with them if it does not already have such pairwise 192 keys. Thus it is a responsibility of GKd not to authorize the use of 193 a groupcast key until it knows that all the GKs have that key. 195 When a station in the group receives data that has been groupcast to 196 the group, if the receiver has the key referenced by the data message 197 the receiver decrypts and verifies it. If verification fails or if 198 the receiver does not have the required key, the receiver discards 199 the data message. Thus whether GKs has been directed to "use" a key 200 by GKd is relevant only to transmission, not reception. 202 2.4 Changes in Group Membership or GKd 204 When a new station joins the group, GKd SHOULD send that station the 205 currently in-use group key and instruct it to use that key and MAY 206 send it other keys known to the group members and intended for future 207 use. 209 If GKd detects that one or more stations that were members of the 210 group are no longer members of the group, it SHOULD generate and 211 distribute a new group key to the remaining group members, instruct 212 them to use this new key, and delete from them any old keys known to 213 the departed group member station(s) or at least instructing them to 214 dis-use such old keys that are marked for use; however, in the case 215 of groups with large and/or highly dynamic membership, where a 216 station might frequently leave and then rejoin, it may, as a 217 practical matter, be necessary to rekey less frequently. 219 A new group member can become GKd due to the previous GKd leaving the 220 group or a configuration change or the like. A GKs MUST NOT use 221 keying material for transmission that was set by a station that it 222 determines is not GKd. To avoid a gap in service, a station that is 223 not GKd MAY set keying material at other stations in the group; 224 however, such a non-GKd station cannot set the use flag for any such 225 keying material. It is RECOMENDED that the second highest priority 226 station to be GKd set such keying material at all other stations in 227 the group. Should a station run out of room for keying material, it 228 SHOULD discard keying material set by a station with lower priority 229 to be GKd before discarding keying material set by a higher priority 230 station and among keys set by GKd is SHOULD discard the lest recently 231 used first. 233 3. Group Keying Messages 235 Keying messages start with a Version number. This document specifies 236 Version zero. 238 Keying messages are structured, as shown in Figure 3.1 below, as 239 o a Version number, 240 o a Response flag, 241 o a Key ID length, 242 o the Key ID of a stable key, 243 o a group keying use profile identifier, 244 o possible padding, 245 o a key wrap algorithm specifier, and finally 246 o a key wrapped vector of additional fields wrapped using a key 247 derived from the stable key identified. 249 Keying messages are always sent unicast and encrypted and 250 authenticated with the appropriate pairwise key, all as further 251 specified for the particular use profile. It will typically be 252 possible for GKd to calculate the keying message once, including the 253 wrapping under a key derived from the stable key, then send that 254 message to various GKs using the different pairwise keys for each 255 GKs. 257 +-+-+-+-+-+-+-+-+ 258 |Ver|R|KeyID1Lng| 1 byte 259 +-+-+-+-+-+-+-+-+... 260 | KeyID1 ... KeyID1Lngth bytes 261 +-+-+-+-+-+-+-+-+... 262 | Use Type | 1 byte 263 +-+-+-+-+-+-+-+-+ 264 | Pad1 Length | 1 byte 265 +-+-+-+-+-+-+-+-+... 266 | Padding Pad1 Length bytes 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 268 | KW Al | KW Length | 2 bytes 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 270 | 271 | Key Wrapped Material Variable size 272 | 273 +-+-+-+-+-+-+-+-... 275 Figure 3.1. Keying Message Structure 277 The fields in Figure 3.1 are as follows: 279 Ver - Group Keying protocol version. This document specifies 280 version zero. 282 R - Response flag. If set to one, indicates a response message. 283 If set to zero, indicated a request or no-op message. 285 KeyID1Lngth, KeyID1 - KeyID1 identifies the stable key wrapping 286 key (also known as the Key Encrypting Key (KEK)) as further 287 specified in the use profile. KeyID1Lngth is a 5-bit field 288 that gives the length of KeyID1 in bytes minus 1 as an 289 unsigned integer. 291 Use Type - Specifies the particular group security use profile 292 such as one of the two profiles in [SGKPuses]. See Section 293 5, Item 3. 295 Pad1 Length, Pad1 - Padding to obscure the non-padded message 296 size. Pad1 Length may be from 0 to 255 and gives the length 297 of the padding as an unsigned integer. Each byte of padding 298 MUST be equal to Pad1 Length. For example, 3 bytes of 299 padding with length is 0x03030303. 301 KW Algorithm - An unsigned integer 4-bit field specifying the 302 Key Wrap Algorithm. See Section 5, Item 4. 304 KW Length - An unsigned integer 14-bit field that gives the 305 length of the Key Wrapped Material in octets. 307 Key Wrapped Material - The output of the designated Key 308 Wrapping Algorithm on the message vector of fields using 309 the designated stable key. 311 The vector of fields contained within the key wrapping is specified 312 for the various keying messages in subsections below. The contents 313 of this wrapped vector are protected by the key wrapping as well as 314 being authenticated and super-encrypted by the pairwise keyed 315 security used for sending the overall keying message. The probability 316 that the stable key used for key wrapping is the same as the outer 317 message pairwise key MUST be insignificant (less that 1 in 2**64). 319 Each group keying message contains, in the key wrapped vector of 320 fields, a message type and a message ID set by the sender of a 321 request. These fields are returned in the corresponding response to 322 assist in the matching of response to requests, except that there is 323 no response required to the No-Op message. 325 If no response is received to a request (other than a No-Op request) 326 for an amount of time configurable in milliseconds from 1 to ( 2**15 327 - 1 ), the request is re-transmitted with the same message ID. These 328 retries can occur up to a configurable number of times from 1 to 8. 329 Unless otherwise provided in the particular use profile, the default 330 response delay threshold is 200 milliseconds and the default maximum 331 number of retries is 3. 333 Keying messages are sent with a priority/QoS configurable on a per 334 device per use type basis. The default priority/QoS is specified in 335 the use profile. 337 Since the minimum length of the Key Wrapped Material is 16 bytes, the 338 minimum valid length of a keying message before pairwise security is 339 21 bytes, even if KeyID1 Length and Pad1 Length are zero. All multi- 340 byte fields are in network order, that is, with the most significant 341 byte first. The maximum valid length before pairwise security is 4 342 (fixed bytes) + 32 (max KeyID1) + 255 (max padding) + 264 (max KW 343 material) = 555 bytes. 345 3.1 Set Key Message 347 The structure of the wrapped vector of fields for the Set Key keying 348 message is as show in Figure 3.2. A recipient automatically 349 determines the overall length provided for this vector of fields 350 inside the key wrapping as a byproduct of the process of key 351 unwrapping. 353 +-+-+-+-+-+-+-+-+ 354 | Msg Type = 1 | 1 bytes 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Msg ID 3 bytes | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Pad2 Length | 1 bytes 359 +-+-+-+-+-+-+-+-+... 360 | Padding Pad2 Length bytes 361 +-+-+-+-+-+-+-+-+... 362 | Other Variable size 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Lifetime | 2 bytes 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | KeyID2 Length | 1 byte 367 +-+-+-+-+-+-+-+-+ 368 | KeyID2 ... KeyID2 Length bytes 369 +-+-+-+-+-+-+-+-+ 370 | CypherSuiteLng| 1 byte 371 +-+-+-+-+-+-+-+-+ 372 | CypherSuite ... CypherSuiteLng bytes 373 +-+-+-+-+-+-+-+-... 374 | Key ... Variable size 375 +-+-+-+-+-+-+-+-... 377 Figure 3.2. Set Key Message Inner Structure 379 The fields are as follows: 381 Msg Type = 1 for Set Key message 383 Msg ID - A 3 byte quantity to be included in the corresponding 384 response message to assist in matching requests and 385 responses. Msg ID zero has a special meaning in responses 386 and MUST NOT be used in a Set Key message or any other 387 group keying request message. 389 Pad2 Length, Pad2 - Padding to obscure the size of the unpadded 390 AES wrapped data. Pad2 Length may be from 0 to 255 and 391 gives the length of the padding as an unsigned integer. 392 Each byte of padding MUST be equal to Pad1 Length. For 393 example, 2 bytes of padding with length byte is 0x020202. 395 Other - Additional information if specified in the use profile. 396 If Other information in this message is not mentioned in 397 the use profile, there is none and this portion of the 398 wrapped information is null. If a use profile specifies 399 Other information it must be possible to determine its 400 length so that following fields can be properly parsed and 401 so that the size of the Key field can be deduced; for 402 example, Other could begin with a length byte. 404 Lifetime - A 2-byte unsigned integer. After that number of 405 seconds plus one second, the key and associated information 406 being set MUST be discarded. Unless otherwise specified for 407 a particular use profile of this group keying protocol, the 408 default Lifetime is 15,000 seconds or a little over four 409 hours. 411 KeyID2 Length, KeyID2 - KeyID2 identifies the group key and 412 associated information being set as further specified in 413 the use profile. KeyID2 Length is an unsigned byte that 414 gives the length of KeyID2 in bytes. 416 CypherSuiteLng, CypherSuite - CypherSuite identifies the cypher 417 suite associated with the key being set as further 418 specified in the use profile. CypherSuite Length is an 419 unsigned byte the gives the length of CypherSuite in bytes. 421 Key - This is the actually group shared secret keying material 422 being set. Its length is deduced from the overall length of 423 the vector of fields (found by the key unwrap operation) 424 and the length of the preceding fields. 426 Keying material and associated cypher suite are indexed under the Key 427 ID and the identity of the station that sent the information. This 428 identity is normally the address of that station as specified in the 429 use profile. 431 If GKs already has a dynamic key set under KeyID2, the key's value 432 and associated cypher suite are compared with those in the Set Key 433 messages. If they are the same, the only receiver action is to update 434 the Lifetime information associated with KeyID2 and send a Response 435 message. If they are different, the lifetime, cypher suite, and key 436 (and possibly Other material) are replaced, the use flag is cleared, 437 and a Response message sent. 439 3.2 Use, Delete, Disuse, or Deleted Key Messages 441 The structure of the wrapped material for the Use Key, Delete Key, 442 Disuse Key, and Deleted Key keying messages are the same as each 443 other except for the message type and are shown in Figure 3.3 445 +-+-+-+-+-+-+-+-+ 446 | Msg Type = t | 1 byte 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Msg ID 3 bytes | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Pad2 Length | 1 bytes 451 +-+-+-+-+-+-+-+-+... 452 | Padding Pad2 Length bytes 453 +-+-+-+-+-+-+-+-+... 454 | Other Variable size 455 +-+-+-+-+-+-+-+-+... 456 | KeyID2 Length | 1 byte 457 +-+-+-+-+-+-+-+-+ 458 | KeyID2 ... KeyID2 bytes 459 +-+-+-+-+-+-+-+-+ 461 Figure 3.3. Use, Delete, Disuse, or Deleted Key Message 463 The Msg Type field specifies the particular message as follows: 465 Msg Type Message 466 -------- ---------- 467 2 Use Key 468 3 Delete Key 469 4 Disuse Key 470 5 Deleted Key 472 The remaining fields are as specified in Section 3.1. KeyID2 473 indicates the key to be used, deleted, for which use should cease, or 474 which has been deleted, depending on the message type. 476 It is RECOMMENDED that these messages be padded so as to be the same 477 length as a typical Set Key message. 479 The Delete Key is sent by a station believing itself to be GKd 480 instructing some GKs to delete a key. When a GKs spontaneously 481 deletes a key, it sends a Deleted Key message to the station from 482 which it received the key. The message types for Delete Key and 483 Deleted Key are different to minimize confusion in corner cases such 484 as the GKd changing while messages are in flight. The Msg ID used in 485 a Deleted Key message is created by the sending GKs from a space of 486 Msg IDs associated with that GKs, which space is independent of the 487 Msg IDs used in requests originated by GKd. 489 3.3 Response Message 491 The structure of the wrapped material for the Response group keying 492 message is as show below in Figure 3.4. A response message is 493 indicated by the R bit in the first byte of the message outside the 494 key wrapping. 496 A response MUST NOT be sent due to the receipt of a response. The R 497 bit is outside of the key wrapping so that this rule can be enforced 498 even in cases of difficulty in unwrapping. 500 +-+-+-+-+-+-+-+-+ 501 | Msg Type = n | 1 byte 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Msg ID 3 bytes | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Pad2 Length | 1 bytes 506 +-+-+-+-+-+-+-+-+... 507 | Padding Pad2 Length bytes 508 +-+-+-+-+-+-+-+-+... 509 | Other Variable size 510 +-+-+-+-+-+-+-+-+... 511 | Response Code | 1 byte 512 +-+-+-+-+-+-+-+-+ 513 | ReqPartLength | 1 byte 514 +-+-+-+-+-+-+-+-+... 515 | Request Part ReqPartLength bytes 516 +-+-+-+-+-+-+-+-... 518 Figure 3.4. Response Message Inner Structure 520 Except as specified below, the fields are as specified for the Key 521 Set message in Section 3.1. 523 Msg Type, Msg ID - The content of these field is copied from 524 the message in reply to which this Response message is sent 525 unless there is an error that stops the replying station 526 from determining them; in that case the special value zero 527 is used for the Msg Type and Msg ID. Errors where the Msg 528 Type and ID could not be determined are indicated by a 529 Response Code with its high order bit set to one, that is, 530 the 0b1xxxxxxx bit set. 532 Response Code - An unsigned byte giving the response as 533 enumerated in in Section 3.3.1. Any Response Code other 534 than a success indicates that the receiver took no action 535 on the request other than sending an error Response 536 message. 538 ReqPartLength, Request Part: It is usually usefully to include 539 some or all of the request message in error responses. 540 - If the Response Code high order two bits are zero, the 541 request succeeded and ReqPartLength MUST be set to zero 542 so Request Part will be null. 543 - If the Response Code high order two bits are zero one 544 (0b01xxxxxx), then there was an error in the part of the 545 request inside the key wrapping but the unwrap process 546 was successful. ReqPartLength is the length of the 547 request message material included in the Request Part 548 field. The included request material is from the 549 unwrapped vector of fields started with the Msg Type 550 byte. 551 - If the Response Code high order bit is one (the 552 0b1xxxxxxx is set), then there was an error parsing the 553 material outside the AES key wrap or an error in the AES 554 unwrapping process. ReqPartLength is the length of the 555 request message part included in the Request Part field. 556 The included part of the request starts with the first 557 byte of the message (the byte containing the version, 558 response flag, and KeyID1 Length). The key wrapped 559 material in the response message will still be wrapped. 561 3.3.1 Response Codes 563 The high order two bits of the Response Code have meaning as shown in 564 Table 3.1. 566 Top 2 Bits Category 567 ---------- ---------- 568 0b00 Success 569 0b01 AES wrap contents 570 0b10/11 Outside of AES wrap contents 572 Figure 3.1 Categories of Response Codes 574 Response Response 575 Decimal Hex Meaning 576 -------- -------- ---------- 577 0 0x00 Success 578 1 0x01 Success and the key at an existing key ID was 579 changed 580 2-47 0x02-0x2F Unassigned 581 48-63 0x30-0x3F Reserved for special success codes defined in 582 use profiles 583 64 0x40 Malformed inner fields (see Note 2 below) 584 65 0x41 Unknown or zero Msg Type in a request 585 66 0x42 Zero Msg ID in a request 586 68 0x43 Invalid length KeyID2 587 69 0x44 Unknown KeyID2 588 70 0x45 Invalid length CypherSuite 589 71 0x46 Unknown CyperSuite 590 72 0x47 Bad Key (see Note 3 below) 591 73-111 0x49-0x6F Unassigned 592 112-127 0x70-0x7F Reserved for error codes defined in use 593 profiles and related to the key wrapped 594 contents 595 128 0x80 Malformed message (see Note 1 below) 596 129 0x81 Invalid length KeyID1 597 130 0x82 Unknown KeyID1 598 131 0x83 Unknown Use Type 599 131 0x84 Key unwrap fails test for constant (e.g., AES 600 test 1, see Section 3 [RFC5649]). 601 132 0x85 Key unwrap fails message length versus 602 wrapped size test (e.g., AES test 2, 603 see Section 3 [RFC5649]). 604 133 0x86 Key unwrap fails test for value of padding 605 (e.g., AES test3, see Section 3 606 [RFC5649]). 607 134-175 0x86-0x7F Unassigned 608 176-191 0xB0-0xBF Reserved for error codes defined in use 609 profiles and related to parts of 610 message outside the key wrap contents 611 192 0xC0 No keys set 612 193 0xC1 Referenced key unknown 613 194 0xC2 Referenced key known but use flag not set 614 195-255 0xC3-0xFF Reserved 616 Response Code Notes: 618 Note 1 Message is too short or too long, AES wrapped material is too 619 short, Padding bytes are not the required value, or similar 620 fundamental message format problems. 622 Note 2 The key wrapped inner vector of fields is too short or too 623 long, Padding bytes are not the required value, or similar 624 fundamental vector of fields format problems. 626 Note 3 Key is not a valid length for CypherSuite or other internal 627 checks on key (for example, parity bits in a 64 bit DES key 628 (not that you should be using DES)) fail when they should be 629 correct. 631 Figure 3.2 Response Codes 633 3.4 No-Op Message 635 The No-Op message is a dummy message intended for use in disguising 636 metadata deducible from keying message transmissions. It requires no 637 response although a recipient can always decided to send a No-Op 638 message to a station from which it has received such a message. The 639 vector of fields inside the AES key wrap is as follows: 641 +-+-+-+-+-+-+-+-+ 642 | Msg Type = 6 | 1 byte 643 +-+-+-+-+-+-+-+-+ 644 | Pad2 Length | 1 bytes 645 +-+-+-+-+-+-+-+-+... 646 | Padding Pad2 Length bytes 647 +-+-+-+-+-+-+-+-... 649 Figure 3.5. No-Op Message Inner Structure 651 The Msg Type is set to 6 to indicate a No-Op message. 653 Pad2 Length and Padding are as specified in Section 3.1. It is 654 RECOMMENDED that Pad2 Length in a No-Op message be such as to make 655 its length the same as the length of a typical Set Key message. 657 4. Security Considerations 659 This section gives some general security considerations of this group 660 keying protocol as distinguished from security considerations of a 661 particular use profile. 663 The method by which the stations in the group discover each other is 664 specified in the group keying use profile. GKd controls group access 665 and generally learns whatever it needs to know about GKs during the 666 pairwise authentication and pairwise keying process. 668 The group keying provided by this protocol is shared secret keying. 669 This means that data messages can only be authenticated as coming 670 from some group member but not as coming from a specific group 671 member. If this level of authentication is insufficient, GKd can 672 simply not set keys or not set them as usable. This will force all 673 stations in the group that are configured to use security for multi- 674 destination transmissions to the group to serially unicast data to 675 the other group members using pairwise keying. 677 The content value of padding fields in the Group Keying protocol is 678 fixed so that it cannot be used as a covert channel. It might still 679 be possible to use the length of padding as a covert channel. 681 5. IANA Considerations 683 IANA is requested to perform the following actions: 685 1. Establish a protocol parameters web page for "Group Keying 686 Protocol Parameters" with the initial registries on that page 687 as specified below in this section. 689 2. Establish a "Message Type" registry on the Group Keying 690 Protocol Parameters page as follows: 692 Name: Message Types Registration Procedure: IETF Review 693 Reference: [this document] 695 Type Description Reference 696 ------- ----------- --------------- 697 0 Reserved [This document] 698 1 Set Key [This document] 699 2 Use Key [This document] 700 3 Delete Key [This document] 701 4 Disuse Key [This document] 702 5 Deleted Key [This document] 703 6 No-Op [This document] 704 7-250 Unassigned 705 251-254 Reserved for Private Use [This document] 706 255 Reserved [This document] 708 3. Establish a "Group Keying Use Profile" registry on the Group 709 Keying Protocol Parameters page as follows: 711 Name: Group Keying Use Profiles Registration Procedure: IETF 712 Review Reference: [This document] 714 Profile Description Reference(s) 715 --------- ----------- ------------ 716 0 Reserved [This document] 717 1 Extended RBridge Channel [SGKPuses] 718 2 TRILL over IP [SGKPuses] 719 3-250 Unassigned 720 251-254 Reserved for Private Use [This document] 721 255 Reserved [This document] 723 4. Establish a "Key Wrap Algorithm" registry on the Group Keying 724 Protocol Parameters page as follows: 726 Name: Key Wrap Algorithms Registration Procedure: IETF Review 727 Reference: [This document] 729 Code Algorithm Reference 730 ----- ----------- --------- 731 0 Reserved [This document] 732 1 AES [RFC5649] 733 2 ChaCha [ChaChaKW] 734 3-16 - Unassigned 735 17 Reserved [This document] 737 5. Establish a "Response Code" registry on the Group Keying 738 Protocol Parameters page as show below taking entries from the 739 Response Code table in Section 3.3.1 above. In the table of 740 values, the Reference column should be "[This document]" except 741 where the Meaning is "Unassigned" or "Reserved". 743 Name: Response Codes Registration Procedure: IETF Review 744 Reference: [This document] 746 Note: The top two bits of the Response Code indicate a category 747 as specified in Section 3.3.1 of [this document]. 749 Response Response 750 Decimal Hex Meaning Reference 751 -------- --------- ----------- --------- 752 0 0x00 Success [this document] 753 ... ... ... 754 255 0xFF Reserved 756 Normative References 758 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 760 March 1997, . 762 [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard 763 (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 764 10.17487/RFC5649, September 2009, . 767 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 768 Ghanwani, "Routing Bridges (RBridges): Base Protocol 769 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 770 . 772 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 773 Security Version 1.2", RFC 6347, January 2012, . 776 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 777 D., and A. Banerjee, "Transparent Interconnection of Lots of 778 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 779 . 781 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 782 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 783 Lots of Links (TRILL): Clarifications, Corrections, and 784 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 785 . 787 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 788 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 789 2017, . 791 [SGKPuses] - D. Eastlake, D. Zhang, "Simple Group Keying Protocol 792 TRILL Use Profiles", draft-ietf-trill-link-gk-profiles, work in 793 progress. 795 [ChaChaKW] - D. Eastlake, "CHA CHA 20 Key Wrap with Padding 796 Algorithm", draft-eastlake-chacha20-key-wrap, work in progress. 798 Informative References 800 None. 802 Acknowledgements 804 The contributions of the following are hereby gratefully 805 acknowledged: 807 TBD 809 Authors' Addresses 811 Donald E. Eastlake, 3rd 812 Futurewei Technologies 813 2386 Panoramic Circle 814 Apopka, FL 32703 USA 816 Phone: +1-508-333-2270 817 EMail: d3e3e3@gmail.com 819 Dacheng Zhang 820 Huawei Technologies 822 Email: dacheng.zhang@huawei.com 824 Copyright, Disclaimer, and Additional IPR Provisions 826 Copyright (c) 2021 IETF Trust and the persons identified as the 827 document authors. All rights reserved. 829 This document is subject to BCP 78 and the IETF Trust's Legal 830 Provisions Relating to IETF Documents 831 (http://trustee.ietf.org/license-info) in effect on the date of 832 publication of this document. Please review these documents 833 carefully, as they describe your rights and restrictions with respect 834 to this document. Code Components extracted from this document must 835 include Simplified BSD License text as described in Section 4.e of 836 the Trust Legal Provisions and are provided without warranty as 837 described in the Simplified BSD License. The definitive version of 838 an IETF Document is that published by, or under the auspices of, the 839 IETF. Versions of IETF Documents that are published by third parties, 840 including those that are translated into other languages, should not 841 be considered to be definitive versions of IETF Documents. The 842 definitive version of these Legal Provisions is that published by, or 843 under the auspices of, the IETF. Versions of these Legal Provisions 844 that are published by third parties, including those that are 845 translated into other languages, should not be considered to be 846 definitive versions of these Legal Provisions. For the avoidance of 847 doubt, each Contributor to the IETF Standards Process licenses each 848 Contribution that he or she makes as part of the IETF Standards 849 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 850 language to the contrary, or terms, conditions or rights that differ 851 from or are inconsistent with the rights and licenses granted under 852 RFC 5378, shall have any effect and shall be null and void, whether 853 published or posted by such Contributor, or included with or in such 854 Contribution.