INTERNET-DRAFT Donald Eastlake Intended status: Proposed Standard Dacheng Zhang Huawei Expires: July 18, 2019 January 19, 2019 Simple Group Keying Protocol (SGKP) Abstract This document specifies a simple general group keying protocol that provides for the distribution of shared secret keys to group members and the management of such keys. It assumes that secure pairwise keys can be created between any two group members. Status of This Memo This Internet-Draft is submitted 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 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 Simple Group Keying Table of Contents 1. Introduction............................................3 1.1 Terminology and Acronyms..............................3 2. Simple Group Keying Protocol............................4 2.1 Assumptions............................................4 2.2 Group Keying Procedure Overview........................4 2.3 Transmission and Receipt of Group Data Messages........5 2.4 Changes in Group Membership or GKd.....................6 3. Group Keying Messages...................................7 3.1 Set Key Message........................................9 3.2 Use, Delete, Disuse, or Deleted Key Messages..........11 3.3 Response Message......................................12 3.3.1 Response Codes......................................13 3.4 No-Op Message.........................................15 4. Security Considerations................................16 5. IANA Considerations....................................17 Normative References......................................19 Informative References....................................19 Acknowledgements..........................................20 Authors' Addresses........................................21 D. Eastlake [Page 2] INTERNET-DRAFT Simple Group Keying 1. Introduction This document specifies a simple general group keying protocol that provides for the distribution of shared secret keys to group members and the management of such keys. It assumes that secure pairwise keys can be created between any two group members. A companion document specifies two profiles for the use of this group keying protocol in a case using DTLS and a case using IPsec payload formats. 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 the following terminology and acronyms: AES - Advanced Encryption Standard. DTLS - Datagram Transport Level Security [RFC6347]. 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). IS-IS - Intermediate System to Intermediate System [RFC7176]. keying material - The set of a Key ID, a secret key, and a cypher suite. QoS - Quality of Service. RBridge - An alternative term for a TRILL switch. 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 3] INTERNET-DRAFT Simple Group Keying 2. Simple Group Keying Protocol This section gives an overview of the assumptions and capabilities of the Simple Group Keying Protocol (SGKP) that provides shared secret group keys. Further details of the messages used for this protocol are give in Section 3. Any particular use of this protocol will require profiling giving further details and specifics for that use. For example, the envelope used for addressing and transmitting the messages of this protocol must be specified for any particular use. This protocol is not suitable for discovery messages but is intended for use between members of a group that have already established or can establish 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. - There are one or more keys, other than the dynamic or pairwise keys, which are already in place at all group member stations and may be present at other 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 of SGKP. All such keying messages MUST be encrypted and authenticated using the pairwise keys as further specified in the use profile. D. Eastlake [Page 4] INTERNET-DRAFT Simple Group Keying 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 dynamic key when appropriate. 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 from GKd 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 one member, transmission of data between group members is a moot question and any messages that would be so transmitted if the group had more members are discarded. 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. D. Eastlake [Page 5] INTERNET-DRAFT Simple Group Keying 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 MAY 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 dis-use 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. 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 for transmission that was 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. D. Eastlake [Page 6] INTERNET-DRAFT Simple Group Keying 3. Group Keying Messages Keying messages start with a Version number. This document specifies Version zero. Keying messages are structured, as shown in Figure 3.1 below, 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, o a key wrap algorithm specifier, and finally o a key wrapped vector of additional fields wrapped using a key derived from the stable key identified. 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 wrapping under a key derived from the stable key, then send that message to various GKs using the different pairwise keys for each GKs. +-+-+-+-+-+-+-+-+ |Ver|R|KeyID1Lng| 1 byte +-+-+-+-+-+-+-+-+... | KeyID1 ... KeyID1Lngth bytes +-+-+-+-+-+-+-+-+... | Use Type | 1 byte +-+-+-+-+-+-+-+-+ | Pad1 Length | 1 byte +-+-+-+-+-+-+-+-+... | Padding Pad1 Length bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | KW Al | KW Length | 2 bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | | Key Wrapped Material Variable size | +-+-+-+-+-+-+-+-... Figure 3.1. Keying Message Structure The fields in Figure 3.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. D. Eastlake [Page 7] INTERNET-DRAFT Simple Group Keying If set to zero, indicated a request or no-op message. KeyID1Lngth, KeyID1 - KeyID1 identifies the stable 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 minus 1 as an unsigned integer. Use Type - Specifies the particular group security use profile such as one of the two profiles in [SGKPuses]. See Section 5, Item 3. 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. KW Algorithm - An unsigned integer 4-bit field specifying the Key Wrap Algorithm. See Section 5, Item 4. KW Length - An unsigned integer 14-bit field that gives the length of the Key Wrapped Material in octets. Key Wrapped Material - The output of the designated Key Wrapping Algorithm on the message vector of fields using the designated stable key. The vector of fields contained within the key wrapping is specified for the various keying messages in subsections below. The contents of this wrapped vector are protected by the key wrapping as well as being authenticated and super-encrypted by the pairwise keyed security used for sending the overall keying message. The probability that the stable key used for key wrapping is the same as the outer message pairwise key MUST be insignificant (less that 1 in 2**64). Each group keying message contains, in the key 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 required to the No-Op message. If no response is received to a request (other than a No-Op request) 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. D. Eastlake [Page 8] INTERNET-DRAFT Simple Group Keying 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 Key Wrapped Material is 16 bytes, the minimum valid length of a keying message before pairwise security is 21 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. The maximum valid length before pairwise security is 4 (fixed bytes) + 32 (max KeyID1) + 255 (max padding) + 264 (max KW material) = 555 bytes. 3.1 Set Key Message The structure of the wrapped vector of fields for the Set Key keying message is as show in Figure 3.2. A recipient automatically determines the overall length provided for this vector of fields inside the key wrapping as a byproduct of the process of key unwrapping. +-+-+-+-+-+-+-+-+ | 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 3.2. Set Key Message Inner Structure D. Eastlake [Page 9] INTERNET-DRAFT Simple Group Keying 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 unpadded 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, Other could begin with a length byte. 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 key unwrap operation) and the length of the preceding fields. Keying material and associated cypher suite are indexed under the Key ID and the identity of the station that sent the information. This identity is normally the address of that station as specified in the D. Eastlake [Page 10] INTERNET-DRAFT Simple Group Keying use profile. 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. 3.2 Use, Delete, Disuse, or Deleted Key Messages The structure of the wrapped material for the Use Key, Delete Key, Disuse Key, and Deleted Key keying messages are the same as each other except for the message type and are shown in Figure 3.3 +-+-+-+-+-+-+-+-+ | 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 3.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 3.1. 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 D. Eastlake [Page 11] INTERNET-DRAFT Simple Group Keying 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 space is independent of the Msg IDs used in requests originated by GKd. 3.3 Response Message The structure of the wrapped material for the Response group keying message is as show below in Figure 3.4. A response message is 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 ReqPartLength bytes +-+-+-+-+-+-+-+-... Figure 3.4. Response Message Inner Structure Except as specified below, the fields are as specified for the Key Set message in Section 3.1. Msg Type, Msg ID - The content of these field is copied from the message in reply to which this Response message is sent D. Eastlake [Page 12] INTERNET-DRAFT Simple Group Keying 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 in Section 3.3.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. - 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 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). The key wrapped material in the response message will still be wrapped. 3.3.1 Response Codes The high order two bits of the Response Code have meaning as shown in Table 3.1. Top 2 Bits Category ---------- ---------- 0b00 Success 0b01 AES wrap contents 0b10/11 Outside of AES wrap contents Figure 3.1 Categories of Response Codes D. Eastlake [Page 13] INTERNET-DRAFT Simple Group Keying 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 key wrapped 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 Key unwrap fails test for constant (e.g., AES test 1, see Section 3 [RFC5649]). 132 0x85 Key unwrap fails message length versus wrapped size test (e.g., AES test 2, see Section 3 [RFC5649]). 133 0x86 Key unwrap fails test for value of padding (e.g., AES test3, 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 key 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 key wrapped inner vector of fields is too short or too long, Padding bytes are not the required value, or similar D. Eastlake [Page 14] INTERNET-DRAFT Simple Group Keying 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 when they should be correct. Figure 3.2 Response Codes 3.4 No-Op Message The No-Op message is a dummy message intended for use in disguising metadata deducible 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: +-+-+-+-+-+-+-+-+ | Msg Type = 6 | 1 byte +-+-+-+-+-+-+-+-+ | Pad2 Length | 1 bytes +-+-+-+-+-+-+-+-+... | Padding Pad2 Length bytes +-+-+-+-+-+-+-+-... Figure 3.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 3.1. 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. D. Eastlake [Page 15] INTERNET-DRAFT Simple Group Keying 4. 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 serially 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. It might still be possible to use the length of padding as a covert channel. D. Eastlake [Page 16] INTERNET-DRAFT Simple Group Keying 5. IANA Considerations 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: Name: Message Types 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: Name: Group Keying Use Profiles Registration Procedure: IETF Review Reference: [This document] Profile Description Reference(s) --------- ----------- ------------ 0 Reserved [This document] 1 Extended RBridge Channel [SGKPuses] 2 TRILL over IP [SGKPuses] 3-250 Unassigned 251-254 Reserved for Private Use [This document] 255 Reserved [This document] 4. Establish a "Key Wrap Algorithm" registry on the Group Keying Protocol Parameters page as follows: D. Eastlake [Page 17] INTERNET-DRAFT Simple Group Keying Name: Key Wrap Algorithms Registration Procedure: IETF Review Reference: [This document] Code Algorithm Reference ----- ----------- --------- 0 Reserved [This document] 1 AES [RFC5649] 2 ChaCha [ChaChaKW] 3-16 - Unassigned 17 Reserved [This document] 5. Establish a "Response Code" registry on the Group Keying Protocol Parameters page as show below taking entries from the Response Code table in Section 3.3.1 above. In the table of values, the Reference column should be "[This document]" except where the Meaning is "Unassigned" or "Reserved". Name: Response Codes Registration Procedure: IETF Review Reference: [This document] Note: The top two bits of the Response Code indicate a category as specified in Section 3.3.1 of [this document]. Response Response Decimal Hex Meaning Reference -------- --------- ----------- --------- 0 0x00 Success [this document] ... ... ... 255 0xFF Reserved D. Eastlake [Page 18] INTERNET-DRAFT Simple Group Keying Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, . [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, . [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, . [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, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SGKPuses] - D. Eastlake, D. Zhang, "Simple Group Keying Protocol TRILL Use Profiles", draft-ietf-trill-link-gk-profiles, work in progress. [ChaChaKW] - D. Eastlake, "CHA CHA 20 Key Wrap with Padding Algorithm", draft-eastlake-chacha20-key-wrap, work in progress. Informative References None. D. Eastlake [Page 19] INTERNET-DRAFT Simple Group Keying Acknowledgements The contributions of the following are hereby gratefully acknowledged: TBD D. Eastlake [Page 20] INTERNET-DRAFT Simple Group Keying Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Dacheng Zhang Huawei Technologies Email: dacheng.zhang@huawei.com D. Eastlake [Page 21] INTERNET-DRAFT Simple Group Keying Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2019 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 22]