INTERNET-DRAFT Donald Eastlake Intended status: Proposed Standard Dacheng Zhang Huawei Expires: March 27, 2018 September 28, 2017 A Group Keying Protocol Abstract This document specifies a general group keying protocol. It also provides use profiles for the application of this group keying protocol to multi-destination TRILL Extended RBridge Channel message security and TRILL over IP packet security. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the authors or the TRILL working group mailing list: trill@ietf.org. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake [Page 1] INTERNET-DRAFT TRILL: Group Keying Table of Contents 1. Introduction............................................3 1.1 Terminology and Acronyms..............................3 2. Group Keying Protocol...................................5 2.1 Assumptions............................................5 2.2 Group Keying Procedure Overview........................5 2.3 Transmission and Receipt of Group Data Messages........6 2.4 Changes in Group Membership or GKd.....................6 2.5 Group Keying Messages..................................7 2.6 Set Key Message........................................9 2.7 Use, Delete, Disuse, or Deleted Key Messages..........11 2.8 Response Message......................................12 2.8.1 Response Codes......................................14 2.8 No-Op Message.........................................15 2.9 General Security Considerations.......................16 3. DTLS: Extended RBridge Channel Group Keyed Security....17 3.1 Transmission of Group Keying Messages.................17 3.2 Transmission of Protected Multi-destination Data......18 4. TRILL Over IP Group Keyed Security.....................19 4.1 Transmission of Group Keying Messages.................19 4.2 Transmission of Protected Multi-destination Data......19 5. IANA Considerations....................................20 5.1 Group Keying Protocol.................................20 5.2 Group Keying RBridge Channel Protocol Numbers.........21 5.3 Group Secured Extended RBridge Channel SType..........21 6. Security Considerations................................22 Normative References......................................23 Informative References....................................24 Acknowledgements..........................................25 Authors' Addresses........................................26 D. Eastlake [Page 2] INTERNET-DRAFT TRILL: Group Keying 1. Introduction This document specifies a general group keying protocol in Section 2. In addition, it provides, in Section 3, the use profile for the application of this group keying protocol to a case using DTLS (TRILL [RFC6325] [RFC7780] Extended RBridge Channel message security [RFC7178] [RFC7978]) and IPsec [TRILLoverIP}. It is anticipated that there will be other uses for this group keying protocol. 1.1 Terminology and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology and acronyms defined in [RFC6325] and [RFC7178]. Some of these are repeated below for convenience along with additional new terms and acronyms. AES - Advanced Encryption Standard. Data Label - VLAN or FGL. DTLS - Datagram Transport Level Security [RFC6347]. FGL - Fine Grained Label [RFC7172]. GKd - A distinguished station in a group that is in charge of which group keying (Section 2) is in use. GKs - Stations in a group other than GKd (Section 2). HKDF - Hash based Key Derivation Function [RFC5869]. IS-IS - Intermediate System to Intermediate System [RFC7176]. keying material - The set of a Key ID, a secret key, and a cypher suite. PDU - Protocol Data Unit. QoS - Quality of Service. RBridge - An alternative term for a TRILL switch. SHA - Secure Hash Algorithm [RFC6234]. D. Eastlake [Page 3] INTERNET-DRAFT TRILL: Group Keying TRILL - Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer. TRILL switch - A device that implements the TRILL protocol [RFC6325] [RFC7780], sometimes referred to as an RBridge. D. Eastlake [Page 4] INTERNET-DRAFT TRILL: Group Keying 2. Group Keying Protocol This section defines a general Group Keying Protocol that provides shared secret group keys. Any particular use of this protocol will require profiling giving further details and specifics for that use. The protocol is not suitable for discovery messages but is intended for use between members of a group that have already established pair-wise security. 2.1 Assumptions The following are assumed: - All pairs of stations in the group can engage in pairwise communication with unicast messages and each can groupcast a message to the other group members. - At any particular time, there is a distinguished station GKd in the group that is in charge of keying for the groupcast data messages to be sent to the group. The group wide shared secret keys established by GKd are referred to herein as "dynamic" keys. - Pairwise keying has been negotiated between GKd and each other station GKs1, GKs2, ... GKsN in the group. These keys are referred to in this protocol as "pairwise" keys. - One or more keys, other than the dynamic or pairwise keys, each of which is already in place at all group member stations. These are referred to as "stable" keys. When keying material is stored by a station, it is accompanied by a "use flag" indicating whether or not that keying material is usable for groupcast transmissions. 2.2 Group Keying Procedure Overview GKd sends unicast keying messages to the other stations in the group and they respond as specified below and in further detail in the particular use profiles for this Group Keying Protocol. All such keying messages MUST be encrypted and authenticated using the pairwise keys as further specified in the use profile. Typically, GKd sends a keying message to each GKs with keying material. After successful acknowledgement of receipt from each GKs, GKd sends a keying message to each GKs instructing it to use the dynamic key GKd has set. It would be common for GKd to set a new dynamic key at each GKs while an older dynamic key is in use so that GKd can more promptly roll over to the new key when appropriate. D. Eastlake [Page 5] INTERNET-DRAFT TRILL: Group Keying To avoid an indefinite build up of keying material at a GKs, keys have a lifetime specified by GKd and GKd can send a message deleting a key. (GKd can also send a message indicating that a key is no longer to be used but leaving it set.) Should the space available at a GKs for keying material be exhausted, on receipt of a Set Key keying message for a new key ID GKs discards a dynamic key it has and originates a Delete Key message to the source of that dynamic key. 2.3 Transmission and Receipt of Group Data Messages If a group has only two members, then pairwise security is used between them. When a group has more than two members and a station in the group transmits a data message to the group, if the transmitter has one or more keys set by GKd that it has been instructed to use, it uses one of those keys and its associated cypher suite to groupcast the data message. If it has no such key, then it uses serial unicast to send the data message to each other member of the group, negotiating pairwise keys with them if it does not already have such pairwise keys. Thus it is a responsibility of GKd not to authorize the use of a groupcast key until it knows that all the GKs have that key. When a station in the group receives data that has been groupcast to the group, if the receiver has the key referenced by the data message the receiver decrypts and verifies it. If verification fails or if the receiver does not have the required key, the receiver discards the data message. Thus whether GKs has been directed to "use" a key by GKd is relevant only to transmission, not reception. 2.4 Changes in Group Membership or GKd When a new station joins the group, GKd should send that station the currently in-use group key and instruct it to use that key and send it other keys known to the group members and intended for future use. If GKd detects that one or more stations that were members of the group are no longer members of the group, it SHOULD generate and distribute a new group key to the remaining group members, instruct them to use this new key, and delete from them any old keys known to the departed group member station(s) or at least instructing them to disuse such old keys that are marked for use; however, in the case of groups with large and/or highly dynamic membership, where a station might frequently leave and then rejoin, it may, as a practical matter, be necessary to rekey less frequently. D. Eastlake [Page 6] INTERNET-DRAFT TRILL: Group Keying A new group member can become GKd due to the previous GKd leaving the group or a configuration change or the like. A GKs MUST NOT use keying material set by a station that it determines is not GKd. To avoid a gap in service, a station that is not GKd MAY set keying material at other stations in the group; however, such a non-GKd station cannot set the use flag for any such keying material. It is RECOMENDED that the second highest priority station to be GKd set such keying material at all other stations in the group. Should a station run out of room for keying material, it SHOULD discard keying material set by a station with lower priority to be GKd before discarding keying material set by a higher priority station and among keys set by GKd is SHOULD discard the lest recently used first. 2.5 Group Keying Messages Keying messages start with a Version number. This document specifies Version zero. Keying messages are structured as o a Version number, o a Response flag, o a Key ID length, o the Key ID of a stable key, o a group keying use profile identifier, o possible padding, and finally o an AES key wrapped [RFC5649] [RFC3394] vector of additional fields wrapped using the stable key identified and using AES-256, as shown in Figure 2.1 below. Keying messages are always sent unicast and encrypted and authenticated with the appropriate pairwise key, all as further specified for the particular use profile. It will typically be possible for GKd to calculate the keying message once, including the AES wrapping under a stable key, then send that message to various GKs using the different pairwise keys for each GKs. D. Eastlake [Page 7] INTERNET-DRAFT TRILL: Group Keying +-+-+-+-+-+-+-+-+ |Ver|R|KeyID1Lng| 1 byte +-+-+-+-+-+-+-+-+... | KeyID1 ... KeyID1Lngth bytes +-+-+-+-+-+-+-+-+... | Use Type | 1 byte +-+-+-+-+-+-+-+-+ | Pad1 Length | 1 byte +-+-+-+-+-+-+-+-+... | Padding Pad1 Length bytes +-+-+-+-+-+-+-+-+... |AES Wrap Length| 1 byte +-+-+-+-+-+-+-+-+... | | AES Wrapped Material Variable size | +-+-+-+-+-+-+-+-... Figure 2.1. Keying Message Structure The fields in Figure 2.1 are as follows: Ver - Group Keying protocol version. This document specifies version zero. R - Response flag. If set to one, indicates a response message. If set to zero, indicated a request or no-op message. KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key wrapping key (also known as the Key Encrypting Key (KEK)) as further specified in the use profile. KeyID1Lngth is a 5-bit field that gives the length of KeyID1 in bytes as an unsigned integer. Use Type - Specifies the particular group security use profile such as RBridge Extension (Section 3) or IP link [TRILLoverIP]. Pad1 Length, Pad1 - Padding to obscure the non-padded message size. Pad1 Length may be from 0 to 255 and gives the length of the padding as an unsigned integer. Each byte of padding MUST be equal to Pad1 Length. For example, 3 bytes of padding with length is 0x03030303. AES Wrap Length - An unsigned byte that gives the length of the AES Wrapped Material in units of 8 bytes. The length of AES key wrapped material is, as specified in [RFC5649], always a multiple of 8 bytes (64 bits) and not less than 16 bytes. Thus an AES Wrap Length of 0 or 1 is invalid. D. Eastlake [Page 8] INTERNET-DRAFT TRILL: Group Keying AES Wrapped Material - The output of the AES Key Wrapping operation on the message vector of fields using the specified stable key. The vector of fields contained within the AES-256 key wrapping is specified for the various keying messages in subsections below. The contents of this wrapped vector are protected by the AES wrapping as well as being authenticated and super-encrypted by the pairwise keyed security used for sending the overall keying message. The stable key used for AES wrapping MUST be different from the outer message pairwise key. Each group keying message contains, in the AES wrapped vector of fields, a message type and a message ID set by the sender of a request. These fields are returned in the corresponding response to assist in the matching of response to requests, except that there is no response to the No-Op message. If no response is received to a request (other than a No-Op message) for an amount of time configurable in milliseconds from 1 to ( 2**15 - 1 ), the request is re-transmitted with the same message ID. These retries can occur up to a configurable number of times from 1 to 8. Unless otherwise provided in the particular use profile, the default response delay threshold is 200 milliseconds and the default maximum number of retries is 3. Keying messages are sent with a priority/QoS configurable on a per device per use type basis. The default priority/QoS is specified in the use profile. Since the minimum length of the AES Wrapped Material is 16 bytes [RFC5649], the minimum valid size of a keying message is 20 bytes, even if KeyID1 Length and Pad1 Length are zero. All multi-byte fields are in network order, that is, with the most significant byte first. 2.6 Set Key Message The structure of the wrapped vector of fields for the Set Key keying message is as show in Figure 2.2. A recipient automatically determines the overall length provided for this vector of fields inside the AES wrapping as a byproduct of the process of AES unwrapping [RFC5649]. D. Eastlake [Page 9] INTERNET-DRAFT TRILL: Group Keying +-+-+-+-+-+-+-+-+ | Msg Type = 1 | 1 bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad2 Length | 1 bytes +-+-+-+-+-+-+-+-+... | Padding Pad2 Length bytes +-+-+-+-+-+-+-+-+... | Other Variable size +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | 2 bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KeyID2 Length | 1 byte +-+-+-+-+-+-+-+-+ | KeyID2 ... KeyID2 Length bytes +-+-+-+-+-+-+-+-+ | CypherSuiteLng| 1 byte +-+-+-+-+-+-+-+-+ | CypherSuite ... CypherSuiteLng bytes +-+-+-+-+-+-+-+-... | Key ... Variable size +-+-+-+-+-+-+-+-... Figure 2.2. Set Key Message Inner Structure The fields are as follows: Msg Type = 1 for Set Key message Msg ID - A 3 byte quantity to be included in the corresponding response message to assist in matching requests and responses. Msg ID zero has a special meaning in responses and MUST NOT be used in a Set Key message or any other group keying request message. Pad2 Length, Pad2 - Padding to obscure the size of the unapdded AES wrapped data. Pad2 Length may be from 0 to 255 and gives the length of the padding as an unsigned integer. Each byte of padding MUST be equal to Pad1 Length. For example, 2 bytes of padding with length byte is 0x020202. Other - Additional information if specified in the use profile. If Other information in this message is not mentioned in the use profile, there is none and this portion of the wrapped information is null. If a use profile specifies Other information it must be possible to determine its length so that following fields can be properly parsed and so that the size of the Key field can be deduced; for example, it could begin with a length byte. D. Eastlake [Page 10] INTERNET-DRAFT TRILL: Group Keying Lifetime - A 2-byte unsigned integer. After that number of seconds plus one second, the key and associated information being set MUST be discarded. Unless otherwise specified for a particular use profile of this group keying protocol, the default Lifetime is 15,000 seconds or a little over four hours. KeyID2 Length, KeyID2 - KeyID2 identifies the group key and associated information being set as further specified in the use profile. KeyID2 Length is an unsigned byte that gives the length of KeyID2 in bytes. CypherSuiteLng, CypherSuite - CypherSuite identifies the cypher suite associated with the key being set as further specified in the use profile. CypherSuite Length is an unsigned byte the gives the length of CypherSuite in bytes. Key - This is the actually group shared secret keying material being set. Its length is deduced from the overall length of the vector of fields (found by the AES unwrap operation) and the length of the preceding fields. If GKs already has a dynamic key set under KeyID2, the key's value and associated cypher suite are compared with those in the Set Key messages. If they are the same, the only receiver action is to update the Lifetime information associated with KeyID2 and send a Response message. If they are different, the lifetime, cypher suite, and key (and possibly Other material) are replaced, the use flag is cleared, and a Response message sent. 2.7 Use, Delete, Disuse, or Deleted Key Messages The structure of the wrapped material for the Use Key, Delete Key, and Disuse Key keying messages are the same as each other except for the message type. This structure is shown in Figure 2.3 D. Eastlake [Page 11] INTERNET-DRAFT TRILL: Group Keying +-+-+-+-+-+-+-+-+ | Msg Type = t | 1 byte +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad2 Length | 1 bytes +-+-+-+-+-+-+-+-+... | Padding Pad2 Length bytes +-+-+-+-+-+-+-+-+... | Other Variable size +-+-+-+-+-+-+-+-+... | KeyID2 Length | 1 byte +-+-+-+-+-+-+-+-+ | KeyID2 ... KeyID2 bytes +-+-+-+-+-+-+-+-+ Figure 2.3. Use, Delete, Disuse, or Deleted Key Message The Msg Type field specifies the particular message as follows: Msg Type Message -------- ---------- 2 Use Key 3 Delete Key 4 Disuse Key 5 Deleted Key The remaining fields are as specified in Section 2.4. KeyID2 indicates the key to be used, deleted, for which use should cease, or which has been deleted, depending on the message type. It is RECOMMENDED that these messages be padded so as to be the same length as a typical Set Key message. The Delete Key is sent by a station believing itself to be GKd instructing some GKs to delete a key. When a GKs spontaneously deletes a key, it sends a Deleted Key message to the station from which it received the key. The message types for Delete Key and Deleted Key are different to minimize confusion in corner cases such as the GKd changing while messages are in flight. The Msg ID used in a Deleted Key message is created by the sending GKs from a space of Msg IDs associated with that GKs which is independent of the Msg IDs used in requests originated by GKd. 2.8 Response Message The structure of the wrapped material for the Response group keying message is as show below in Figure 2.4. A response message is D. Eastlake [Page 12] INTERNET-DRAFT TRILL: Group Keying indicated by the R bit in the first byte of the message outside the key wrapping. A response MUST NOT be sent due to the receipt of a response. The R bit is outside of the key wrapping so that this rule can be enforced even in cases of difficulty in unwrapping. +-+-+-+-+-+-+-+-+ | Msg Type = n | 1 byte +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad2 Length | 1 bytes +-+-+-+-+-+-+-+-+... | Padding Pad2 Length bytes +-+-+-+-+-+-+-+-+... | Other Variable size +-+-+-+-+-+-+-+-+... | Response Code | 1 byte +-+-+-+-+-+-+-+-+ | ReqPartLength | 1 byte +-+-+-+-+-+-+-+-+... | Request Part ReqPartLenth bytes +-+-+-+-+-+-+-+-... Figure 2.4. Response Message Inner Structure Except as specified below, the fields are as specified for the Key Set message. Msg Type, Msg ID - The content of these field is copied from the message in reply to which this Response message is sent unless there is an error that stops the replying station from determining them; in that case the special value zero is used for the Msg Type and Msg ID. Errors where the Msg Type and ID could not be determined are indicated by a Response Code with its high order bit set to one, that is, the 0b1xxxxxxx bit set. Response Code - An unsigned byte giving the response as enumerated in Table 2.2 in Section 2.8.1. Any Response Code other than a success indicates that the receiver took no action on the request other than sending an error Response message. ReqPartLength, Request Part: It is usually usefully to include some or all of the request message in error responses. - If the Response Code high order two bits are zero, the request succeeded and ReqPartLength MUST be set to zero so Request Part will be null. D. Eastlake [Page 13] INTERNET-DRAFT TRILL: Group Keying - If the Response Code high order two bits are zero one (0b01xxxxxx), then there was an error in the part of the request inside the AES key wrapping but the unwrap process was successful. ReqPartLength is the length of the request message material included in the Request Part field. The included request material is from the unwrapped vector of fields started with the Msg Type byte. - If the Response Code high order bit is one (the 0b1xxxxxxx is set), then there was an error parsing the material outside the AES key wrap or an error in the AES unwrapping process. ReqPartLength is the length of the request message part included in the Request Part field. The included part of the request starts with the first byte of the message (the byte containing the version, response flag, and KeyID1 Length). 2.8.1 Response Codes The high order two bits of the Response Code have meaning as shown in Table 2.1. Top 2 Bits Category ---------- ---------- 0b00 Success 0b01 AES wrap contents 0b10/11 Outside of AES wrap contents Response Response Decimal Hex Meaning -------- -------- ---------- 0 0x00 Success 1 0x01 Success and the key at an existing key ID was changed 2-47 0x02-0x2F Unassigned 48-63 0x30-0x3F Reserved for special success codes defined in use profiles 64 0x40 Malformed inner fields (see Note 2 below) 65 0x41 Unknown or zero Msg Type in a request 66 0x42 Zero Msg ID in a request 68 0x43 Invalid length KeyID2 69 0x44 Unknown KeyID2 70 0x45 Invalid length CypherSuite 71 0x46 Unknown CyperSuite 72 0x47 Bad Key (see Note 3 below) 73-111 0x49-0x6F Unassigned 112-127 0x70-0x7F Reserved for error codes defined in use profiles and related to the AES wrapped D. Eastlake [Page 14] INTERNET-DRAFT TRILL: Group Keying contents 128 0x80 Malformed message (see Note 1 below) 129 0x81 Invalid length KeyID1 130 0x82 Unknown KeyID1 131 0x83 Unknown Use Type 131 0x84 AES unwrap fails test 1, see Section 3 [RFC5649] 132 0x85 AES unwrap fails test 2, see Section 3 [RFC5649] 133 0x86 AES unwrap fails test 3, see Section 3 [RFC5649] 134-175 0x86-0x7F Unassigned 176-191 0xB0-0xBF Reserved for error codes defined in use profiles and related to parts of message outside the AES wrap contents 192 0xC0 No keys set 193 0xC1 Referenced key unknown 194 0xC2 Referenced key known but use flag not set 195-255 0xC3-0xFF Reserved Response Code Notes: Note 1 Message is too short or too long, AES wrapped material is too short, Padding bytes are not the required value, or similar fundamental message format problems. Note 2 The AES wrapped inner vector of fields is too short or too long, Padding bytes are not the required value, or similar fundamental vector of fields format problems. Note 3 Key is not a valid length for CypherSuite or other internal checks on key (for example, parity bits in a 64 bit DES key (not that you should be using DES)) fail. 2.8 No-Op Message The No-Op message is a dummy message intended for use in disguising metadata deducable from keying message transmissions. It requires no response although a recipient can always decided to send a No-Op message to a station from which it has received such a message. The vector of fields inside the AES key wrap is as follows: D. Eastlake [Page 15] INTERNET-DRAFT TRILL: Group Keying +-+-+-+-+-+-+-+-+ | Msg Type = 6 | 1 byte +-+-+-+-+-+-+-+-+ | Pad2 Length | 1 bytes +-+-+-+-+-+-+-+-+... | Padding Pad2 Length bytes +-+-+-+-+-+-+-+-... Figure 2.5. No-Op Message Inner Structure The Msg Type is set to 6 to indicate a No-Op message. Pad2 Length and Padding are as specified in Section 2.6. It is RECOMMENDED that Pad2 Length in a No-Op message be such as to make its length the same as the length of a typical Set Key message. 2.9 General Security Considerations This section gives some general security considerations of this group keying protocol as distinguished from security considerations of a particular use profile. The method by which the stations in the group discover each other is specified in the group keying use profile. GKd controls group access and generally learns whatever it needs to know about GKs during the pairwise authentication and pairwise keying process. The group keying provided by this protocol is shared secret keying. This means that data messages can only be authenticated as coming from some group member but not as coming from a specific group member. If this level of authentication is insufficient, GKd can simply not set keys or not set them as usable. This will force all stations in the group that are configured to use security for multi- destination transmissions to the group to serial unicast data to the other group members using pairwise keying. The content value of padding fields in the Group Keying protocol is fixed so that it cannot be used as a covert channel. The length of padding could still be so used. D. Eastlake [Page 16] INTERNET-DRAFT TRILL: Group Keying 3. DTLS: Extended RBridge Channel Group Keyed Security This section specifies a profile of the group keying protocol defined in Section 2. This profile provides shared secret keying to secure multi-destination Extended RBridge Channel messages [RFC7978]. The keys put in place by the group keying protocol are available for use as DTLS pre-shared keys with the DTLS and Composite Security of multi-destination Extended RBridge Channel messages as specified in Section 3.2. For this group keying use profile, a group is identified by TRILL Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable [RFC7780] RBridges with interest in that Data Label. GKd is the RBridge in the group that, of those group members supporting the Group Keying Protocol, is the highest priority to be a TRILL distribution tree root. If not all members of the group support the Group Keying Protocol, then there are two cases for multi-destination Channel Tunnel RBridge Channel messages: (1) If the sender and at least two other group members support the Group Keying Protocol, it SHOULD, for efficiency, send a secured multi-destination RBridge Channel message to cover the group and serially unicast to the group members not supporting the Group Keying Protocol. (2) In other cases the sender serially transmits the data to the group members using pairwise security. 3.1 Transmission of Group Keying Messages Keying messages themselves are sent as unicast Extended RBridge Channel messages carrying a Group Keying protocol (see Section 5.2) RBridge Channel message. They MUST use DTLS Pairwise or Composite (STypes 2 or 3) security. The Group Keying profile for this Group Keying Use Type is as follows: Priority of Group Keying messages for this SHOULD be 6 unless the network manager chooses to use a lower priority after determining that such lower priority group keying messages will yield acceptable performance. Priority 7 SHOULD NOT be used as it may cause interference with the establishment and maintenance of adjacency. Use Type = 1 KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID. CypherSuiteLng = 2, CypherSuite is the cypher suite used in D. Eastlake [Page 17] INTERNET-DRAFT TRILL: Group Keying groupcast extended RBridge Channel data messages for the corresponding KeyID2. This a DTLS [RFC6347] cypher suite. KeyID2 Length = 1, KeyID2 is the index under which a group key is set. Group keys are, in effect, indexed by this KeyID2 and the nickname of the GKd as used in the Ingress Nickname field of the TRILL Header of Group Keying messages. 3.2 Transmission of Protected Multi-destination Data Protected Extended RBridge Channel [RFC7978] messages are multicast (M bit set to one in the TRILL Header) and set the SType field to a new value for "Group Secured" (See Section 5.3). The data is formatted as one byte of Key ID followed by data formatted as TLS 1.2 [RFC5246] application_data using the cyphersuite and keying material stored under the Key ID. D. Eastlake [Page 18] INTERNET-DRAFT TRILL: Group Keying 4. TRILL Over IP Group Keyed Security This section specifies a profile of the group keying protocol defined in Section 2. This profile provides shared secret keying to secure TRILL over IP messages [TRILLoverIP]. The keys put in place by the group keying protocol are available for use as IPSEC keys. For this group keying use profile, a group is identified by an IP multicast address and consists of the adjacent [RFC7177] RBridges reachable with that multicast address. GKd is the RBridge in the group that, of those group members supporting the Group Keying Protocol, has the highest priority to be a TRILL distribution tree root. If not all members of the group support the Group Keying Protocol, then there are two cases for multi-destination TRILL over IP messages: (1) If the sender and at least two other group members support the Group Keying Protocol, it SHOULD, for efficiency, send a secured IPSEC message to cover the group and serially unicast to the group members not supporting the Group Keying Protocol. (2) In other cases the sender serially transmits the data to the group members using pairwise security. 4.1 Transmission of Group Keying Messages tbd Use Type = 2 tbd 4.2 Transmission of Protected Multi-destination Data tbd D. Eastlake [Page 19] INTERNET-DRAFT TRILL: Group Keying 5. IANA Considerations This section gives IANA Considerations. 5.1 Group Keying Protocol IANA is requested to perform the following actions: 1. Establish a protocol parameters web page for "Group Keying Protocol Parameters" with the initial registries on that page as specified below in this section. 2. Establish a "Message Type" registry on the Group Keying Protocol Parameters page as follows: Registration Procedure: IETF Review Reference: [this document] Type Description Reference ------- ----------- --------------- 0 Reserved [This document] 1 Set Key [This document] 2 Use Key [This document] 3 Delete Key [This document] 4 Disuse Key [This document] 5 Deleted Key [This document] 6 No-Op [This document] 7-250 Unassigned 251-254 Reserved for Private Use [This document] 255 Reserved [This document] 3. Establish a "Group Keying Use Profile" registry on the Group Keying Protocol Parameters page as follows: Registration Procedure: IETF Review Reference: [This document] Profile Description Reference --------- ----------- --------- 0 Reserved [This document] 1 Extended RBridge Channel [This document] 2 TRILL over IP [This document] 3-250 Unassigned 251-254 Reserved for Private Use [This document] 255 Reserved [This document] D. Eastlake [Page 20] INTERNET-DRAFT TRILL: Group Keying 4. Establish a "Response Code" registry on the Group Keying Protocol Parameters page as show below taking entries from the Response Code table in Section 2.8.1 above. In the table of values, the Reference column should be "[This document]" except where the Meaning is "Unassigned" or "Reserved". Registration Procedure: IETF Review Reference: [This document] Note: The top two bits of the Response Code indicate a category as specified in Section 2.8.1 of [this document]. Response Response Decimal Hex Meaning Reference -------- --------- ----------- --------- 0 0x00 Success [this document] ... ... ... 255 0xFF Reserved 5.2 Group Keying RBridge Channel Protocol Numbers IANA is requested to assign TBD1 as the TRILL RBridge Channel protocol number, from the range assigned by Standards Action, for use when the "Group Keying" protocol is transmitted over Extended RBridge Channel messages. The added RBridge Channel protocols registry entry on the TRILL Parameters web page is as follows: Protocol Description Reference -------- -------------- ------------------ TBD1 Group Keying Section 2 of [this document] 5.3 Group Secured Extended RBridge Channel SType IANA is requested to assign TBD2 as the Group Secured SType in the "Extended RBridge Channel Security Types Subregistry" on the TRILL Parameters web page as follows: SType Description Reference ----- ------------- ---------- TBD2 Group Secured Section 3.2 of [this document] D. Eastlake [Page 21] INTERNET-DRAFT TRILL: Group Keying 6. Security Considerations TBD See [RFC7978] for Extended RBridge Channel security. See [RFC7457] in connection with TLS and DTLS security. D. Eastlake [Page 22] INTERNET-DRAFT TRILL: Group Keying Normative References [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, . [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, . [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, . [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, . [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, . [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014, . [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links D. Eastlake [Page 23] INTERNET-DRAFT TRILL: Group Keying (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, . [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", draft-ietf-trill-over-ip, work in progress. Informative References [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, February 2015, . D. Eastlake [Page 24] INTERNET-DRAFT TRILL: Group Keying Acknowledgements The contributions of the following are hereby gratefully acknowledged: TBD The document was prepared in raw nroff. All macros used were defined within the source file. D. Eastlake [Page 25] INTERNET-DRAFT TRILL: Group Keying Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Dacheng Zhang Huawei Technologies Email: dacheng.zhang@huawei.com D. Eastlake [Page 26] INTERNET-DRAFT TRILL: Group Keying Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake [Page 27]