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