Network Working Group B. Weis
Internet-Draft Cisco Systems
Intended status: Standards Track U. Mangla
Expires: April 13, 2014 N. Maheshwari
Juniper Networks Inc.
T. Karl
Deutsche Telekom
October 10, 2013
GDOI GROUPKEY-PUSH Acknowledgement Message
draft-weis-gdoi-rekey-ack-00
Abstract
The Group Domain of Interpretation (RFC 6407) includes the ability
for a Group Controller/Key Server (GCKS) to provide a set of current
Group Member (GM) devices with additional security associations
(e.g., to rekey expiring security associations). This memo adds the
ability of a GCKS to request the GM devices to return an
acknowledgement of receipt of its rekey message, and specifies the
acknowledgement method.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 13, 2014.
Copyright Notice
Copyright (c) 2013 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
Weis, et al. Expires April 13, 2014 [Page 1]
Internet-Draft GROUPKEY-PUSH ACK October 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Acknowledgement Message Request . . . . . . . . . . . . . . . 5
2.1. REKEY_ACK_KEK Type . . . . . . . . . . . . . . . . . . . . 5
2.2. REKEY_ACK_LKH Type . . . . . . . . . . . . . . . . . . . . 5
3. GROUPKEY-PUSH Acknowledgement Message . . . . . . . . . . . . 6
3.1. ISAKMP HDR . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. HASH . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Group Member Operations . . . . . . . . . . . . . . . . . . . 9
5. GCKS Operations . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Protection of the GROUPKEY-PUSH ACK . . . . . . . . . . . 11
6.2. Transmitting a GROUPKEY-PUSH ACK . . . . . . . . . . . . . 12
6.3. Receiving a GROUPKEY-PUSH ACK . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Weis, et al. Expires April 13, 2014 [Page 2]
Internet-Draft GROUPKEY-PUSH ACK October 2013
1. Introduction
The Group Domain of Interpretation (RFC 6407) is a group key
management method by which a Group Controller/Key Server (GCKS)
distributes security associations (i.e., cryptographic policy and
keying material) to a set of Group Member (GM) devices. GDOI meets
the requirement of the Multicast Security (MSEC) Group Key Management
Architecture [RFC4046], and defines both a Registration Protocol and
Rekey Protocol. GDOI describes the Rekey Protocol as a GROUPKEY-PUSH
message.
A GDOI GCKS uses a GROUPKEY-PUSH message to alert group members to
updates in policy for the group, including new policy and keying
material, replacement policy and keying material, and indications of
deleted policy and keying material. Usually the GCKS does not
require a notification that the group member actually received the
policy. However, in some cases it is beneficial for a GCKS to be
told by each receiving GM that it received the rekey message and by
implication has reacted to the policy contained within. For example,
a GCKS policy can use the acknowledgements to determine which GMs are
receiving the current group policy and which members may no longer be
members of the group.
This memo introduces a method by which a GM returns an acknowledgment
message to the GCKS. Initially a GCKS requests GM to acknowledge
GROUPKEY-PUSH messages as part of distributed group policy. Then
(shown in Figure 1) when the GCKS delivers a GROUPKEY-PUSH message,
each GM that honors the GCKS request returns a GROUPKEY-PUSH
Acknowledgement Message. The rest of this memo describe this method
in detail.
GROUPKEY-PUSH ACK
+------------------------------+
| +-------> GM1
<----+ |
GCKS +--------------------->+
<----+ GROUPKEY-PUSH |
| +-------> GM2
+------------------------------+
GROUPKEY-PUSH ACK
Figure 1: GROUPKEY-PUSH Rekey Event
Implementation of the GROUPKEY-PUSH Acknowledgement Message is
OPTIONAL.
Weis, et al. Expires April 13, 2014 [Page 3]
Internet-Draft GROUPKEY-PUSH ACK October 2013
1.1. Requirements notation
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].
Weis, et al. Expires April 13, 2014 [Page 4]
Internet-Draft GROUPKEY-PUSH ACK October 2013
2. Acknowledgement Message Request
When a GM is ready to join a group, it contacts the GCKS with a
GROUPKEY-PULL Registration Protocol. When the GCKS has authenticated
and verified that the GM is an authorized member of the group it
download several sets of policy in a Security Association (SA)
payload. If the group includes the use of a GROUPKEY-PUSH Rekey
Protocol, the SA payload includes an SA KEK payload (Section 5.3 of
[RFC6407]). When necessary the GROUPKEY-PUSH Rekey Protocol also
contains an SA payload that includes SA KEK policy. The SA KEK
policy indicates how the GM will be receiving and handling the
GROUPKEY-PUSH Rekey Protocol.
When the GCKS policy includes the use of the GROUPKEY-PUSH
Acknowledgement Message, the GCKS reports this policy to the GM
within the SA KEK policy. The GCKS includes a new KEK Attribute with
the name KEK_ACK_REQUESTED (value TBD-1), which indicates that the GM
is requested to return a GROUPKEY-PUSH Acknowledgement Message. A GM
receiving the KEK_ACK_REQUESTED attribute can choose to ignore it,
thus appearing as if it does not support the KEK_ACK_REQUESTED
attribute. However, GCKS policy may consider a non-responsive GM to
no longer desire to be a member of the group.
The following values of the KEK_ACK_REQUESTED are defined in this
memo.
2.1. REKEY_ACK_KEK Type
This type of Rekey ACK indicates the message defined in this memo,
where the base_key (defined in Section 3.2) is the KEK_ALGORITHM_KEY
used to decrypt the GROUPKEY-PUSH message.
2.2. REKEY_ACK_LKH Type
This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM
KEK attribute has a value representing LKH. The base_key is the Key
Data taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY
attribute (see Section 5.6.3.1 of [RFC6407]). This is a private key
that the GCKS shares with the group member.
Weis, et al. Expires April 13, 2014 [Page 5]
Internet-Draft GROUPKEY-PUSH ACK October 2013
3. GROUPKEY-PUSH Acknowledgement Message
The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in
Figure 2. The SA and KD payloads contain the actual policy and
keying material being distributed to the GM. The SEQ payload
containing a sequence number that is used by the GM for replay
protection. This sequence number defines a unique rekey message
delivered to that GM.
GM GCKS
-- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Rekey SA KEK; encryption occurs after HDR
Figure 2: GROUPKEY-PUSH from RFC 6407
When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK
and it chooses to respond, it returns the value of the Sequence
Number taken from the GROUPKEY-PUSH message to the GCKS along with
its identity. This tuple alerts the GCKS that the GM has received
the GROUPKEY-PUSH message and implemented the policy contained
therein. The GROUPKEY-PUSH Acknowledgement Message is shown in
Figure 3.
GM GCKS
-- ----
HDR, HASH, SEQ, ID ---->
Figure 3: GROUPKEY-PUSH Acknowledgement Message
The IP header for the GROUPKEY-PUSH Acknowledgement Message is
constructed as if it were a reply to the GROUPKEY-PUSH message. That
is, the Source Address of the GROUPKEY-PUSH message becomes the
Destination Address of the GROUPKEY-PUSH Acknowledgement Message and
the GM includes its own IP address as the Source Address of the
GROUPKEY-PUSH Acknowledgement Message. The Source port in the
GROUPKEY-PUSH message UDP header becomes the Destination port of the
GROUPKEY-PUSH Acknowledgement Message UDP header, and the Destination
port of the GROUPKEY-PUSH message UDP header becomes the Source port
of the GROUPKEY-PUSH Acknowledgement Message UDP header.
The following sections describe the payloads in the GROUPKEY-PUSH
Acknowledgement Message.
Weis, et al. Expires April 13, 2014 [Page 6]
Internet-Draft GROUPKEY-PUSH ACK October 2013
3.1. ISAKMP HDR
The message begins with an ISAKMP [RFC2408] header. The fields in
the HDR must be initialized as follows. The Cookies of a GROUPKEY-
PUSH message act as a Security Parameter Index (SPI) and are copied
to the Acknowledgement Message. Next Payload identifies a Hash
payload (8). Major Version is 1 and Minor Version is 0. The
Exchange Type has value 35 for the GDOI GROUPKEY-PUSH Acknowledgment
Message. Flags are set to 0. Message ID MUST be set to zero.
Length is according to ISAKMP (Section 3.1 of [RFC2408]).
3.2. HASH
The HASH payload is defined in ISAKMP [RFC2408]. The hash data in
the HASH payload is created as follows:
HASH = prf(ack_key, SEQ | ID)
where:
o prf is PRF-HMAC-SHA-256 [RFC4868].
o "|" indicates concatenation.
o SEQ and ID represent the bytes comprising the Sequence Number and
Identification Payloads
The ack_key is computed from a KDF that conforms to KDF in Feedback
Mode as defined in NIST SP800-108 [SP800-108] where the length of the
derived keying material is the same as the output of the PRF, there
is no initialization vector, and the optional counter is not used.
ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L)
where:
o prf is PRF-HMAC-SHA-256 [RFC4868].
o base_key is specific to the KEK_ACK_REQUESTED value, and is
described as part of that description.
o "|" indicates concatenation.
o "GROUPKEY-PUSH ACK" is a label encoded as a null terminated ASCII
string.
o SPI is the Initiator Cookie followed by the Responder Cookie taken
from the GROUPKEY-PUSH message HDR, which describes the Context of
Weis, et al. Expires April 13, 2014 [Page 7]
Internet-Draft GROUPKEY-PUSH ACK October 2013
the key usage.
o L is a length field matching the number of bits in the ack_key. L
MUST match the length of the base_key. The value L is represented
as two octets
3.3. SEQ
The Sequence Number Payload is defined in [RFC6407]. The value in
the GROUPKEY-PUSH SEQ payload is copied to the SEQ payload.
3.4. ID
The Identification payload is defined in ISAKMP [RFC2408]. The ID
payload contains an ID Type of ID_IPV4_ADDR or ID_IPV6_ADDR as
defined in [RFC2407]. Protocol ID and Port fields MUST be set to 0.
The address provided in the ID payload represents the IP address of
the GM, and MUST match the source IP address used for the most recent
GROUPKEY-PULL exchange.
Weis, et al. Expires April 13, 2014 [Page 8]
Internet-Draft GROUPKEY-PUSH ACK October 2013
4. Group Member Operations
When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or
GROUPKEY-PUSH message) including an KEK_ACK_REQUESTED attribute, it
records in its group state some indication that it is expected to
return a GROUPKEY-PUSH ACK message. A GM SHOULD honor the
KEK_ACK_REQUESTED attribute by sending acknowledgments, because it
can be expected that the GCKS is likely to take some policy-specific
action regarding non-responsive GMs, including ceasing to deliver
GROUPKEY-PUSH messages to it.
If a GM does not intend to respond with Acknowledgements, or cannot
respond with the requested type of Acknowledgement, it continues with
protocol exchange and participates in the group. In any case, if a
GM stops receiving GROUPKEY-PUSH messages from a GCKS it will re-
register before existing security associations expire, so omitting
sending Acknowledgements should not be critical.
When a GM receives a GROUPKEY-PUSH message, it processes the message
according to RFC 6407. When it concludes successful processing of
the message, it formulates the GROUPKEY-PUSH ACK messages as
described in Section 3 and delivers the message to the GCKS from
which the GROUPKEY-PUSH message was received. A GROUPKEY-PUSH ACK
message is sent even if the GROUPKEY-PUSH message contains a Delete
payload for the KEK used to protect the GROUPKEY-PUSH message.
Weis, et al. Expires April 13, 2014 [Page 9]
Internet-Draft GROUPKEY-PUSH ACK October 2013
5. GCKS Operations
When a GCKS policy includes requesting a GROUPKEY-PUSH ACK message
from Group Members, it includes the KEK_ACK_REQUESTED attribute in
the SA KEK payload. It does this each time the SA KEK is delivered,
in both a GROUPKEY-PULL exchange and GROUPKEY-PUSH message. The
value of the KEK_ACK_REQUESTED attribute will depend upon the type SA
KEK, as described in Section 2.
When a GCKS receives a GROUPKEY-PUSH ACK message (identified by an
Exchange type of GROUPKEY-PUSH-ACK), it first verifies that the group
policy includes receiving GROUPKEY-PUSH ACK messages. If not, the
message is discarded.
If the message is expected, the GCKS validates the format of the
message, and verifies that the HASH has been properly constructed as
described in Section 3.2. If validation fails, the message is
discarded. The GCKS extracts the sequence number and identity of the
GM from the SEQ and ID payloads respectively, and records the fact
that the GM received the GROUPKEY-PUSH message represented by its
serial number. The GCKS MAY be configured with additional policy
actions such as alerting its administrators of GMs that do not return
several consecutive acknowledgement messages or even removing
unresponsive GMs from the group. However, a GCKS with a policy of
removing GMs from the group needs to be aware that GMs that chose not
to respond will not receive newer group policy until it initiates
contact with the GCKS again.
When a GROUPKEY-PUSH message includes a Delete payload for the KEK
used to protect the GROUPKEY-PUSH message, the GCKS should not itself
delete the KEK until it has given GMs time to acknowledge receiving
the GROUPKEY-PUSH message.
Weis, et al. Expires April 13, 2014 [Page 10]
Internet-Draft GROUPKEY-PUSH ACK October 2013
6. Security Considerations
There are three areas of security considerations to consider: the
protection of the GROUPKEY-PUSH ACK message, whether the GM should
transmit a GROUPKEY-PUSH ACK, and whether a KS should accept a
GROUPKEY-PUSH ACK.
6.1. Protection of the GROUPKEY-PUSH ACK
The GROUPKEY-PUSH ACK message is an ISAKMP [RFC2408] message.
Message authentication and Man-in-the-Middle Attack Protection is
provided by the inclusion of a HASH payload, which includes the
output of an HMAC computation (PRF-HMAC-SHA-256) over the bytes of
the message.
When the value of REKEY_ACK_KEK is specified, because the KEK is a
group secret impersonation of a victim GM by another authorized GM is
possible. However, security considerations of the impersonation are
limited to a false claim that a victim GM has received a GROUPKEY-
PUSH when the victim GM has in fact not received it (e.g., because an
active attacker has discarded the GROUPKEY-PUSH). If a GCKS policy
includes sending retransmissions of the GROUPKEY-PUSH message to that
victim GM, then the victim GM may not receive replacement security
associations. However, this adds no additional threats over a use
case where the GROUPKEY-PUSH ACK is not deployed and GROUPKEY-PUSH
messages are withheld from a victim GM by an active attacker. These
threats can be mitigated by using a value of REKEY_ACK_LKH, due to
the use of a secret pairwise key shared between the GCKS and
individual GM.
Confidentiality is not provided for the GROUPKEY-PUSH ACK message.
The contents of the message can be observed by a passive attacker,
which includes the hash value, the sequence number of in the
GROUPKEY-PUSH message to which it is acknowledging receipt, and the
identity of the GM. Observation of a hash value or set of hash
values will not compromise the hash key. The identity of the GM is
also available to the passive attacker as the source IP address of
the packet. The sequence number does reveal the sequence number that
was included in the GROUPKEY-PUSH, which was previously not available
to the attacker. However, the attacker is assumed to not be in
possession of the key used to encrypt the message, and thus cannot
create a spoofed GROUPKEY-PUSH message. Therefore, there is no
direct value that the attacker derives from the knowledge of the
sequence number.
Weis, et al. Expires April 13, 2014 [Page 11]
Internet-Draft GROUPKEY-PUSH ACK October 2013
6.2. Transmitting a GROUPKEY-PUSH ACK
A GM transmits an ACK only when the policy of the most recently
received SA KEK includes a request by the GCKS for ACKs, and only is
returned after processing the GROUPKEY-PUSH message according to
Section 4.4 of [RFC6407]. In other words, the form of the GROUPKEY-
PUSH message will have been validated, replay protection completed,
and the digital signature verified as being genuine. Therefore, the
threats of a GM responding to a spoofed or resent GROUPKEY-PUSH
message, and the possibility of the GM being used to propagate a
Distributed Denial of Service (DDoS) attack on a GCKS are mitigated.
For more information, see the security considerations of a GROUPKEY-
PUSH message described in Section 7.3 of [RFC6407].
6.3. Receiving a GROUPKEY-PUSH ACK
A KS receiving ACK messages will follow the validation steps
described in Section 5 before interpreting the contents of the
message. The GCKS will then be sure to operate only on messages that
have been sent by an authorized GM.
A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACK messages from
each GM to which it was sent. That is, needs to ensure it has
sufficient resources (e.g., receive queue size) so that it does not
unnecessarily drop ACK messages. An GCKS should be aware that a
large number of replayed or invalid GROUPKEY-PUSH messages could be
addressed to it. However, this is no worse a threat than if it
received a large number of other types of replayed or invalid ISAKMP
messages containing a HASH payload.
GCKS implementations SHOULD keep a record (e.g., a hash value) of
recently received GROUPKEY-PUSH Acknowledgment messages and reject
duplicate messages prior to performing cryptographic operations.
This enables an early discard of the replayed messages.
How a GCKS processes the serial number and identity included in an
ACK message is a matter of local policy and is outside the scope of
this memo.
Weis, et al. Expires April 13, 2014 [Page 12]
Internet-Draft GROUPKEY-PUSH ACK October 2013
7. IANA Considerations
The following additions are made to the GDOI Payloads [GDOI-REG]
registry.
A new attribute is added to the SA KEK Payload Values - KEK
Attributes registry. The ID Class name is KEK_ACK_REQUESTED with a
value of TBD-1, and is a Basic attribute. Values for this attribute
are shown in the following table. The terms Reserved, Unassigned,
and Private Use are to be applied as defined in [RFC5226]. The
registration procedure is Specification Required.
Value Type
------- ----
0 Reserved
1 REKEY_ACK_KEK
2 REKEY_ACK_LKH
3-128 Unassigned
129-255 Private Use
A new registry is added to GDOI Payloads [GDOI-REG] defining
Additional Exchange values for the GDOI DOI. The registration
procedure is Specification Required. The terms Reserved and
Unassigned are to be applied as defined in [RFC5226].
Value Phase Reference
---- ----- ---------
GROUPKEY-PULL 32 RFC 6407
GROUPKEY-PUSH 33 RFC 6407
Reserved 34
GROUPKEY-PUSH-ACK 35 RFC XXXX
Unassigned 36-239
[Note to RFC Editor: Please replace XXXX with the number of the RFC
resulting from this memo, and delete this note.]
Weis, et al. Expires April 13, 2014 [Page 13]
Internet-Draft GROUPKEY-PUSH ACK October 2013
8. Acknowledgements
Mike Hamada provided many useful technical and editorial comments and
suggestions for improvement.
Weis, et al. Expires April 13, 2014 [Page 14]
Internet-Draft GROUPKEY-PUSH ACK October 2013
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
9.2. Informative References
[GDOI-REG]
Internet Assigned Numbers Authority, "Group Domain of
Interpretation (GDOI) Payload Type Values", IANA Registry,
December 2004, <http://www.iana.org/assignments/
gdoi-payloads/gdoi-payloads.xml>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[SP800-108]
Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", United States of America,
National Institute of Science and Technology, NIST Special
Publication 800-108, November 2008, <http://www.iana.org/
assignments/gdoi-payloads/gdoi-payloads.xml>.
Weis, et al. Expires April 13, 2014 [Page 15]
Internet-Draft GROUPKEY-PUSH ACK October 2013
Authors' Addresses
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-408-526-4796
Email: bew@cisco.com
Umesh Mangla
Juniper Networks Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
Phone: +1-408-936-1022
Email: umangla@juniper.net
Nilesh Maheshwari
Juniper Networks Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
Phone: +1-408-936-7570
Email: nileshm@juniper.net
Thomas Karl
Deutsche Telekom
Landgrabenweg 151
Bonn, 53227
Germany
Phone: +49 221 91611582
Email: thomas.karl@detecon.com
Weis, et al. Expires April 13, 2014 [Page 16]