idnits 2.17.1 draft-ietf-trill-group-keying-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (September 28, 2017) is 2374 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 3394 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Dacheng Zhang 3 Huawei 4 Expires: March 27, 2018 September 28, 2017 6 A Group Keying Protocol 7 9 Abstract 11 This document specifies a general group keying protocol. It also 12 provides use profiles for the application of this group keying 13 protocol to multi-destination TRILL Extended RBridge Channel message 14 security and TRILL over IP packet security. 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Distribution of this document is unlimited. Comments should be sent 22 to the authors or the TRILL working group mailing list: 23 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. Group Keying Protocol...................................5 46 2.1 Assumptions............................................5 47 2.2 Group Keying Procedure Overview........................5 48 2.3 Transmission and Receipt of Group Data Messages........6 49 2.4 Changes in Group Membership or GKd.....................6 50 2.5 Group Keying Messages..................................7 51 2.6 Set Key Message........................................9 52 2.7 Use, Delete, Disuse, or Deleted Key Messages..........11 53 2.8 Response Message......................................12 54 2.8.1 Response Codes......................................14 55 2.8 No-Op Message.........................................15 56 2.9 General Security Considerations.......................16 58 3. DTLS: Extended RBridge Channel Group Keyed Security....17 59 3.1 Transmission of Group Keying Messages.................17 60 3.2 Transmission of Protected Multi-destination Data......18 62 4. TRILL Over IP Group Keyed Security.....................19 63 4.1 Transmission of Group Keying Messages.................19 64 4.2 Transmission of Protected Multi-destination Data......19 66 5. IANA Considerations....................................20 67 5.1 Group Keying Protocol.................................20 68 5.2 Group Keying RBridge Channel Protocol Numbers.........21 69 5.3 Group Secured Extended RBridge Channel SType..........21 71 6. Security Considerations................................22 73 Normative References......................................23 74 Informative References....................................24 76 Acknowledgements..........................................25 77 Authors' Addresses........................................26 79 1. Introduction 81 This document specifies a general group keying protocol in Section 2. 82 In addition, it provides, in Section 3, the use profile for the 83 application of this group keying protocol to a case using DTLS (TRILL 84 [RFC6325] [RFC7780] Extended RBridge Channel message security 85 [RFC7178] [RFC7978]) and IPsec [TRILLoverIP}. It is anticipated that 86 there will be other uses for this group keying protocol. 88 1.1 Terminology and Acronyms 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119] [RFC8174] 93 when, and only when, they appear in all capitals, as shown here. 95 This document uses terminology and acronyms defined in [RFC6325] and 96 [RFC7178]. Some of these are repeated below for convenience along 97 with additional new terms and acronyms. 99 AES - Advanced Encryption Standard. 101 Data Label - VLAN or FGL. 103 DTLS - Datagram Transport Level Security [RFC6347]. 105 FGL - Fine Grained Label [RFC7172]. 107 GKd - A distinguished station in a group that is in charge of 108 which group keying (Section 2) is in use. 110 GKs - Stations in a group other than GKd (Section 2). 112 HKDF - Hash based Key Derivation Function [RFC5869]. 114 IS-IS - Intermediate System to Intermediate System [RFC7176]. 116 keying material - The set of a Key ID, a secret key, and a cypher 117 suite. 119 PDU - Protocol Data Unit. 121 QoS - Quality of Service. 123 RBridge - An alternative term for a TRILL switch. 125 SHA - Secure Hash Algorithm [RFC6234]. 127 TRILL - Transparent Interconnection of Lots of Links or Tunneled 128 Routing in the Link Layer. 130 TRILL switch - A device that implements the TRILL protocol 131 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 133 2. Group Keying Protocol 135 This section defines a general Group Keying Protocol that provides 136 shared secret group keys. Any particular use of this protocol will 137 require profiling giving further details and specifics for that use. 138 The protocol is not suitable for discovery messages but is intended 139 for use between members of a group that have already established 140 pair-wise security. 142 2.1 Assumptions 144 The following are assumed: 145 - All pairs of stations in the group can engage in pairwise 146 communication with unicast messages and each can groupcast a 147 message to the other group members. 148 - At any particular time, there is a distinguished station GKd in 149 the group that is in charge of keying for the groupcast data 150 messages to be sent to the group. The group wide shared secret 151 keys established by GKd are referred to herein as "dynamic" 152 keys. 153 - Pairwise keying has been negotiated between GKd and each other 154 station GKs1, GKs2, ... GKsN in the group. These keys are 155 referred to in this protocol as "pairwise" keys. 156 - One or more keys, other than the dynamic or pairwise keys, each 157 of which is already in place at all group member stations. These 158 are referred to as "stable" keys. 160 When keying material is stored by a station, it is accompanied by a 161 "use flag" indicating whether or not that keying material is usable 162 for groupcast transmissions. 164 2.2 Group Keying Procedure Overview 166 GKd sends unicast keying messages to the other stations in the group 167 and they respond as specified below and in further detail in the 168 particular use profiles for this Group Keying Protocol. All such 169 keying messages MUST be encrypted and authenticated using the 170 pairwise keys as further specified in the use profile. 172 Typically, GKd sends a keying message to each GKs with keying 173 material. After successful acknowledgement of receipt from each GKs, 174 GKd sends a keying message to each GKs instructing it to use the 175 dynamic key GKd has set. It would be common for GKd to set a new 176 dynamic key at each GKs while an older dynamic key is in use so that 177 GKd can more promptly roll over to the new key when appropriate. 179 To avoid an indefinite build up of keying material at a GKs, keys 180 have a lifetime specified by GKd and GKd can send a message deleting 181 a key. (GKd can also send a message indicating that a key is no 182 longer to be used but leaving it set.) Should the space available at 183 a GKs for keying material be exhausted, on receipt of a Set Key 184 keying message for a new key ID GKs discards a dynamic key it has and 185 originates a Delete Key message to the source of that dynamic key. 187 2.3 Transmission and Receipt of Group Data Messages 189 If a group has only two members, then pairwise security is used 190 between them. 192 When a group has more than two members and a station in the group 193 transmits a data message to the group, if the transmitter has one or 194 more keys set by GKd that it has been instructed to use, it uses one 195 of those keys and its associated cypher suite to groupcast the data 196 message. If it has no such key, then it uses serial unicast to send 197 the data message to each other member of the group, negotiating 198 pairwise keys with them if it does not already have such pairwise 199 keys. Thus it is a responsibility of GKd not to authorize the use of 200 a groupcast key until it knows that all the GKs have that key. 202 When a station in the group receives data that has been groupcast to 203 the group, if the receiver has the key referenced by the data message 204 the receiver decrypts and verifies it. If verification fails or if 205 the receiver does not have the required key, the receiver discards 206 the data message. Thus whether GKs has been directed to "use" a key 207 by GKd is relevant only to transmission, not reception. 209 2.4 Changes in Group Membership or GKd 211 When a new station joins the group, GKd should send that station the 212 currently in-use group key and instruct it to use that key and send 213 it other keys known to the group members and intended for future use. 215 If GKd detects that one or more stations that were members of the 216 group are no longer members of the group, it SHOULD generate and 217 distribute a new group key to the remaining group members, instruct 218 them to use this new key, and delete from them any old keys known to 219 the departed group member station(s) or at least instructing them to 220 disuse such old keys that are marked for use; however, in the case of 221 groups with large and/or highly dynamic membership, where a station 222 might frequently leave and then rejoin, it may, as a practical 223 matter, be necessary to rekey less frequently. 225 A new group member can become GKd due to the previous GKd leaving the 226 group or a configuration change or the like. A GKs MUST NOT use 227 keying material set by a station that it determines is not GKd. To 228 avoid a gap in service, a station that is not GKd MAY set keying 229 material at other stations in the group; however, such a non-GKd 230 station cannot set the use flag for any such keying material. It is 231 RECOMENDED that the second highest priority station to be GKd set 232 such keying material at all other stations in the group. Should a 233 station run out of room for keying material, it SHOULD discard keying 234 material set by a station with lower priority to be GKd before 235 discarding keying material set by a higher priority station and among 236 keys set by GKd is SHOULD discard the lest recently used first. 238 2.5 Group Keying Messages 240 Keying messages start with a Version number. This document specifies 241 Version zero. 243 Keying messages are structured as 244 o a Version number, 245 o a Response flag, 246 o a Key ID length, 247 o the Key ID of a stable key, 248 o a group keying use profile identifier, 249 o possible padding, and finally 250 o an AES key wrapped [RFC5649] [RFC3394] vector of additional 251 fields wrapped using the stable key identified and using 252 AES-256, as shown in Figure 2.1 below. 254 Keying messages are always sent unicast and encrypted and 255 authenticated with the appropriate pairwise key, all as further 256 specified for the particular use profile. It will typically be 257 possible for GKd to calculate the keying message once, including the 258 AES wrapping under a stable key, then send that message to various 259 GKs using the different pairwise keys for each GKs. 261 +-+-+-+-+-+-+-+-+ 262 |Ver|R|KeyID1Lng| 1 byte 263 +-+-+-+-+-+-+-+-+... 264 | KeyID1 ... KeyID1Lngth bytes 265 +-+-+-+-+-+-+-+-+... 266 | Use Type | 1 byte 267 +-+-+-+-+-+-+-+-+ 268 | Pad1 Length | 1 byte 269 +-+-+-+-+-+-+-+-+... 270 | Padding Pad1 Length bytes 271 +-+-+-+-+-+-+-+-+... 272 |AES Wrap Length| 1 byte 273 +-+-+-+-+-+-+-+-+... 274 | 275 | AES Wrapped Material Variable size 276 | 277 +-+-+-+-+-+-+-+-... 279 Figure 2.1. Keying Message Structure 281 The fields in Figure 2.1 are as follows: 283 Ver - Group Keying protocol version. This document specifies 284 version zero. 286 R - Response flag. If set to one, indicates a response message. 287 If set to zero, indicated a request or no-op message. 289 KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key 290 wrapping key (also known as the Key Encrypting Key (KEK)) 291 as further specified in the use profile. KeyID1Lngth is a 292 5-bit field that gives the length of KeyID1 in bytes as an 293 unsigned integer. 295 Use Type - Specifies the particular group security use profile 296 such as RBridge Extension (Section 3) or IP link 297 [TRILLoverIP]. 299 Pad1 Length, Pad1 - Padding to obscure the non-padded message 300 size. Pad1 Length may be from 0 to 255 and gives the length 301 of the padding as an unsigned integer. Each byte of padding 302 MUST be equal to Pad1 Length. For example, 3 bytes of 303 padding with length is 0x03030303. 305 AES Wrap Length - An unsigned byte that gives the length of the 306 AES Wrapped Material in units of 8 bytes. The length of AES 307 key wrapped material is, as specified in [RFC5649], always 308 a multiple of 8 bytes (64 bits) and not less than 16 bytes. 309 Thus an AES Wrap Length of 0 or 1 is invalid. 311 AES Wrapped Material - The output of the AES Key Wrapping 312 operation on the message vector of fields using the 313 specified stable key. 315 The vector of fields contained within the AES-256 key wrapping is 316 specified for the various keying messages in subsections below. The 317 contents of this wrapped vector are protected by the AES wrapping as 318 well as being authenticated and super-encrypted by the pairwise keyed 319 security used for sending the overall keying message. The stable key 320 used for AES wrapping MUST be different from the outer message 321 pairwise key. 323 Each group keying message contains, in the AES wrapped vector of 324 fields, a message type and a message ID set by the sender of a 325 request. These fields are returned in the corresponding response to 326 assist in the matching of response to requests, except that there is 327 no response to the No-Op message. 329 If no response is received to a request (other than a No-Op message) 330 for an amount of time configurable in milliseconds from 1 to ( 2**15 331 - 1 ), the request is re-transmitted with the same message ID. These 332 retries can occur up to a configurable number of times from 1 to 8. 333 Unless otherwise provided in the particular use profile, the default 334 response delay threshold is 200 milliseconds and the default maximum 335 number of retries is 3. 337 Keying messages are sent with a priority/QoS configurable on a per 338 device per use type basis. The default priority/QoS is specified in 339 the use profile. 341 Since the minimum length of the AES Wrapped Material is 16 bytes 342 [RFC5649], the minimum valid size of a keying message is 20 bytes, 343 even if KeyID1 Length and Pad1 Length are zero. All multi-byte fields 344 are in network order, that is, with the most significant byte first. 346 2.6 Set Key Message 348 The structure of the wrapped vector of fields for the Set Key keying 349 message is as show in Figure 2.2. A recipient automatically 350 determines the overall length provided for this vector of fields 351 inside the AES wrapping as a byproduct of the process of AES 352 unwrapping [RFC5649]. 354 +-+-+-+-+-+-+-+-+ 355 | Msg Type = 1 | 1 bytes 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Msg ID 3 bytes | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Pad2 Length | 1 bytes 360 +-+-+-+-+-+-+-+-+... 361 | Padding Pad2 Length bytes 362 +-+-+-+-+-+-+-+-+... 363 | Other Variable size 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Lifetime | 2 bytes 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | KeyID2 Length | 1 byte 368 +-+-+-+-+-+-+-+-+ 369 | KeyID2 ... KeyID2 Length bytes 370 +-+-+-+-+-+-+-+-+ 371 | CypherSuiteLng| 1 byte 372 +-+-+-+-+-+-+-+-+ 373 | CypherSuite ... CypherSuiteLng bytes 374 +-+-+-+-+-+-+-+-... 375 | Key ... Variable size 376 +-+-+-+-+-+-+-+-... 378 Figure 2.2. Set Key Message Inner Structure 380 The fields are as follows: 382 Msg Type = 1 for Set Key message 384 Msg ID - A 3 byte quantity to be included in the corresponding 385 response message to assist in matching requests and 386 responses. Msg ID zero has a special meaning in responses 387 and MUST NOT be used in a Set Key message or any other 388 group keying request message. 390 Pad2 Length, Pad2 - Padding to obscure the size of the unapdded 391 AES wrapped data. Pad2 Length may be from 0 to 255 and 392 gives the length of the padding as an unsigned integer. 393 Each byte of padding MUST be equal to Pad1 Length. For 394 example, 2 bytes of padding with length byte is 0x020202. 396 Other - Additional information if specified in the use profile. 397 If Other information in this message is not mentioned in 398 the use profile, there is none and this portion of the 399 wrapped information is null. If a use profile specifies 400 Other information it must be possible to determine its 401 length so that following fields can be properly parsed and 402 so that the size of the Key field can be deduced; for 403 example, it could begin with a length byte. 405 Lifetime - A 2-byte unsigned integer. After that number of 406 seconds plus one second, the key and associated information 407 being set MUST be discarded. Unless otherwise specified for 408 a particular use profile of this group keying protocol, the 409 default Lifetime is 15,000 seconds or a little over four 410 hours. 412 KeyID2 Length, KeyID2 - KeyID2 identifies the group key and 413 associated information being set as further specified in 414 the use profile. KeyID2 Length is an unsigned byte that 415 gives the length of KeyID2 in bytes. 417 CypherSuiteLng, CypherSuite - CypherSuite identifies the cypher 418 suite associated with the key being set as further 419 specified in the use profile. CypherSuite Length is an 420 unsigned byte the gives the length of CypherSuite in bytes. 422 Key - This is the actually group shared secret keying material 423 being set. Its length is deduced from the overall length of 424 the vector of fields (found by the AES unwrap operation) 425 and the length of the preceding fields. 427 If GKs already has a dynamic key set under KeyID2, the key's value 428 and associated cypher suite are compared with those in the Set Key 429 messages. If they are the same, the only receiver action is to update 430 the Lifetime information associated with KeyID2 and send a Response 431 message. If they are different, the lifetime, cypher suite, and key 432 (and possibly Other material) are replaced, the use flag is cleared, 433 and a Response message sent. 435 2.7 Use, Delete, Disuse, or Deleted Key Messages 437 The structure of the wrapped material for the Use Key, Delete Key, 438 and Disuse Key keying messages are the same as each other except for 439 the message type. This structure is shown in Figure 2.3 440 +-+-+-+-+-+-+-+-+ 441 | Msg Type = t | 1 byte 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Msg ID 3 bytes | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Pad2 Length | 1 bytes 446 +-+-+-+-+-+-+-+-+... 447 | Padding Pad2 Length bytes 448 +-+-+-+-+-+-+-+-+... 449 | Other Variable size 450 +-+-+-+-+-+-+-+-+... 451 | KeyID2 Length | 1 byte 452 +-+-+-+-+-+-+-+-+ 453 | KeyID2 ... KeyID2 bytes 454 +-+-+-+-+-+-+-+-+ 456 Figure 2.3. Use, Delete, Disuse, or Deleted Key Message 458 The Msg Type field specifies the particular message as follows: 460 Msg Type Message 461 -------- ---------- 462 2 Use Key 463 3 Delete Key 464 4 Disuse Key 465 5 Deleted Key 467 The remaining fields are as specified in Section 2.4. KeyID2 468 indicates the key to be used, deleted, for which use should cease, or 469 which has been deleted, depending on the message type. 471 It is RECOMMENDED that these messages be padded so as to be the same 472 length as a typical Set Key message. 474 The Delete Key is sent by a station believing itself to be GKd 475 instructing some GKs to delete a key. When a GKs spontaneously 476 deletes a key, it sends a Deleted Key message to the station from 477 which it received the key. The message types for Delete Key and 478 Deleted Key are different to minimize confusion in corner cases such 479 as the GKd changing while messages are in flight. The Msg ID used in 480 a Deleted Key message is created by the sending GKs from a space of 481 Msg IDs associated with that GKs which is independent of the Msg IDs 482 used in requests originated by GKd. 484 2.8 Response Message 486 The structure of the wrapped material for the Response group keying 487 message is as show below in Figure 2.4. A response message is 488 indicated by the R bit in the first byte of the message outside the 489 key wrapping. 491 A response MUST NOT be sent due to the receipt of a response. The R 492 bit is outside of the key wrapping so that this rule can be enforced 493 even in cases of difficulty in unwrapping. 495 +-+-+-+-+-+-+-+-+ 496 | Msg Type = n | 1 byte 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Msg ID 3 bytes | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Pad2 Length | 1 bytes 501 +-+-+-+-+-+-+-+-+... 502 | Padding Pad2 Length bytes 503 +-+-+-+-+-+-+-+-+... 504 | Other Variable size 505 +-+-+-+-+-+-+-+-+... 506 | Response Code | 1 byte 507 +-+-+-+-+-+-+-+-+ 508 | ReqPartLength | 1 byte 509 +-+-+-+-+-+-+-+-+... 510 | Request Part ReqPartLenth bytes 511 +-+-+-+-+-+-+-+-... 513 Figure 2.4. Response Message Inner Structure 515 Except as specified below, the fields are as specified for the Key 516 Set message. 518 Msg Type, Msg ID - The content of these field is copied from 519 the message in reply to which this Response message is sent 520 unless there is an error that stops the replying station 521 from determining them; in that case the special value zero 522 is used for the Msg Type and Msg ID. Errors where the Msg 523 Type and ID could not be determined are indicated by a 524 Response Code with its high order bit set to one, that is, 525 the 0b1xxxxxxx bit set. 527 Response Code - An unsigned byte giving the response as 528 enumerated in Table 2.2 in Section 2.8.1. Any Response 529 Code other than a success indicates that the receiver took 530 no action on the request other than sending an error 531 Response message. 533 ReqPartLength, Request Part: It is usually usefully to include 534 some or all of the request message in error responses. 535 - If the Response Code high order two bits are zero, the 536 request succeeded and ReqPartLength MUST be set to zero 537 so Request Part will be null. 539 - If the Response Code high order two bits are zero one 540 (0b01xxxxxx), then there was an error in the part of the 541 request inside the AES key wrapping but the unwrap 542 process was successful. ReqPartLength is the length of 543 the request message material included in the Request 544 Part field. The included request material is from the 545 unwrapped vector of fields started with the Msg Type 546 byte. 547 - If the Response Code high order bit is one (the 548 0b1xxxxxxx is set), then there was an error parsing the 549 material outside the AES key wrap or an error in the AES 550 unwrapping process. ReqPartLength is the length of the 551 request message part included in the Request Part field. 552 The included part of the request starts with the first 553 byte of the message (the byte containing the version, 554 response flag, and KeyID1 Length). 556 2.8.1 Response Codes 558 The high order two bits of the Response Code have meaning as shown in 559 Table 2.1. 561 Top 2 Bits Category 562 ---------- ---------- 563 0b00 Success 564 0b01 AES wrap contents 565 0b10/11 Outside of AES wrap contents 567 Response Response 568 Decimal Hex Meaning 569 -------- -------- ---------- 570 0 0x00 Success 571 1 0x01 Success and the key at an existing key ID was 572 changed 573 2-47 0x02-0x2F Unassigned 574 48-63 0x30-0x3F Reserved for special success codes defined in 575 use profiles 576 64 0x40 Malformed inner fields (see Note 2 below) 577 65 0x41 Unknown or zero Msg Type in a request 578 66 0x42 Zero Msg ID in a request 579 68 0x43 Invalid length KeyID2 580 69 0x44 Unknown KeyID2 581 70 0x45 Invalid length CypherSuite 582 71 0x46 Unknown CyperSuite 583 72 0x47 Bad Key (see Note 3 below) 584 73-111 0x49-0x6F Unassigned 585 112-127 0x70-0x7F Reserved for error codes defined in use 586 profiles and related to the AES wrapped 587 contents 588 128 0x80 Malformed message (see Note 1 below) 589 129 0x81 Invalid length KeyID1 590 130 0x82 Unknown KeyID1 591 131 0x83 Unknown Use Type 592 131 0x84 AES unwrap fails test 1, see Section 3 593 [RFC5649] 594 132 0x85 AES unwrap fails test 2, see Section 3 595 [RFC5649] 596 133 0x86 AES unwrap fails test 3, see Section 3 597 [RFC5649] 598 134-175 0x86-0x7F Unassigned 599 176-191 0xB0-0xBF Reserved for error codes defined in use 600 profiles and related to parts of 601 message outside the AES wrap contents 602 192 0xC0 No keys set 603 193 0xC1 Referenced key unknown 604 194 0xC2 Referenced key known but use flag not set 605 195-255 0xC3-0xFF Reserved 607 Response Code Notes: 609 Note 1 Message is too short or too long, AES wrapped material is too 610 short, Padding bytes are not the required value, or similar 611 fundamental message format problems. 613 Note 2 The AES wrapped inner vector of fields is too short or too 614 long, Padding bytes are not the required value, or similar 615 fundamental vector of fields format problems. 617 Note 3 Key is not a valid length for CypherSuite or other internal 618 checks on key (for example, parity bits in a 64 bit DES key 619 (not that you should be using DES)) fail. 621 2.8 No-Op Message 623 The No-Op message is a dummy message intended for use in disguising 624 metadata deducable from keying message transmissions. It requires no 625 response although a recipient can always decided to send a No-Op 626 message to a station from which it has received such a message. The 627 vector of fields inside the AES key wrap is as follows: 629 +-+-+-+-+-+-+-+-+ 630 | Msg Type = 6 | 1 byte 631 +-+-+-+-+-+-+-+-+ 632 | Pad2 Length | 1 bytes 633 +-+-+-+-+-+-+-+-+... 634 | Padding Pad2 Length bytes 635 +-+-+-+-+-+-+-+-... 637 Figure 2.5. No-Op Message Inner Structure 639 The Msg Type is set to 6 to indicate a No-Op message. 641 Pad2 Length and Padding are as specified in Section 2.6. It is 642 RECOMMENDED that Pad2 Length in a No-Op message be such as to make 643 its length the same as the length of a typical Set Key message. 645 2.9 General Security Considerations 647 This section gives some general security considerations of this group 648 keying protocol as distinguished from security considerations of a 649 particular use profile. 651 The method by which the stations in the group discover each other is 652 specified in the group keying use profile. GKd controls group access 653 and generally learns whatever it needs to know about GKs during the 654 pairwise authentication and pairwise keying process. 656 The group keying provided by this protocol is shared secret keying. 657 This means that data messages can only be authenticated as coming 658 from some group member but not as coming from a specific group 659 member. If this level of authentication is insufficient, GKd can 660 simply not set keys or not set them as usable. This will force all 661 stations in the group that are configured to use security for multi- 662 destination transmissions to the group to serial unicast data to the 663 other group members using pairwise keying. 665 The content value of padding fields in the Group Keying protocol is 666 fixed so that it cannot be used as a covert channel. The length of 667 padding could still be so used. 669 3. DTLS: Extended RBridge Channel Group Keyed Security 671 This section specifies a profile of the group keying protocol defined 672 in Section 2. This profile provides shared secret keying to secure 673 multi-destination Extended RBridge Channel messages [RFC7978]. The 674 keys put in place by the group keying protocol are available for use 675 as DTLS pre-shared keys with the DTLS and Composite Security of 676 multi-destination Extended RBridge Channel messages as specified in 677 Section 3.2. 679 For this group keying use profile, a group is identified by TRILL 680 Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable 681 [RFC7780] RBridges with interest in that Data Label. GKd is the 682 RBridge in the group that, of those group members supporting the 683 Group Keying Protocol, is the highest priority to be a TRILL 684 distribution tree root. If not all members of the group support the 685 Group Keying Protocol, then there are two cases for multi-destination 686 Channel Tunnel RBridge Channel messages: 687 (1) If the sender and at least two other group members support the 688 Group Keying Protocol, it SHOULD, for efficiency, send a secured 689 multi-destination RBridge Channel message to cover the group and 690 serially unicast to the group members not supporting the Group 691 Keying Protocol. 692 (2) In other cases the sender serially transmits the data to the 693 group members using pairwise security. 695 3.1 Transmission of Group Keying Messages 697 Keying messages themselves are sent as unicast Extended RBridge 698 Channel messages carrying a Group Keying protocol (see Section 5.2) 699 RBridge Channel message. They MUST use DTLS Pairwise or Composite 700 (STypes 2 or 3) security. 702 The Group Keying profile for this Group Keying Use Type is as 703 follows: 705 Priority of Group Keying messages for this SHOULD be 6 unless the 706 network manager chooses to use a lower priority after 707 determining that such lower priority group keying messages 708 will yield acceptable performance. Priority 7 SHOULD NOT be 709 used as it may cause interference with the establishment and 710 maintenance of adjacency. 712 Use Type = 1 714 KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID. 716 CypherSuiteLng = 2, CypherSuite is the cypher suite used in 717 groupcast extended RBridge Channel data messages for the 718 corresponding KeyID2. This a DTLS [RFC6347] cypher suite. 720 KeyID2 Length = 1, KeyID2 is the index under which a group key is 721 set. Group keys are, in effect, indexed by this KeyID2 and 722 the nickname of the GKd as used in the Ingress Nickname 723 field of the TRILL Header of Group Keying messages. 725 3.2 Transmission of Protected Multi-destination Data 727 Protected Extended RBridge Channel [RFC7978] messages are multicast 728 (M bit set to one in the TRILL Header) and set the SType field to a 729 new value for "Group Secured" (See Section 5.3). The data is 730 formatted as one byte of Key ID followed by data formatted as TLS 1.2 731 [RFC5246] application_data using the cyphersuite and keying material 732 stored under the Key ID. 734 4. TRILL Over IP Group Keyed Security 736 This section specifies a profile of the group keying protocol defined 737 in Section 2. This profile provides shared secret keying to secure 738 TRILL over IP messages [TRILLoverIP]. The keys put in place by the 739 group keying protocol are available for use as IPSEC keys. 741 For this group keying use profile, a group is identified by an IP 742 multicast address and consists of the adjacent [RFC7177] RBridges 743 reachable with that multicast address. GKd is the RBridge in the 744 group that, of those group members supporting the Group Keying 745 Protocol, has the highest priority to be a TRILL distribution tree 746 root. If not all members of the group support the Group Keying 747 Protocol, then there are two cases for multi-destination TRILL over 748 IP messages: 749 (1) If the sender and at least two other group members support the 750 Group Keying Protocol, it SHOULD, for efficiency, send a secured 751 IPSEC message to cover the group and serially unicast to the 752 group members not supporting the Group Keying Protocol. 753 (2) In other cases the sender serially transmits the data to the 754 group members using pairwise security. 756 4.1 Transmission of Group Keying Messages 757 tbd 759 Use Type = 2 761 tbd 763 4.2 Transmission of Protected Multi-destination Data 765 tbd 767 5. IANA Considerations 769 This section gives IANA Considerations. 771 5.1 Group Keying Protocol 773 IANA is requested to perform the following actions: 775 1. Establish a protocol parameters web page for "Group Keying 776 Protocol Parameters" with the initial registries on that page 777 as specified below in this section. 779 2. Establish a "Message Type" registry on the Group Keying 780 Protocol Parameters page as follows: 782 Registration Procedure: IETF Review 784 Reference: [this document] 786 Type Description Reference 787 ------- ----------- --------------- 788 0 Reserved [This document] 789 1 Set Key [This document] 790 2 Use Key [This document] 791 3 Delete Key [This document] 792 4 Disuse Key [This document] 793 5 Deleted Key [This document] 794 6 No-Op [This document] 795 7-250 Unassigned 796 251-254 Reserved for Private Use [This document] 797 255 Reserved [This document] 799 3. Establish a "Group Keying Use Profile" registry on the Group 800 Keying Protocol Parameters page as follows: 802 Registration Procedure: IETF Review 804 Reference: [This document] 806 Profile Description Reference 807 --------- ----------- --------- 808 0 Reserved [This document] 809 1 Extended RBridge Channel [This document] 810 2 TRILL over IP [This document] 811 3-250 Unassigned 812 251-254 Reserved for Private Use [This document] 813 255 Reserved [This document] 815 4. Establish a "Response Code" registry on the Group Keying 816 Protocol Parameters page as show below taking entries from the 817 Response Code table in Section 2.8.1 above. In the table of 818 values, the Reference column should be "[This document]" except 819 where the Meaning is "Unassigned" or "Reserved". 821 Registration Procedure: IETF Review 823 Reference: [This document] 825 Note: The top two bits of the Response Code indicate a category 826 as specified in Section 2.8.1 of [this document]. 828 Response Response 829 Decimal Hex Meaning Reference 830 -------- --------- ----------- --------- 831 0 0x00 Success [this document] 832 ... ... ... 833 255 0xFF Reserved 835 5.2 Group Keying RBridge Channel Protocol Numbers 837 IANA is requested to assign TBD1 as the TRILL RBridge Channel 838 protocol number, from the range assigned by Standards Action, for use 839 when the "Group Keying" protocol is transmitted over Extended RBridge 840 Channel messages. 842 The added RBridge Channel protocols registry entry on the TRILL 843 Parameters web page is as follows: 845 Protocol Description Reference 846 -------- -------------- ------------------ 847 TBD1 Group Keying Section 2 of [this document] 849 5.3 Group Secured Extended RBridge Channel SType 851 IANA is requested to assign TBD2 as the Group Secured SType in the 852 "Extended RBridge Channel Security Types Subregistry" on the TRILL 853 Parameters web page as follows: 855 SType Description Reference 856 ----- ------------- ---------- 857 TBD2 Group Secured Section 3.2 of [this document] 859 6. Security Considerations 861 TBD 863 See [RFC7978] for Extended RBridge Channel security. 865 See [RFC7457] in connection with TLS and DTLS security. 867 Normative References 869 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 871 March 1997, . 873 [RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard 874 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 875 September 2002, . 877 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 878 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 879 . 881 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 882 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 883 5310, DOI 10.17487/RFC5310, February 2009, . 886 [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard 887 (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 888 10.17487/RFC5649, September 2009, . 891 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 892 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 893 . 895 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 896 Ghanwani, "Routing Bridges (RBridges): Base Protocol 897 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 898 . 900 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 901 Security Version 1.2", RFC 6347, January 2012, . 904 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 905 and D. Dutt, "Transparent Interconnection of Lots of Links 906 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 907 10.17487/RFC7172, May 2014, . 910 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 911 D., and A. Banerjee, "Transparent Interconnection of Lots of 912 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 913 . 915 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 916 and V. Manral, "Transparent Interconnection of Lots of Links 917 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 918 . 920 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 921 Ward, "Transparent Interconnection of Lots of Links (TRILL): 922 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 923 2014, . 925 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 926 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 927 Lots of Links (TRILL): Clarifications, Corrections, and 928 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 929 . 931 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 932 Interconnection of Lots of Links (TRILL): RBridge Channel 933 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 934 2016, . 936 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 937 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 938 2017, . 940 [TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang, 941 "Transparent Interconnection of Lots of Links (TRILL) over IP", 942 draft-ietf-trill-over-ip, work in progress. 944 Informative References 946 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 947 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 948 10.17487/RFC6234, May 2011, . 951 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 952 Known Attacks on Transport Layer Security (TLS) and Datagram 953 TLS (DTLS)", RFC 7457, February 2015, . 956 Acknowledgements 958 The contributions of the following are hereby gratefully 959 acknowledged: 961 TBD 963 The document was prepared in raw nroff. All macros used were defined 964 within the source file. 966 Authors' Addresses 968 Donald E. Eastlake, 3rd 969 Huawei Technologies 970 155 Beaver Street 971 Milford, MA 01757 USA 973 Phone: +1-508-333-2270 974 EMail: d3e3e3@gmail.com 976 Dacheng Zhang 977 Huawei Technologies 979 Email: dacheng.zhang@huawei.com 981 Copyright, Disclaimer, and Additional IPR Provisions 983 Copyright (c) 2017 IETF Trust and the persons identified as the 984 document authors. All rights reserved. 986 This document is subject to BCP 78 and the IETF Trust's Legal 987 Provisions Relating to IETF Documents 988 (http://trustee.ietf.org/license-info) in effect on the date of 989 publication of this document. Please review these documents 990 carefully, as they describe your rights and restrictions with respect 991 to this document. Code Components extracted from this document must 992 include Simplified BSD License text as described in Section 4.e of 993 the Trust Legal Provisions and are provided without warranty as 994 described in the Simplified BSD License. The definitive version of 995 an IETF Document is that published by, or under the auspices of, the 996 IETF. Versions of IETF Documents that are published by third parties, 997 including those that are translated into other languages, should not 998 be considered to be definitive versions of IETF Documents. The 999 definitive version of these Legal Provisions is that published by, or 1000 under the auspices of, the IETF. Versions of these Legal Provisions 1001 that are published by third parties, including those that are 1002 translated into other languages, should not be considered to be 1003 definitive versions of these Legal Provisions. For the avoidance of 1004 doubt, each Contributor to the IETF Standards Process licenses each 1005 Contribution that he or she makes as part of the IETF Standards 1006 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1007 language to the contrary, or terms, conditions or rights that differ 1008 from or are inconsistent with the rights and licenses granted under 1009 RFC 5378, shall have any effect and shall be null and void, whether 1010 published or posted by such Contributor, or included with or in such 1011 Contribution.