Internet DRAFT - draft-eastlake-trill-group-keying
draft-eastlake-trill-group-keying
INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Huawei
Expires: December 19, 2017 June 20, 2017
A Group Keying Protocol
<draft-eastlake-trill-group-keying-02.txt>
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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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, <http://www.rfc-
editor.org/info/rfc5310>.
[RFC5649] - Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
10.17487/RFC5649, September 2009, <http://www.rfc-
editor.org/info/rfc5649>.
[RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
Expand Key Derivation Function (HKDF)", RFC 5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[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,
<http://www.rfc-editor.org/info/rfc6325>.
[RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-
editor.org/info/rfc6347>.
[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, <http://www.rfc-
editor.org/info/rfc7172>.
[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,
<http://www.rfc-editor.org/info/rfc7176>.
[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,
<http://www.rfc-editor.org/info/rfc7177>.
[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, <http://www.rfc-editor.org/info/rfc7178>.
[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,
<http://www.rfc-editor.org/info/rfc7780>.
[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, <http://www.rfc-editor.org/info/rfc7978>.
[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <http://www.rfc-editor.org/info/rfc8174>.
[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, <http://www.rfc-
editor.org/info/rfc6234>.
[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, <http://www.rfc-
editor.org/info/rfc7457>.
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
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]