idnits 2.17.1 draft-eastlake-trill-group-keying-01.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 (December 28, 2016) is 2676 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: June 29, 2017 December 28, 2016 5 TRILL: Group Keying 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. 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 TRILL [RFC6325] 83 [RFC7780] Extended RBridge Channel message security [RFC7178] 84 [RFC7978]. It is anticipated that there will be other uses for this 85 group keying protocol, for example in connection with link security 86 in [TRILLoverIP]. 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]. 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 RBridge - An alternative term for a TRILL switch. 122 SHA - Secure Hash Algorithm [RFC6234]. 124 TRILL - Transparent Interconnection of Lots of Links or Tunneled 125 Routing in the Link Layer. 127 TRILL switch - A device that implements the TRILL protocol 128 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 130 2. Group Keying Protocol 132 This section defines a general Group Keying Protocol that provides 133 shared secret group keys. Any particular use of this protocol will 134 require a profiling giving further details and specifics for that 135 use. The protocol is not suitable for discovery messages but is 136 intended for use between members of a group that have already 137 established pair-wise security. 139 2.1 Assumptions 141 The following are assumed: 142 - All pairs of stations in the group can engage in pairwise 143 communication with unicast messages and each can groupcast a 144 message to the other group members. 145 - At any particular time, there is a distinguished station GKd in 146 the group that is in charge of keying for the groupcast data 147 messages to be sent to the group. The group wide shared secret 148 keys established by GKd are referred to herein as "dynamic" 149 keys. 150 - Pairwise keying has been negotiated between GKd and each other 151 station GKs1, GKs2, ... GKsN in the group. These keys are 152 referred to in this protocol as "pairwise" keys. 153 - One or more keys, other than the dynamic or pairwise keys, are 154 already in place at all group member stations. These are 155 referred to as "stable" keys. 157 When keying material is stored by a station, it is accompanied by a 158 "use flag" indicating whether or not that keying material is usable 159 for groupcast transmissions. 161 2.2 Group Keying Procedure Overview 163 GKd sends unicast keying messages to the other stations in the group 164 and they respond as specified below and in further detail in the 165 particular use profile for this Group Keying Protocol. All such 166 keying messages MUST be encrypted and authenticated using the 167 pairwise keys as further specified in the use profile. 169 Typically, GKd sends a keying message to each GKs with keying 170 material. After successful acknowledgement of receipt from each GKs, 171 GKd sends a keying message to each GKs instructing it to use the 172 dynamic key GKd has set. It would be common for GKd to set a new 173 dynamic key at each GKs while an older dynamic key is in use so that 174 GKd can more promptly roll over to the new key when appropriate. 176 To avoid an indefinite build up of keying material at a GKs, keys 177 have a lifetime specified by GKd and GKd can send a message deleting 178 a key. (GKd can also send a message indicating that a key is no 179 longer to be used but leaving it set.) Should the space available at 180 a GKs for keying material be exhausted, on receipt of a Set Key 181 keying message for a new key ID GKs discards a dynamic key it has and 182 originates a Delete Key message to the source of that dynamic key. 184 2.3 Transmission and Receipt of Group Data Messages 186 If a group has only two members, then pairwise security is used 187 between them. 189 When a group has more than two members and a station in the group 190 transmits a data message to the group, if the transmitter has one or 191 more keys set by GKd that it has been instructed to use, it uses one 192 of those keys and its associated cypher suite to groupcast the data 193 message. If it has no such key, then it uses serial unicast to send 194 the data message to each other member of the group, negotiating 195 pairwise keys with them if it does not already have such pairwise 196 keys. Thus it is a responsibility of GKd not to authorize the use of 197 a groupcast key until it knows that all the GKs have that key. 199 When a station in the group receives data that has been groupcast to 200 the group, if the receiver has the key referenced by the data message 201 the receiver decrypts and verifies it. If verification fails or if 202 the receiver does not have the required key, the receiver discards 203 the data message. Thus whether GKs has been directed to "use" a key 204 by GKd is relevant only to transmission, not reception. 206 2.4 Changes in Group Membership or GKd 208 When a new station joins the group, GKd should send that station the 209 currently in-use group key and instruct it to use that key and send 210 it other keys known to the group members and intended for future use. 212 If GKd detects that one or more stations that were members of the 213 group are no longer members of the group, it SHOULD generate and 214 distribute a new group key to the remaining group members, instruct 215 them to use this new key, and delete from them any old keys known to 216 the departed group member station(s) or at least instructing them to 217 disuse such old keys that are marked for use; however, in the case of 218 groups with large and/or highly dynamic membership, where a station 219 might frequently leave and then rejoin, it may, as a practical 220 matter, be necessary to rekey less frequently. 222 A new group member can become GKd due to the previous GKd leaving the 223 group or a configuration change or the like. A GKs MUST NOT use 224 keying material set by a station that it determines is not GKd. To 225 avoid a gap in service, a station that is not GKd MAY set keying 226 material at other stations in the group; however, such a non-GKd 227 station cannot set the use flag for any such keying material. It is 228 RECOMENDED that the second highest priority station to be GKd set 229 such keying material at all other stations in the group. Should a 230 station run out of room for keying material, it SHOULD discard keying 231 material set by a station with lower priority to be GKd before 232 discarding keying material set by a higher priority station and among 233 keys set by GKd is SHOULD discard the lest recently used first. 235 2.5 Group Keying Messages 237 Keying messages start with a Version number. This document specifies 238 Version zero. 240 Keying messages are structured as 241 o a Version number, 242 o a Response flag, 243 o a Key ID length, 244 o the Key ID of a stable key, 245 o a group keying use profile identifier, 246 o possible padding, and finally 247 o an AES key wrapped [RFC5649] [RFC3394] vector of additional 248 fields wrapped using the stable key identified and using 249 AES-256, as shown in Figure 2.1 below. 251 Keying messages are always sent unicast and encrypted and 252 authenticated with the appropriate pairwise key, all as further 253 specified for the particular use profile. It will typically be 254 possible for GKd to calculate the keying message once, including the 255 AES wrapping under a stable key, then send that message to various 256 GKs using the different pairwise keys for each GKs. 258 +-+-+-+-+-+-+-+-+ 259 |Ver|R|KeyID1Lng| 1 byte 260 +-+-+-+-+-+-+-+-+... 261 | KeyID1 ... KeyID1Lngth bytes 262 +-+-+-+-+-+-+-+-+... 263 | Use Type | 1 byte 264 +-+-+-+-+-+-+-+-+ 265 | Pad1 Length | 1 byte 266 +-+-+-+-+-+-+-+-+... 267 | Padding Pad1 Length bytes 268 +-+-+-+-+-+-+-+-+... 269 |AES Wrap Length| 1 byte 270 +-+-+-+-+-+-+-+-+... 271 | 272 | AES Wrapped Material Variable size 273 | 274 +-+-+-+-+-+-+-+-... 276 Figure 2.1. Keying Message Structure 278 The fields in Figure 2.1 are as follows: 280 Ver - Group Keying protocol version. This document specifies 281 version zero. 283 R - Response flag. If set to one, indicates a response message. 284 If set to zero, indicated a request or no-op message. 286 KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key 287 wrapping key (also known as the Key Encrypting Key (KEK)) 288 as further specified in the use profile. KeyID1Lngth is a 289 byte that gives the length of KeyID1 in bytes as an 290 unsigned integer. 292 Use Type - Specifies the particular group security use profile 293 such as RBridge Extension (Section 3) or IP link 294 [TRILLoverIP]. 296 Pad1 Length, Pad1 - Padding to obscure the non-padded message 297 size. Pad1 Length may be from 0 to 255 and gives the length 298 of the padding as an unsigned integer. Each byte of padding 299 MUST be equal to Pad1 Length. For example, 3 bytes of 300 padding with length is 0x03030303. 302 AES Wrap Length - An unsigned byte that gives the length of the 303 AES Wrapped Material in units of 8 bytes. The length of AES 304 key wrapped material is, as specified in [RFC5649], always 305 a multiple of 8 bytes (64 bits) and not less than 16 bytes. 306 Thus an AES Wrap Length of 0 or 1 is invalid. 308 AES Wrapped Material - The output of the AES Key Wrapping 309 operation on the message vector of fields using the 310 specified stable key. 312 The vector of fields contained within the AES-256 key wrapping is 313 specified for the various keying messages in subsections below. The 314 contents of this wrapped vector are protected by the AES wrapping as 315 well as being authenticated and super-encrypted by the pairwise keyed 316 security used for sending the overall keying message. The stable key 317 used for AES wrapping MUST be different from the outer message 318 pairwise key. 320 Each group keying message contains, in the AES wrapped vector of 321 fields, a message type and a message ID set by the sender of a 322 request. These fields are returned in the corresponding response to 323 assist in the matching of response to requests, except that there is 324 no response to the No-Op message. 326 If no response is received to a request (other than a No-Op message) 327 for an amount of time configurable in milliseconds from 1 to ( 2**15 328 - 1 ), the request is re-transmitted with the same message ID. These 329 retries can occur up to a configurable number of times from 1 to 8. 330 Unless otherwise provided in the particular use profile, the default 331 response delay threshold is 200 milliseconds and the default maximum 332 number of retries is 3. 334 Keying messages are sent with a priority configurable on a per device 335 per use type basis. The default priority is specified in the use 336 profile. 338 Since the minimum length of the AES Wrapped Material is 16 bytes 339 [RFC5649], the minimum valid size of a keying message is 20 bytes, 340 even if KeyID1 Length and Pad1 Length are zero. All multi-byte fields 341 are in network order, that is, with the most significant byte first. 343 2.6 Set Key Message 345 The structure of the wrapped vector of fields for the Set Key keying 346 message is as show in Figure 2.2. A recipient automatically 347 determines the overall length provided for this vector of fields 348 inside the AES wrapping as a byproduct of the process of AES 349 unwrapping [RFC5649]. 351 +-+-+-+-+-+-+-+-+ 352 | Msg Type = 1 | 1 bytes 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Msg ID 3 bytes | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Pad2 Length | 1 bytes 357 +-+-+-+-+-+-+-+-+... 358 | Padding Pad2 Length bytes 359 +-+-+-+-+-+-+-+-+... 360 | Other Variable size 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Lifetime | 2 bytes 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | KeyID2 Length | 1 byte 365 +-+-+-+-+-+-+-+-+ 366 | KeyID2 ... KeyID2 Length bytes 367 +-+-+-+-+-+-+-+-+ 368 | CypherSuiteLng| 1 byte 369 +-+-+-+-+-+-+-+-+ 370 | CypherSuite ... CypherSuiteLng bytes 371 +-+-+-+-+-+-+-+-... 372 | Key ... Variable size 373 +-+-+-+-+-+-+-+-... 375 Figure 2.2. Set Key Message Inner Structure 377 The fields are as follows: 379 Msg Type = 1 for Set Key message 381 Msg ID - A 3 byte quantity to be included in the corresponding 382 response message to assist in matching requests and 383 responses. Msg ID zero has a special meaning in responses 384 and MUST NOT be used in a Set Key message or any other 385 group keying request message. 387 Pad2 Length, Pad2 - Padding to obscure the size of the unapdded 388 AES wrapped data. Pad2 Length may be from 0 to 255 and 389 gives the length of the padding as an unsigned integer. 390 Each byte of padding MUST be equal to Pad1 Length. For 391 example, 2 bytes of padding with length byte is 0x020202. 393 Other - Additional information if specified in the use profile. 394 If Other information in this message is not mentioned in 395 the use profile, there is none and this portion of the 396 wrapped information is null. If a use profile specifies 397 Other information it must be possible to determine its 398 length so that following fields can be properly parsed and 399 so that the size of the Key field can be deduced. 401 Lifetime - A 2-byte unsigned integer. After that number of 402 seconds plus one second, the key and associated information 403 being set MUST be discarded. Unless otherwise specified for 404 a particular use profile of this group keying protocol, the 405 default Lifetime is 15,000 seconds or a little over four 406 hours. 408 KeyID2 Length, KeyID2 - KeyID2 identifies the group key and 409 associated information being set as further specified in 410 the use profile. KeyID2 Length is an unsigned byte that 411 gives the length of KeyID2 in bytes. 413 CypherSuiteLng, CypherSuite - CypherSuite identifies the cypher 414 suite associated with the key being set as further 415 specified in the use profile. CypherSuite Length is an 416 unsigned byte the gives the length of CypherSuite in bytes. 418 Key - This is the actually group shared secret keying material 419 being set. Its length is deduced from the overall length of 420 the vector of fields (found by the AES unwrap operation) 421 and the length of the preceding fields. 423 If GKs already has a dynamic key set under KeyID2, the key's value 424 and associated cypher suite are compared with those in the Set Key 425 messages. If they are the same, the only receiver action is to update 426 the Lifetime information associated with KeyID2 and send a Response 427 message. If they are different, the lifetime, cypher suite, and key 428 (and possibly Other material) are replaced, the use flag is cleared, 429 and a Response message sent. 431 2.7 Use, Delete, Disuse, or Deleted Key Messages 433 The structure of the wrapped material for the Use Key, Delete Key, 434 and Disuse Key keying messages are the same as each other except for 435 the message type. This structure is shown in Figure 2.3 436 +-+-+-+-+-+-+-+-+ 437 | Msg Type = t | 1 byte 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Msg ID 3 bytes | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Pad2 Length | 1 bytes 442 +-+-+-+-+-+-+-+-+... 443 | Padding Pad2 Length bytes 444 +-+-+-+-+-+-+-+-+... 445 | Other Variable size 446 +-+-+-+-+-+-+-+-+... 447 | KeyID2 Length | 1 byte 448 +-+-+-+-+-+-+-+-+ 449 | KeyID2 ... KeyID2 bytes 450 +-+-+-+-+-+-+-+-+ 452 Figure 2.3. Use, Delete, Disuse, or Deleted Key Message 454 The Msg Type field specifies the particular message as follows: 456 Msg Type Message 457 -------- ---------- 458 2 Use Key 459 3 Delete Key 460 4 Disuse Key 461 5 Deleted Key 463 The remaining fields are as specified in Section 2.4. KeyID2 464 indicates the key to be used, deleted, for which use should cease, or 465 which has been deleted, depending on the message type. 467 It is RECOMMENDED that these messages be padded so as to be the same 468 length as a typical Set Key message. 470 The Deleted Key is sent by a station believing itself to be GKd 471 instructing some GKs to delete a key. When a GKs spontaneously 472 deletes a key, it sends a Deleted Key message to the station from 473 which it received the key. The message types for Delete Key and 474 Deleted Key are different to minimize confusion in corner cases such 475 as the GKd changing while messages are in flight. The Msg ID used in 476 a Deleted Key message is created by the sending GKs from a space of 477 Msg IDs associated with that GKs which is independent of the Msg IDs 478 used in requests originated by GKd. 480 2.8 Response Message 482 The structure of the wrapped material for the Response group keying 483 message is as show below in Figure 2.4. A response message is 484 indicated by the R bit in the first byte of the message outside the 485 key wrapping. 487 A response MUST NOT be sent due to the receipt of a response. The R 488 bit is outside of the key wrapping so that this rule can be enforced 489 even in cases of difficulty in unwrapping. 491 +-+-+-+-+-+-+-+-+ 492 | Msg Type = n | 1 byte 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Msg ID 3 bytes | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Pad2 Length | 1 bytes 497 +-+-+-+-+-+-+-+-+... 498 | Padding Pad2 Length bytes 499 +-+-+-+-+-+-+-+-+... 500 | Other Variable size 501 +-+-+-+-+-+-+-+-+... 502 | Response Code | 1 byte 503 +-+-+-+-+-+-+-+-+ 504 | ReqPartLength | 1 byte 505 +-+-+-+-+-+-+-+-+... 506 | Request Part ReqPartLenth bytes 507 +-+-+-+-+-+-+-+-... 509 Figure 2.4. Response Message Inner Structure 511 Except as specified below, the fields are as specified for the Key 512 Set message. 514 Msg Type, Msg ID - The content of these field is copied from 515 the message in reply to which this Response message is sent 516 unless there is an error that stops the replying station 517 from determining them, in which case the special value zero 518 is used for the Msg Type and Msg ID. Errors where the Msg 519 Type and ID could not be determined are indicated by a 520 Response Code with their high order bit set to one, that 521 is, the 0b10000000 bit set. 523 Response Code - An unsigned byte giving the response as 524 enumerated in Table 2.2 in Section 2.8.1. Any Response 525 Code other than a success indicates that the receiver took 526 no action on the request other than sending an error 527 Response message. 529 ReqPartLength, Request Part: It is usually usefully to include 530 some or all of the request in error responses. 531 - If the Response Code high order two bits are zero, the 532 request succeeded and ReqPartLength MUST be set to zero 533 so Request Part will be null. 535 - If the Response Code high order two bits are zero one 536 (0b01), then there was an error in the part of the 537 request inside the AES key wrapping but the unwrap 538 process was successful. ReqPartLength is the length of 539 the request message material include in the Request Part 540 field. The included request material is from the 541 unwrapped vector of fields started with the Msg Type 542 byte. 543 - If the Response Code high order bit is one (the 544 0b10000000 is set), then there was an error parsing the 545 material outside the AES key wrap or an error in the AES 546 unwrapping process. ReqPartLength is the length of the 547 request message part included in the Request Part field. 548 The included part of the request starts with the first 549 byte of the message (the byte containing the version, 550 response flag, and KeyID1 Length). 552 2.8.1 Response Codes 554 The high order two bits of the Response Code have meaning as shown in 555 Table 2.1. 557 Top 2 Bits Category 558 ---------- ---------- 559 0b00 Success 560 0b01 AES wrap contents 561 0b10/11 Outside of AES wrap contents 563 Response Response 564 Decimal Hex Meaning 565 -------- -------- ---------- 566 0 0x00 Success 567 1 0x01 Success and the key at an existing key ID was 568 changed 569 2-47 0x02-0x2F Unassigned 570 48-63 0x30-0x3F Reserved for special success codes defined in 571 use profiles 572 64 0x40 Malformed inner fields (see Note 2 below) 573 65 0x41 Unknown or zero Msg Type in a request 574 66 0x42 Zero Msg ID in a request 575 68 0x43 Invalid length KeyID2 576 69 0x44 Unknown KeyID2 577 70 0x45 Invalid length CypherSuite 578 71 0x46 Unknown CyperSuite 579 72 0x47 Bad Key (see Note 3 below) 580 73-111 0x49-0x6F Unassigned 581 112-127 0x70-0x7F Reserved for error codes defined in use 582 profiles and related to the AES wrapped 583 contents 584 128 0x80 Malformed message (see Note 1 below) 585 129 0x81 Invalid length KeyID1 586 130 0x82 Unknown KeyID1 587 131 0x83 Unknown Use Type 588 131 0x84 AES unwrap fails test 1, see Section 3 589 [RFC5649] 590 132 0x85 AES unwrap fails test 2, see Section 3 591 [RFC5649] 592 133 0x86 AES unwrap fails test 3, see Section 3 593 [RFC5649] 594 134-175 0x86-0x7F Unassigned 595 176-191 0xB0-0xBF Reserved for error codes defined in use 596 profiles and related to parts of 597 message outside the AES wrap contents 598 192 0xC0 No keys set 599 193 0xC1 Referenced key unknown 600 194 0xC2 Referenced key known but use flag not set 601 195-255 0xC3-0xFF Reserved 603 Response Code Notes: 605 Note 1 Message is too short or too long, AES wrapped material is too 606 short, Padding bytes are not the required value, or similar 607 fundamental message format problems. 609 Note 2 The AES wrapped inner vector of fields is too short or too 610 long, Padding bytes are not the required value, or similar 611 fundamental vector of fields format problems. 613 Note 3 Key is not a valid length for CypherSuite or other internal 614 checks on key (for example, parity bits in a 64 bit DES key 615 (not that you should be using DES)) fail. 617 2.8 No-Op Message 619 The No-Op message is a dummy message intended for use in disguising 620 metadata deducable from keying message transmissions. It requires no 621 response although a recipient can always decided to send a No-Op 622 message to a station from which it has received such a message. 624 +-+-+-+-+-+-+-+-+ 625 | Msg Type = 6 | 1 byte 626 +-+-+-+-+-+-+-+-+ 627 | Pad2 Length | 1 bytes 628 +-+-+-+-+-+-+-+-+... 629 | Padding Pad2 Length bytes 630 +-+-+-+-+-+-+-+-... 632 Figure 2.5. No-Op Message Inner Structure 634 The Msg Type is set to 6 to indicate a No-Op message. 636 Pad2 Length and Padding are as specified in Section 2.6. It is 637 RECOMMENDED that Pad2 Length in a No-Op message be such as to make 638 its length confusable with the length of a Set Key message. 640 2.9 General Security Considerations 642 This section gives some general security considerations of this group 643 keying protocol as distinguished from security considerations of a 644 particular use profile. 646 The method by which the stations in the group discover each other is 647 specified in the group keying use profile. GKd controls group access 648 and generally learns whatever it needs to know about GKs during the 649 pairwise authentication and pairwise keying process. 651 The group keying provided by this protocol is shared secret keying. 652 This means that data messages can only be authenticated as coming 653 from some group member but not as coming from a specific group 654 member. If this level of authentication is insufficient, GKd can 655 simply not set keys or not set them as usable. This will force all 656 stations in the group that are configured to use security for multi- 657 destination transmissions to the group to serial unicast data to the 658 other group members using pairwise keying. 660 The content value of padding fields in the Group Keying protocol is 661 fixed so that it cannot be used as a covert channel. The length of 662 padding could still be so used. 664 3. Extended RBridge Channel Group Keyed Security 666 This section specifies a profile of the group keying protocol defined 667 in Section 2. This profile provides shared secret keying to secure 668 multi-destination Extended RBridge Channel messages [RFC7978]. The 669 keys put in place by the group keying protocol are available for use 670 as DTLS pre-shared keys with the DTLS and Composite Security of 671 multi-destination Extended RBridge Channel messages as specified in 672 Section 3.2. 674 For this group keying use profile, a group is identified by TRILL 675 Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable 676 [RFC7780] RBridges with interest in that Data Label. GKd is the 677 RBridge in the group that, of those group members supporting the 678 Group Keying Protocol, is the highest priority to be a TRILL 679 distribution tree root. If not all members of the group support the 680 Group Keying Protocol, then there are two cases for multi-destination 681 Channel Tunnel RBridge Channel messages: 682 (1) If the sender and at least two other group members support the 683 Group Keying Protocol, it SHOULD, for efficiency, send a secured 684 multi-destination RBridge Channel message to cover the group and 685 serially unicast to the group members not supporting the Group 686 Keying Protocol. 687 (2) In other cases the sender serially transmits the data to the 688 group members using pairwise security. 690 3.1 Transmission of Group Keying Messages 692 Keying messages themselves are sent as unicast Extended RBridge 693 Channel messages carrying a Group Keying protocol (see Section 5.2) 694 RBridge Channel message. They MUST use DTLS Pairwise or Composite 695 (STypes 2 or 3) security. 697 The RBridge Channel fields profile for this Group Keying Use Type is 698 as follows: 700 Priority of Group Keying messages for this SHOULD be 6 unless the 701 network manager chooses to use a lower priority after 702 determining that such lower priority group keying messages 703 will yield acceptable performance. Priority 7 SHOULD NOT be 704 used as it may cause interference with the establishment and 705 maintenance of adjacency. 707 Use Type = 1 709 KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID. 711 CypherSuiteLng = 2, CypherSuite is the cypher suite used in 712 groupcast extended RBridge Channel data messages for the 713 corresponding KeyID2. This a DTLS [RFC6347] cypher suite. 715 KeyID2 Length = 1, KeyID2 is the index under which a group key is 716 set. Group keys are, in effect, indexed by this KeyID2 and 717 the nickname of the GKd as used in the Ingress Nickname 718 field of the TRILL Header of Group Keying messages. 720 3.2 Transmission of Protected Multi-destination Data 722 Protected Extended RBridge Channel [RFC7978] messages are multicast 723 (M bit set to one in the TRILL Header) and set the SType field to a 724 new value for "Group Secured" (See Section 5.3). The data is 725 formatted as one byte of Key ID followed by data formatted as TLS 1.2 726 [RFC5246] application_data using the cyphersuite and keying material 727 stored under the Key ID. 729 4. TRILL Over IP Group Keyed Security 731 This section specifies a profile of the group keying protocol defined 732 in Section 2. This profile provides shared secret keying to secure 733 TRILL over IP messages [TRILLoverIP]. The keys put in place by the 734 group keying protocol are available for use as IPSEC keys. 736 For this group keying use profile, a group is identified by an IP 737 multicast address and consists of the adjacent [RFC7177] RBridges 738 reachable with that multicast address. GKd is the RBridge in the 739 group that, of those group members supporting the Group Keying 740 Protocol, has the highest priority to be a TRILL distribution tree 741 root. If not all members of the group support the Group Keying 742 Protocol, then there are two cases for multi-destination TRILL over 743 IP messages: 744 (1) If the sender and at least two other group members support the 745 Group Keying Protocol, it SHOULD, for efficiency, send a secured 746 IPSEC message to cover the group and serially unicast to the 747 group members not supporting the Group Keying Protocol. 748 (2) In other cases the sender serially transmits the data to the 749 group members using pairwise security. 751 4.1 Transmission of Group Keying Messages 752 tbd 754 Use Type = 2 756 tbd 758 4.2 Transmission of Protected Multi-destination Data 760 tbd 762 5. IANA Considerations 764 This section gives IANA Considerations. 766 5.1 Group Keying Protocol 768 IANA is requested to perform the following actions: 770 1. Establish a protocol parameters web page for "Group Keying 771 Protocol Parameters" with the initial registries on that page 772 as specified below in this section. 774 2. Establish a "Message Type" registry on the Group Keying 775 Protocol Parameters page as follows: 777 Registration Procedure: IETF Review 779 Reference: [this document] 781 Type Description Reference 782 ------- ----------- --------------- 783 0 Reserved [This document] 784 1 Set Key [This document] 785 2 Use Key [This document] 786 3 Delete Key [This document] 787 4 Disuse Key [This document] 788 5 Deleted Key [This document] 789 6 No-Op [This document] 790 7-250 Unassigned 791 251-254 Reserved for Private Use [This document] 792 255 Reserved [This document] 794 3. Establish a "Group Keying Use Profile" registry on the Group 795 Keying Protocol Parameters page as follows: 797 Registration Procedure: IETF Review 799 Reference: [This document] 801 Profile Description Reference 802 --------- ----------- --------- 803 0 Reserved [This document] 804 1 Extended RBridge Channel [This document] 805 2 TRILL over IP [This document] 806 3-250 Unassigned 807 251-254 Reserved for Private Use [This document] 808 255 Reserved [This document] 810 4. Establish a "Response Code" registry on the Group Keying 811 Protocol Parameters page as show below taking entries from the 812 Response Code table in Section 2.8.1 above. In the table of 813 values, the Reference column should be "[This document]" except 814 where the Meaning is "Unassigned" or "Reserved". 816 Registration Procedure: IETF Review 818 Reference: [This document] 820 Note: The top two bits of the Response Code indicate a category 821 as specified in Section 2.8.1 of [this document]. 823 Response Response 824 Decimal Hex Meaning Reference 825 -------- --------- ----------- --------- 826 0 0x00 Success [this document] 827 ... ... ... 828 255 0xFF Reserved 830 5.2 Group Keying RBridge Channel Protocol Numbers 832 IANA is requested to assign TBD1 as the RBridge Channel protocol 833 numbers, from the range assigned by Standards Action, for use when 834 the "Group Keying" protocol is transmitted over Extended RBridge 835 Channel messages. 837 The added RBridge Channel protocols registry entry on the TRILL 838 Parameters web page is as follows: 840 Protocol Description Reference 841 -------- -------------- ------------------ 842 TBD1 Group Keying Section 2 of [this document] 844 5.3 Group Secured Extended RBridge Channel SType 846 IANA is requested to assign TBD2 as the Group Secured SType in the 847 "Extended RBridge Channel Security Types Subregistry" on the TRILL 848 Parameters web page as follows: 850 SType Description Reference 851 ----- ------------- ---------- 852 TBD2 Group Secured Section 3.2 of [this document] 854 6. Security Considerations 856 TBD 858 See [RFC7457] in connection with TLS and DTLS security. 860 Normative References 862 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 864 March 1997, . 866 [RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard 867 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 868 September 2002, . 870 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 871 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 872 . 874 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 875 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 876 5310, DOI 10.17487/RFC5310, February 2009, . 879 [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard 880 (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 881 10.17487/RFC5649, September 2009, . 884 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 885 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 886 . 888 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 889 Ghanwani, "Routing Bridges (RBridges): Base Protocol 890 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 891 . 893 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 894 Security Version 1.2", RFC 6347, January 2012, . 897 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 898 and D. Dutt, "Transparent Interconnection of Lots of Links 899 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 900 10.17487/RFC7172, May 2014, . 903 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 904 D., and A. Banerjee, "Transparent Interconnection of Lots of 905 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 906 . 908 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 909 and V. Manral, "Transparent Interconnection of Lots of Links 910 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 911 . 913 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 914 Ward, "Transparent Interconnection of Lots of Links (TRILL): 915 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 916 2014, . 918 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 919 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 920 Lots of Links (TRILL): Clarifications, Corrections, and 921 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 922 . 924 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 925 Interconnection of Lots of Links (TRILL): RBridge Channel 926 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 927 2016, . 929 [TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang, 930 "Transparent Interconnection of Lots of Links (TRILL) over IP", 931 draft-ietf-trill-over-ip, work in progress. 933 Informative References 935 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 936 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 937 10.17487/RFC6234, May 2011, . 940 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 941 Known Attacks on Transport Layer Security (TLS) and Datagram 942 TLS (DTLS)", RFC 7457, February 2015, . 945 Acknowledgements 947 The contributions of the following are hereby gratefully 948 acknowledged: 950 TBD 952 The document was prepared in raw nroff. All macros used were defined 953 within the source file. 955 Authors' Addresses 957 Donald E. Eastlake, 3rd 958 Huawei Technologies 959 155 Beaver Street 960 Milford, MA 01757 USA 962 Phone: +1-508-333-2270 963 EMail: d3e3e3@gmail.com 965 Copyright, Disclaimer, and Additional IPR Provisions 967 Copyright (c) 2016 IETF Trust and the persons identified as the 968 document authors. All rights reserved. 970 This document is subject to BCP 78 and the IETF Trust's Legal 971 Provisions Relating to IETF Documents 972 (http://trustee.ietf.org/license-info) in effect on the date of 973 publication of this document. Please review these documents 974 carefully, as they describe your rights and restrictions with respect 975 to this document. Code Components extracted from this document must 976 include Simplified BSD License text as described in Section 4.e of 977 the Trust Legal Provisions and are provided without warranty as 978 described in the Simplified BSD License. The definitive version of 979 an IETF Document is that published by, or under the auspices of, the 980 IETF. Versions of IETF Documents that are published by third parties, 981 including those that are translated into other languages, should not 982 be considered to be definitive versions of IETF Documents. The 983 definitive version of these Legal Provisions is that published by, or 984 under the auspices of, the IETF. Versions of these Legal Provisions 985 that are published by third parties, including those that are 986 translated into other languages, should not be considered to be 987 definitive versions of these Legal Provisions. For the avoidance of 988 doubt, each Contributor to the IETF Standards Process licenses each 989 Contribution that he or she makes as part of the IETF Standards 990 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 991 language to the contrary, or terms, conditions or rights that differ 992 from or are inconsistent with the rights and licenses granted under 993 RFC 5378, shall have any effect and shall be null and void, whether 994 published or posted by such Contributor, or included with or in such 995 Contribution.