idnits 2.17.1 draft-eastlake-trill-group-keying-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2017) is 2501 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 Huawei 3 Expires: December 19, 2017 June 20, 2017 5 A Group Keying Protocol 6 8 Abstract 10 This document specifies a general group keying protocol. It also 11 provides use profiles for the application of this group keying 12 protocol to multi-destination TRILL Extended RBridge Channel message 13 security and TRILL over IP packet security. 15 Status of This Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Distribution of this document is unlimited. Comments should be sent 21 to the authors or the TRILL working group mailing list: 22 trill@ietf.org. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 36 Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Table of Contents 41 1. Introduction............................................3 42 1.1 Terminology and Acronyms..............................3 44 2. Group Keying Protocol...................................5 45 2.1 Assumptions............................................5 46 2.2 Group Keying Procedure Overview........................5 47 2.3 Transmission and Receipt of Group Data Messages........6 48 2.4 Changes in Group Membership or GKd.....................6 49 2.5 Group Keying Messages..................................7 50 2.6 Set Key Message........................................9 51 2.7 Use, Delete, Disuse, or Deleted Key Messages..........11 52 2.8 Response Message......................................12 53 2.8.1 Response Codes......................................14 54 2.8 No-Op Message.........................................15 55 2.9 General Security Considerations.......................16 57 3. DTLS: Extended RBridge Channel Group Keyed Security....17 58 3.1 Transmission of Group Keying Messages.................17 59 3.2 Transmission of Protected Multi-destination Data......18 61 4. TRILL Over IP Group Keyed Security.....................19 62 4.1 Transmission of Group Keying Messages.................19 63 4.2 Transmission of Protected Multi-destination Data......19 65 5. IANA Considerations....................................20 66 5.1 Group Keying Protocol.................................20 67 5.2 Group Keying RBridge Channel Protocol Numbers.........21 68 5.3 Group Secured Extended RBridge Channel SType..........21 70 6. Security Considerations................................22 72 Normative References......................................23 73 Informative References....................................24 75 Acknowledgements..........................................25 76 Authors' Addresses........................................26 78 1. Introduction 80 This document specifies a general group keying protocol in Section 2. 81 In addition, it provides, in Section 3, the use profile for the 82 application of this group keying protocol to a case using DTLS (TRILL 83 [RFC6325] [RFC7780] Extended RBridge Channel message security 84 [RFC7178] [RFC7978]) and IPsec [TRILLoverIP}. It is anticipated that 85 there will be other uses for this group keying protocol. 87 1.1 Terminology and Acronyms 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119] [RFC8174] 92 when, and only when, they appear in all capitals, as shown here. 94 This document uses terminology and acronyms defined in [RFC6325] and 95 [RFC7178]. Some of these are repeated below for convenience along 96 with additional new terms and acronyms. 98 AES - Advanced Encryption Standard. 100 Data Label - VLAN or FGL. 102 DTLS - Datagram Transport Level Security [RFC6347]. 104 FGL - Fine Grained Label [RFC7172]. 106 GKd - A distinguished station in a group that is in charge of 107 which group keying (Section 2) is in use. 109 GKs - Stations in a group other than GKd (Section 2). 111 HKDF - Hash based Key Derivation Function [RFC5869]. 113 IS-IS - Intermediate System to Intermediate System [RFC7176]. 115 keying material - The set of a Key ID, a secret key, and a cypher 116 suite. 118 PDU - Protocol Data Unit. 120 QoS - Quality of Service. 122 RBridge - An alternative term for a TRILL switch. 124 SHA - Secure Hash Algorithm [RFC6234]. 126 TRILL - Transparent Interconnection of Lots of Links or Tunneled 127 Routing in the Link Layer. 129 TRILL switch - A device that implements the TRILL protocol 130 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 132 2. Group Keying Protocol 134 This section defines a general Group Keying Protocol that provides 135 shared secret group keys. Any particular use of this protocol will 136 require profiling giving further details and specifics for that use. 137 The protocol is not suitable for discovery messages but is intended 138 for use between members of a group that have already established 139 pair-wise security. 141 2.1 Assumptions 143 The following are assumed: 144 - All pairs of stations in the group can engage in pairwise 145 communication with unicast messages and each can groupcast a 146 message to the other group members. 147 - At any particular time, there is a distinguished station GKd in 148 the group that is in charge of keying for the groupcast data 149 messages to be sent to the group. The group wide shared secret 150 keys established by GKd are referred to herein as "dynamic" 151 keys. 152 - Pairwise keying has been negotiated between GKd and each other 153 station GKs1, GKs2, ... GKsN in the group. These keys are 154 referred to in this protocol as "pairwise" keys. 155 - One or more keys, other than the dynamic or pairwise keys, each 156 of which is already in place at all group member stations. These 157 are referred to as "stable" keys. 159 When keying material is stored by a station, it is accompanied by a 160 "use flag" indicating whether or not that keying material is usable 161 for groupcast transmissions. 163 2.2 Group Keying Procedure Overview 165 GKd sends unicast keying messages to the other stations in the group 166 and they respond as specified below and in further detail in the 167 particular use profiles for this Group Keying Protocol. All such 168 keying messages MUST be encrypted and authenticated using the 169 pairwise keys as further specified in the use profile. 171 Typically, GKd sends a keying message to each GKs with keying 172 material. After successful acknowledgement of receipt from each GKs, 173 GKd sends a keying message to each GKs instructing it to use the 174 dynamic key GKd has set. It would be common for GKd to set a new 175 dynamic key at each GKs while an older dynamic key is in use so that 176 GKd can more promptly roll over to the new key when appropriate. 178 To avoid an indefinite build up of keying material at a GKs, keys 179 have a lifetime specified by GKd and GKd can send a message deleting 180 a key. (GKd can also send a message indicating that a key is no 181 longer to be used but leaving it set.) Should the space available at 182 a GKs for keying material be exhausted, on receipt of a Set Key 183 keying message for a new key ID GKs discards a dynamic key it has and 184 originates a Delete Key message to the source of that dynamic key. 186 2.3 Transmission and Receipt of Group Data Messages 188 If a group has only two members, then pairwise security is used 189 between them. 191 When a group has more than two members and a station in the group 192 transmits a data message to the group, if the transmitter has one or 193 more keys set by GKd that it has been instructed to use, it uses one 194 of those keys and its associated cypher suite to groupcast the data 195 message. If it has no such key, then it uses serial unicast to send 196 the data message to each other member of the group, negotiating 197 pairwise keys with them if it does not already have such pairwise 198 keys. Thus it is a responsibility of GKd not to authorize the use of 199 a groupcast key until it knows that all the GKs have that key. 201 When a station in the group receives data that has been groupcast to 202 the group, if the receiver has the key referenced by the data message 203 the receiver decrypts and verifies it. If verification fails or if 204 the receiver does not have the required key, the receiver discards 205 the data message. Thus whether GKs has been directed to "use" a key 206 by GKd is relevant only to transmission, not reception. 208 2.4 Changes in Group Membership or GKd 210 When a new station joins the group, GKd should send that station the 211 currently in-use group key and instruct it to use that key and send 212 it other keys known to the group members and intended for future use. 214 If GKd detects that one or more stations that were members of the 215 group are no longer members of the group, it SHOULD generate and 216 distribute a new group key to the remaining group members, instruct 217 them to use this new key, and delete from them any old keys known to 218 the departed group member station(s) or at least instructing them to 219 disuse such old keys that are marked for use; however, in the case of 220 groups with large and/or highly dynamic membership, where a station 221 might frequently leave and then rejoin, it may, as a practical 222 matter, be necessary to rekey less frequently. 224 A new group member can become GKd due to the previous GKd leaving the 225 group or a configuration change or the like. A GKs MUST NOT use 226 keying material set by a station that it determines is not GKd. To 227 avoid a gap in service, a station that is not GKd MAY set keying 228 material at other stations in the group; however, such a non-GKd 229 station cannot set the use flag for any such keying material. It is 230 RECOMENDED that the second highest priority station to be GKd set 231 such keying material at all other stations in the group. Should a 232 station run out of room for keying material, it SHOULD discard keying 233 material set by a station with lower priority to be GKd before 234 discarding keying material set by a higher priority station and among 235 keys set by GKd is SHOULD discard the lest recently used first. 237 2.5 Group Keying Messages 239 Keying messages start with a Version number. This document specifies 240 Version zero. 242 Keying messages are structured as 243 o a Version number, 244 o a Response flag, 245 o a Key ID length, 246 o the Key ID of a stable key, 247 o a group keying use profile identifier, 248 o possible padding, and finally 249 o an AES key wrapped [RFC5649] [RFC3394] vector of additional 250 fields wrapped using the stable key identified and using 251 AES-256, as shown in Figure 2.1 below. 253 Keying messages are always sent unicast and encrypted and 254 authenticated with the appropriate pairwise key, all as further 255 specified for the particular use profile. It will typically be 256 possible for GKd to calculate the keying message once, including the 257 AES wrapping under a stable key, then send that message to various 258 GKs using the different pairwise keys for each GKs. 260 +-+-+-+-+-+-+-+-+ 261 |Ver|R|KeyID1Lng| 1 byte 262 +-+-+-+-+-+-+-+-+... 263 | KeyID1 ... KeyID1Lngth bytes 264 +-+-+-+-+-+-+-+-+... 265 | Use Type | 1 byte 266 +-+-+-+-+-+-+-+-+ 267 | Pad1 Length | 1 byte 268 +-+-+-+-+-+-+-+-+... 269 | Padding Pad1 Length bytes 270 +-+-+-+-+-+-+-+-+... 271 |AES Wrap Length| 1 byte 272 +-+-+-+-+-+-+-+-+... 273 | 274 | AES Wrapped Material Variable size 275 | 276 +-+-+-+-+-+-+-+-... 278 Figure 2.1. Keying Message Structure 280 The fields in Figure 2.1 are as follows: 282 Ver - Group Keying protocol version. This document specifies 283 version zero. 285 R - Response flag. If set to one, indicates a response message. 286 If set to zero, indicated a request or no-op message. 288 KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key 289 wrapping key (also known as the Key Encrypting Key (KEK)) 290 as further specified in the use profile. KeyID1Lngth is a 291 5-bit field that gives the length of KeyID1 in bytes as an 292 unsigned integer. 294 Use Type - Specifies the particular group security use profile 295 such as RBridge Extension (Section 3) or IP link 296 [TRILLoverIP]. 298 Pad1 Length, Pad1 - Padding to obscure the non-padded message 299 size. Pad1 Length may be from 0 to 255 and gives the length 300 of the padding as an unsigned integer. Each byte of padding 301 MUST be equal to Pad1 Length. For example, 3 bytes of 302 padding with length is 0x03030303. 304 AES Wrap Length - An unsigned byte that gives the length of the 305 AES Wrapped Material in units of 8 bytes. The length of AES 306 key wrapped material is, as specified in [RFC5649], always 307 a multiple of 8 bytes (64 bits) and not less than 16 bytes. 308 Thus an AES Wrap Length of 0 or 1 is invalid. 310 AES Wrapped Material - The output of the AES Key Wrapping 311 operation on the message vector of fields using the 312 specified stable key. 314 The vector of fields contained within the AES-256 key wrapping is 315 specified for the various keying messages in subsections below. The 316 contents of this wrapped vector are protected by the AES wrapping as 317 well as being authenticated and super-encrypted by the pairwise keyed 318 security used for sending the overall keying message. The stable key 319 used for AES wrapping MUST be different from the outer message 320 pairwise key. 322 Each group keying message contains, in the AES wrapped vector of 323 fields, a message type and a message ID set by the sender of a 324 request. These fields are returned in the corresponding response to 325 assist in the matching of response to requests, except that there is 326 no response to the No-Op message. 328 If no response is received to a request (other than a No-Op message) 329 for an amount of time configurable in milliseconds from 1 to ( 2**15 330 - 1 ), the request is re-transmitted with the same message ID. These 331 retries can occur up to a configurable number of times from 1 to 8. 332 Unless otherwise provided in the particular use profile, the default 333 response delay threshold is 200 milliseconds and the default maximum 334 number of retries is 3. 336 Keying messages are sent with a priority/QoS configurable on a per 337 device per use type basis. The default priority/QoS is specified in 338 the use profile. 340 Since the minimum length of the AES Wrapped Material is 16 bytes 341 [RFC5649], the minimum valid size of a keying message is 20 bytes, 342 even if KeyID1 Length and Pad1 Length are zero. All multi-byte fields 343 are in network order, that is, with the most significant byte first. 345 2.6 Set Key Message 347 The structure of the wrapped vector of fields for the Set Key keying 348 message is as show in Figure 2.2. A recipient automatically 349 determines the overall length provided for this vector of fields 350 inside the AES wrapping as a byproduct of the process of AES 351 unwrapping [RFC5649]. 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 2.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 unapdded 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, it 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 AES unwrap operation) 424 and the length of the preceding fields. 426 If GKs already has a dynamic key set under KeyID2, the key's value 427 and associated cypher suite are compared with those in the Set Key 428 messages. If they are the same, the only receiver action is to update 429 the Lifetime information associated with KeyID2 and send a Response 430 message. If they are different, the lifetime, cypher suite, and key 431 (and possibly Other material) are replaced, the use flag is cleared, 432 and a Response message sent. 434 2.7 Use, Delete, Disuse, or Deleted Key Messages 436 The structure of the wrapped material for the Use Key, Delete Key, 437 and Disuse Key keying messages are the same as each other except for 438 the message type. This structure is shown in Figure 2.3 439 +-+-+-+-+-+-+-+-+ 440 | Msg Type = t | 1 byte 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Msg ID 3 bytes | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Pad2 Length | 1 bytes 445 +-+-+-+-+-+-+-+-+... 446 | Padding Pad2 Length bytes 447 +-+-+-+-+-+-+-+-+... 448 | Other Variable size 449 +-+-+-+-+-+-+-+-+... 450 | KeyID2 Length | 1 byte 451 +-+-+-+-+-+-+-+-+ 452 | KeyID2 ... KeyID2 bytes 453 +-+-+-+-+-+-+-+-+ 455 Figure 2.3. Use, Delete, Disuse, or Deleted Key Message 457 The Msg Type field specifies the particular message as follows: 459 Msg Type Message 460 -------- ---------- 461 2 Use Key 462 3 Delete Key 463 4 Disuse Key 464 5 Deleted Key 466 The remaining fields are as specified in Section 2.4. KeyID2 467 indicates the key to be used, deleted, for which use should cease, or 468 which has been deleted, depending on the message type. 470 It is RECOMMENDED that these messages be padded so as to be the same 471 length as a typical Set Key message. 473 The Delete Key is sent by a station believing itself to be GKd 474 instructing some GKs to delete a key. When a GKs spontaneously 475 deletes a key, it sends a Deleted Key message to the station from 476 which it received the key. The message types for Delete Key and 477 Deleted Key are different to minimize confusion in corner cases such 478 as the GKd changing while messages are in flight. The Msg ID used in 479 a Deleted Key message is created by the sending GKs from a space of 480 Msg IDs associated with that GKs which is independent of the Msg IDs 481 used in requests originated by GKd. 483 2.8 Response Message 485 The structure of the wrapped material for the Response group keying 486 message is as show below in Figure 2.4. A response message is 487 indicated by the R bit in the first byte of the message outside the 488 key wrapping. 490 A response MUST NOT be sent due to the receipt of a response. The R 491 bit is outside of the key wrapping so that this rule can be enforced 492 even in cases of difficulty in unwrapping. 494 +-+-+-+-+-+-+-+-+ 495 | Msg Type = n | 1 byte 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Msg ID 3 bytes | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Pad2 Length | 1 bytes 500 +-+-+-+-+-+-+-+-+... 501 | Padding Pad2 Length bytes 502 +-+-+-+-+-+-+-+-+... 503 | Other Variable size 504 +-+-+-+-+-+-+-+-+... 505 | Response Code | 1 byte 506 +-+-+-+-+-+-+-+-+ 507 | ReqPartLength | 1 byte 508 +-+-+-+-+-+-+-+-+... 509 | Request Part ReqPartLenth bytes 510 +-+-+-+-+-+-+-+-... 512 Figure 2.4. Response Message Inner Structure 514 Except as specified below, the fields are as specified for the Key 515 Set message. 517 Msg Type, Msg ID - The content of these field is copied from 518 the message in reply to which this Response message is sent 519 unless there is an error that stops the replying station 520 from determining them; in that case the special value zero 521 is used for the Msg Type and Msg ID. Errors where the Msg 522 Type and ID could not be determined are indicated by a 523 Response Code with its high order bit set to one, that is, 524 the 0b1xxxxxxx bit set. 526 Response Code - An unsigned byte giving the response as 527 enumerated in Table 2.2 in Section 2.8.1. Any Response 528 Code other than a success indicates that the receiver took 529 no action on the request other than sending an error 530 Response message. 532 ReqPartLength, Request Part: It is usually usefully to include 533 some or all of the request message in error responses. 534 - If the Response Code high order two bits are zero, the 535 request succeeded and ReqPartLength MUST be set to zero 536 so Request Part will be null. 538 - If the Response Code high order two bits are zero one 539 (0b01xxxxxx), then there was an error in the part of the 540 request inside the AES key wrapping but the unwrap 541 process was successful. ReqPartLength is the length of 542 the request message material included in the Request 543 Part field. The included request material is from the 544 unwrapped vector of fields started with the Msg Type 545 byte. 546 - If the Response Code high order bit is one (the 547 0b1xxxxxxx is set), then there was an error parsing the 548 material outside the AES key wrap or an error in the AES 549 unwrapping process. ReqPartLength is the length of the 550 request message part included in the Request Part field. 551 The included part of the request starts with the first 552 byte of the message (the byte containing the version, 553 response flag, and KeyID1 Length). 555 2.8.1 Response Codes 557 The high order two bits of the Response Code have meaning as shown in 558 Table 2.1. 560 Top 2 Bits Category 561 ---------- ---------- 562 0b00 Success 563 0b01 AES wrap contents 564 0b10/11 Outside of AES wrap contents 566 Response Response 567 Decimal Hex Meaning 568 -------- -------- ---------- 569 0 0x00 Success 570 1 0x01 Success and the key at an existing key ID was 571 changed 572 2-47 0x02-0x2F Unassigned 573 48-63 0x30-0x3F Reserved for special success codes defined in 574 use profiles 575 64 0x40 Malformed inner fields (see Note 2 below) 576 65 0x41 Unknown or zero Msg Type in a request 577 66 0x42 Zero Msg ID in a request 578 68 0x43 Invalid length KeyID2 579 69 0x44 Unknown KeyID2 580 70 0x45 Invalid length CypherSuite 581 71 0x46 Unknown CyperSuite 582 72 0x47 Bad Key (see Note 3 below) 583 73-111 0x49-0x6F Unassigned 584 112-127 0x70-0x7F Reserved for error codes defined in use 585 profiles and related to the AES wrapped 586 contents 587 128 0x80 Malformed message (see Note 1 below) 588 129 0x81 Invalid length KeyID1 589 130 0x82 Unknown KeyID1 590 131 0x83 Unknown Use Type 591 131 0x84 AES unwrap fails test 1, see Section 3 592 [RFC5649] 593 132 0x85 AES unwrap fails test 2, see Section 3 594 [RFC5649] 595 133 0x86 AES unwrap fails test 3, see Section 3 596 [RFC5649] 597 134-175 0x86-0x7F Unassigned 598 176-191 0xB0-0xBF Reserved for error codes defined in use 599 profiles and related to parts of 600 message outside the AES wrap contents 601 192 0xC0 No keys set 602 193 0xC1 Referenced key unknown 603 194 0xC2 Referenced key known but use flag not set 604 195-255 0xC3-0xFF Reserved 606 Response Code Notes: 608 Note 1 Message is too short or too long, AES wrapped material is too 609 short, Padding bytes are not the required value, or similar 610 fundamental message format problems. 612 Note 2 The AES wrapped inner vector of fields is too short or too 613 long, Padding bytes are not the required value, or similar 614 fundamental vector of fields format problems. 616 Note 3 Key is not a valid length for CypherSuite or other internal 617 checks on key (for example, parity bits in a 64 bit DES key 618 (not that you should be using DES)) fail. 620 2.8 No-Op Message 622 The No-Op message is a dummy message intended for use in disguising 623 metadata deducable from keying message transmissions. It requires no 624 response although a recipient can always decided to send a No-Op 625 message to a station from which it has received such a message. The 626 vector of fields inside the AES key wrap is as follows: 628 +-+-+-+-+-+-+-+-+ 629 | Msg Type = 6 | 1 byte 630 +-+-+-+-+-+-+-+-+ 631 | Pad2 Length | 1 bytes 632 +-+-+-+-+-+-+-+-+... 633 | Padding Pad2 Length bytes 634 +-+-+-+-+-+-+-+-... 636 Figure 2.5. No-Op Message Inner Structure 638 The Msg Type is set to 6 to indicate a No-Op message. 640 Pad2 Length and Padding are as specified in Section 2.6. It is 641 RECOMMENDED that Pad2 Length in a No-Op message be such as to make 642 its length the same as the length of a typical Set Key message. 644 2.9 General Security Considerations 646 This section gives some general security considerations of this group 647 keying protocol as distinguished from security considerations of a 648 particular use profile. 650 The method by which the stations in the group discover each other is 651 specified in the group keying use profile. GKd controls group access 652 and generally learns whatever it needs to know about GKs during the 653 pairwise authentication and pairwise keying process. 655 The group keying provided by this protocol is shared secret keying. 656 This means that data messages can only be authenticated as coming 657 from some group member but not as coming from a specific group 658 member. If this level of authentication is insufficient, GKd can 659 simply not set keys or not set them as usable. This will force all 660 stations in the group that are configured to use security for multi- 661 destination transmissions to the group to serial unicast data to the 662 other group members using pairwise keying. 664 The content value of padding fields in the Group Keying protocol is 665 fixed so that it cannot be used as a covert channel. The length of 666 padding could still be so used. 668 3. DTLS: Extended RBridge Channel Group Keyed Security 670 This section specifies a profile of the group keying protocol defined 671 in Section 2. This profile provides shared secret keying to secure 672 multi-destination Extended RBridge Channel messages [RFC7978]. The 673 keys put in place by the group keying protocol are available for use 674 as DTLS pre-shared keys with the DTLS and Composite Security of 675 multi-destination Extended RBridge Channel messages as specified in 676 Section 3.2. 678 For this group keying use profile, a group is identified by TRILL 679 Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable 680 [RFC7780] RBridges with interest in that Data Label. GKd is the 681 RBridge in the group that, of those group members supporting the 682 Group Keying Protocol, is the highest priority to be a TRILL 683 distribution tree root. If not all members of the group support the 684 Group Keying Protocol, then there are two cases for multi-destination 685 Channel Tunnel RBridge Channel messages: 686 (1) If the sender and at least two other group members support the 687 Group Keying Protocol, it SHOULD, for efficiency, send a secured 688 multi-destination RBridge Channel message to cover the group and 689 serially unicast to the group members not supporting the Group 690 Keying Protocol. 691 (2) In other cases the sender serially transmits the data to the 692 group members using pairwise security. 694 3.1 Transmission of Group Keying Messages 696 Keying messages themselves are sent as unicast Extended RBridge 697 Channel messages carrying a Group Keying protocol (see Section 5.2) 698 RBridge Channel message. They MUST use DTLS Pairwise or Composite 699 (STypes 2 or 3) security. 701 The Group Keying profile for this Group Keying Use Type is as 702 follows: 704 Priority of Group Keying messages for this SHOULD be 6 unless the 705 network manager chooses to use a lower priority after 706 determining that such lower priority group keying messages 707 will yield acceptable performance. Priority 7 SHOULD NOT be 708 used as it may cause interference with the establishment and 709 maintenance of adjacency. 711 Use Type = 1 713 KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID. 715 CypherSuiteLng = 2, CypherSuite is the cypher suite used in 716 groupcast extended RBridge Channel data messages for the 717 corresponding KeyID2. This a DTLS [RFC6347] cypher suite. 719 KeyID2 Length = 1, KeyID2 is the index under which a group key is 720 set. Group keys are, in effect, indexed by this KeyID2 and 721 the nickname of the GKd as used in the Ingress Nickname 722 field of the TRILL Header of Group Keying messages. 724 3.2 Transmission of Protected Multi-destination Data 726 Protected Extended RBridge Channel [RFC7978] messages are multicast 727 (M bit set to one in the TRILL Header) and set the SType field to a 728 new value for "Group Secured" (See Section 5.3). The data is 729 formatted as one byte of Key ID followed by data formatted as TLS 1.2 730 [RFC5246] application_data using the cyphersuite and keying material 731 stored under the Key ID. 733 4. TRILL Over IP Group Keyed Security 735 This section specifies a profile of the group keying protocol defined 736 in Section 2. This profile provides shared secret keying to secure 737 TRILL over IP messages [TRILLoverIP]. The keys put in place by the 738 group keying protocol are available for use as IPSEC keys. 740 For this group keying use profile, a group is identified by an IP 741 multicast address and consists of the adjacent [RFC7177] RBridges 742 reachable with that multicast address. GKd is the RBridge in the 743 group that, of those group members supporting the Group Keying 744 Protocol, has the highest priority to be a TRILL distribution tree 745 root. If not all members of the group support the Group Keying 746 Protocol, then there are two cases for multi-destination TRILL over 747 IP messages: 748 (1) If the sender and at least two other group members support the 749 Group Keying Protocol, it SHOULD, for efficiency, send a secured 750 IPSEC message to cover the group and serially unicast to the 751 group members not supporting the Group Keying Protocol. 752 (2) In other cases the sender serially transmits the data to the 753 group members using pairwise security. 755 4.1 Transmission of Group Keying Messages 756 tbd 758 Use Type = 2 760 tbd 762 4.2 Transmission of Protected Multi-destination Data 764 tbd 766 5. IANA Considerations 768 This section gives IANA Considerations. 770 5.1 Group Keying Protocol 772 IANA is requested to perform the following actions: 774 1. Establish a protocol parameters web page for "Group Keying 775 Protocol Parameters" with the initial registries on that page 776 as specified below in this section. 778 2. Establish a "Message Type" registry on the Group Keying 779 Protocol Parameters page as follows: 781 Registration Procedure: IETF Review 783 Reference: [this document] 785 Type Description Reference 786 ------- ----------- --------------- 787 0 Reserved [This document] 788 1 Set Key [This document] 789 2 Use Key [This document] 790 3 Delete Key [This document] 791 4 Disuse Key [This document] 792 5 Deleted Key [This document] 793 6 No-Op [This document] 794 7-250 Unassigned 795 251-254 Reserved for Private Use [This document] 796 255 Reserved [This document] 798 3. Establish a "Group Keying Use Profile" registry on the Group 799 Keying Protocol Parameters page as follows: 801 Registration Procedure: IETF Review 803 Reference: [This document] 805 Profile Description Reference 806 --------- ----------- --------- 807 0 Reserved [This document] 808 1 Extended RBridge Channel [This document] 809 2 TRILL over IP [This document] 810 3-250 Unassigned 811 251-254 Reserved for Private Use [This document] 812 255 Reserved [This document] 814 4. Establish a "Response Code" registry on the Group Keying 815 Protocol Parameters page as show below taking entries from the 816 Response Code table in Section 2.8.1 above. In the table of 817 values, the Reference column should be "[This document]" except 818 where the Meaning is "Unassigned" or "Reserved". 820 Registration Procedure: IETF Review 822 Reference: [This document] 824 Note: The top two bits of the Response Code indicate a category 825 as specified in Section 2.8.1 of [this document]. 827 Response Response 828 Decimal Hex Meaning Reference 829 -------- --------- ----------- --------- 830 0 0x00 Success [this document] 831 ... ... ... 832 255 0xFF Reserved 834 5.2 Group Keying RBridge Channel Protocol Numbers 836 IANA is requested to assign TBD1 as the TRILL RBridge Channel 837 protocol number, from the range assigned by Standards Action, for use 838 when the "Group Keying" protocol is transmitted over Extended RBridge 839 Channel messages. 841 The added RBridge Channel protocols registry entry on the TRILL 842 Parameters web page is as follows: 844 Protocol Description Reference 845 -------- -------------- ------------------ 846 TBD1 Group Keying Section 2 of [this document] 848 5.3 Group Secured Extended RBridge Channel SType 850 IANA is requested to assign TBD2 as the Group Secured SType in the 851 "Extended RBridge Channel Security Types Subregistry" on the TRILL 852 Parameters web page as follows: 854 SType Description Reference 855 ----- ------------- ---------- 856 TBD2 Group Secured Section 3.2 of [this document] 858 6. Security Considerations 860 TBD 862 See [RFC7978] for Extended RBridge Channel security. 864 See [RFC7457] in connection with TLS and DTLS security. 866 Normative References 868 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 870 March 1997, . 872 [RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard 873 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 874 September 2002, . 876 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 877 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 878 . 880 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 881 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 882 5310, DOI 10.17487/RFC5310, February 2009, . 885 [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard 886 (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 887 10.17487/RFC5649, September 2009, . 890 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 891 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 892 . 894 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 895 Ghanwani, "Routing Bridges (RBridges): Base Protocol 896 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 897 . 899 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 900 Security Version 1.2", RFC 6347, January 2012, . 903 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 904 and D. Dutt, "Transparent Interconnection of Lots of Links 905 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 906 10.17487/RFC7172, May 2014, . 909 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 910 D., and A. Banerjee, "Transparent Interconnection of Lots of 911 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 912 . 914 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 915 and V. Manral, "Transparent Interconnection of Lots of Links 916 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 917 . 919 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 920 Ward, "Transparent Interconnection of Lots of Links (TRILL): 921 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 922 2014, . 924 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 925 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 926 Lots of Links (TRILL): Clarifications, Corrections, and 927 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 928 . 930 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 931 Interconnection of Lots of Links (TRILL): RBridge Channel 932 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 933 2016, . 935 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 936 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 937 2017, . 939 [TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang, 940 "Transparent Interconnection of Lots of Links (TRILL) over IP", 941 draft-ietf-trill-over-ip, work in progress. 943 Informative References 945 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 946 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 947 10.17487/RFC6234, May 2011, . 950 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 951 Known Attacks on Transport Layer Security (TLS) and Datagram 952 TLS (DTLS)", RFC 7457, February 2015, . 955 Acknowledgements 957 The contributions of the following are hereby gratefully 958 acknowledged: 960 TBD 962 The document was prepared in raw nroff. All macros used were defined 963 within the source file. 965 Authors' Addresses 967 Donald E. Eastlake, 3rd 968 Huawei Technologies 969 155 Beaver Street 970 Milford, MA 01757 USA 972 Phone: +1-508-333-2270 973 EMail: d3e3e3@gmail.com 975 Copyright, Disclaimer, and Additional IPR Provisions 977 Copyright (c) 2017 IETF Trust and the persons identified as the 978 document authors. All rights reserved. 980 This document is subject to BCP 78 and the IETF Trust's Legal 981 Provisions Relating to IETF Documents 982 (http://trustee.ietf.org/license-info) in effect on the date of 983 publication of this document. Please review these documents 984 carefully, as they describe your rights and restrictions with respect 985 to this document. Code Components extracted from this document must 986 include Simplified BSD License text as described in Section 4.e of 987 the Trust Legal Provisions and are provided without warranty as 988 described in the Simplified BSD License. The definitive version of 989 an IETF Document is that published by, or under the auspices of, the 990 IETF. Versions of IETF Documents that are published by third parties, 991 including those that are translated into other languages, should not 992 be considered to be definitive versions of IETF Documents. The 993 definitive version of these Legal Provisions is that published by, or 994 under the auspices of, the IETF. Versions of these Legal Provisions 995 that are published by third parties, including those that are 996 translated into other languages, should not be considered to be 997 definitive versions of these Legal Provisions. For the avoidance of 998 doubt, each Contributor to the IETF Standards Process licenses each 999 Contribution that he or she makes as part of the IETF Standards 1000 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1001 language to the contrary, or terms, conditions or rights that differ 1002 from or are inconsistent with the rights and licenses granted under 1003 RFC 5378, shall have any effect and shall be null and void, whether 1004 published or posted by such Contributor, or included with or in such 1005 Contribution.