draft-ietf-msec-gdoi-update-07.txt   draft-ietf-msec-gdoi-update-08.txt 
MSEC Working Group B. Weis MSEC Working Group B. Weis
Internet-Draft S. Rowles Internet-Draft S. Rowles
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: April 28, 2011 T. Hardjono Expires: September 15, 2011 T. Hardjono
MIT MIT
October 25, 2010 March 14, 2011
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-07 draft-ietf-msec-gdoi-update-08
Abstract Abstract
This document describes an updated version of the Group Domain of This document describes an updated version of the Group Domain of
Interpretation (GDOI) protocol specified in RFC 3547. The GDOI Interpretation (GDOI) protocol specified in RFC 3547. The GDOI
provides group key management to support secure group communications provides group key management to support secure group communications
according to the architecture specified in RFC 4046. The GDOI according to the architecture specified in RFC 4046. The GDOI
manages group security associations, which are used by IPsec and manages group security associations, which are used by IPsec and
potentially other data security protocols. potentially other data security protocols.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. GDOI Applications . . . . . . . . . . . . . . . . . . . . 6 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 6
1.4. Extending GDOI . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Forward and Backward Access Control . . . . . . . . . . . 7
2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 9 2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 8
2.1. ISAKMP Phase 1 protocol . . . . . . . . . . . . . . . . . 9 2.1. ISAKMP Phase 1 protocol . . . . . . . . . . . . . . . . . 8
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 10 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . . 12 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 11
3.4. Receiver Operations . . . . . . . . . . . . . . . . . . . 13 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13
3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 13
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 15 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16
4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 16 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 17
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 16 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17
4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 16 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17
4.4. Group Member Operations . . . . . . . . . . . . . . . . . 17 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 18 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 20
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 18 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
5.2. Security Association Payload . . . . . . . . . . . . . . . 18 5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 20 5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 22
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 26 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 28
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 29 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 33 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 41 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 43
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 43 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 46
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 45 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 48
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 46 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 49
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 48 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 51
7.4. Forward and Backward Access Control . . . . . . . . . . . 52
7.5. Derivation of keying material . . . . . . . . . . . . . . 54
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
8.1. Additions to current registries . . . . . . . . . . . . . 50 8.1. Additions to current registries . . . . . . . . . . . . . 55
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 50 8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 55
8.3. Cleanup of existing registries . . . . . . . . . . . . . . 57
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.1. Normative References . . . . . . . . . . . . . . . . . . . 53 10.1. Normative References . . . . . . . . . . . . . . . . . . . 60
10.2. Informative References . . . . . . . . . . . . . . . . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Alternate GDOI Phase 1 protocols . . . . . . . . . . 58 Appendix A. Extending GDOI . . . . . . . . . . . . . . . . . . . 65
A.1. IKEv2 Exchange . . . . . . . . . . . . . . . . . . . . . . 58 A.1. Alternate GDOI Phase 1 protocols . . . . . . . . . . . . . 65
A.2. KINK Protocol . . . . . . . . . . . . . . . . . . . . . . 58 A.2. Supporting new SA TEK types . . . . . . . . . . . . . . . 66
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 59 Appendix B. GDOI Applications . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Appendix C. Significant Changes from RFC 3547 . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
Secure group and multicast applications require a method by which Secure group and multicast applications require a method by which
each group member shares common security policy and keying material. each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI), This document describes the Group Domain of Interpretation (GDOI),
which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group
key management system. The GDOI distributes security associations key management system. The GDOI distributes security associations
(SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and (SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and
potentially other data security protocols used in group applications. potentially other data security protocols used in group applications.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
and described more generally by the The Multicast Group Security and described more generally by the The Multicast Group Security
Architecture [RFC3740]. Architecture [RFC3740].
In this group key management model, the GDOI protocol participants In this group key management model, the GDOI protocol participants
are a "group controller/key server" (GCKS) and a group member (GM). are a "group controller/key server" (GCKS) and a group member (GM).
A group member contacts ("registers with") a GCKS to join the group. A group member contacts ("registers with") a GCKS to join the group.
During the registration mutual authentication and authorization are During the registration mutual authentication and authorization are
achieved, after which the GCKS distributes current group policy and achieved, after which the GCKS distributes current group policy and
keying material to the group member over an authenticated and keying material to the group member over an authenticated and
encrypted session. The GCKS may also initiate contact ("rekeys") encrypted session. The GCKS may also initiate contact ("rekeys")
group members to provide updates to group policy. with group members to provide updates to group policy.
ISAKMP defines two "phases" of negotiation (p.16 of [RFC2408]). A ISAKMP defines two "phases" of negotiation (p.16 of [RFC2408]). A
Phase 1 security association provides mutual authentication and Phase 1 security association provides mutual authentication and
authorization, and a security association that is used by the authorization, and a security association that is used by the
protocol participants to execute a phase 2 exchange. This document protocol participants to execute a phase 2 exchange. This document
incorporates (i.e., uses but does not re-define) the Phase 1 security incorporates (i.e., uses but does not re-define) the Phase 1 security
association definition from the Internet DOI [RFC2407], [RFC2409]. association definition from the Internet DOI [RFC2407], [RFC2409].
Phase 1 security association types other than ISAKMP are possible, Phase 1 security association types other than ISAKMP are possible,
and are noted in Appendix A. Requirements of those phase 1 security and are noted in Appendix A. Requirements of those phase 1 security
associations are specified in Section 2. The GDOI includes two new associations are specified in Section 2. The GDOI includes two new
skipping to change at page 4, line 50 skipping to change at page 4, line 50
1. The GROUPKEY-PULL registration protocol exchange. This exchange 1. The GROUPKEY-PULL registration protocol exchange. This exchange
uses "pull" behavior since the member initiates the retrieval of uses "pull" behavior since the member initiates the retrieval of
these SAs from a GCKS. It is protected by an ISAKMP phase 1 these SAs from a GCKS. It is protected by an ISAKMP phase 1
protocol, as described above. At the culmination of a GROUPKEY- protocol, as described above. At the culmination of a GROUPKEY-
PULL exchange, an authorized group member has received and PULL exchange, an authorized group member has received and
installed a set of SAs that represent group policy, and it is installed a set of SAs that represent group policy, and it is
ready to participate in secure group communications. ready to participate in secure group communications.
2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is 2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is
a datagram initiated ("pushed") by the GCKS, usually delivered to a datagram initiated ("pushed") by the GCKS, usually delivered to
group members using a IP multicast address. The rekey protool is group members using a IP multicast address. The rekey protocol
an ISAKMP protocol, where cryptographic policy and keying is an ISAKMP protocol, where cryptographic policy and keying
material ("Re-key SA") is included in the group policy material ("Re-key SA") is included in the group policy
distributed by the GCKS in the GROUPKEY-PULL exchange. At the distributed by the GCKS in the GROUPKEY-PULL exchange. At the
culmination of a GROUPKEY-PUSH exchange the key server has sent culmination of a GROUPKEY-PUSH exchange the key server has sent
group policy to all authorized group members, allowing receiving group policy to all authorized group members, allowing receiving
group members to participate in secure group communications. If group members to participate in secure group communications. If
a group management method is included in group policy (as a group management method is included in group policy (as
described in Section 1.5.1), at the conclusion of the GROUPKEY- described in Section 7.4), at the conclusion of the GROUPKEY-PUSH
PUSH exchange some members of the group may have been de- exchange some members of the group may have been de-authorized
authorized and no longer able to participate in the secure group and no longer able to participate in the secure group
communications. communications.
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| | | |
| +--------------------+ | | +--------------------+ |
| +------>| GDOI GCKS |<------+ | | +------>| GDOI GCKS |<------+ |
| | +--------------------+ | | | | +--------------------+ | |
| | | | | | | | | |
| GROUPKEY-PULL | GROUPKEY-PULL | | GROUPKEY-PULL | GROUPKEY-PULL |
| PROTOCOL | PROTOCOL | | PROTOCOL | PROTOCOL |
skipping to change at page 5, line 41 skipping to change at page 5, line 41
| +-Data Security Protocol (e.g., ESP)-+ | | +-Data Security Protocol (e.g., ESP)-+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Although the GROUPKEY-PUSH protocol specified by this document can be Although the GROUPKEY-PUSH protocol specified by this document can be
used to refresh the Re-key SA protecting the GROUPKEY-PUSH protocol, used to refresh the Re-key SA protecting the GROUPKEY-PUSH protocol,
the most common use of GROUPKEY-PUSH is to establish keying material the most common use of GROUPKEY-PUSH is to establish keying material
and policy for a data security protocol. and policy for a data security protocol.
In summary, GDOI is a group security association management protocol: In summary, GDOI is a group security association management protocol:
All GDOI messages are used to create, maintain, or delete security all GDOI messages are used to create, maintain, or delete security
associations for a group. As described above, these security associations for a group. As described above, these security
associations protect one or more data security protocal SAs, a Re-key associations protect one or more data security protocol SAs, a Re-key
SA, and/or other data shared by group members for multicast and SA, and/or other data shared by group members for multicast and
groups security applications. groups security applications.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The following key terms are used throughout this document. The following key terms are used throughout this document.
Data-Security SA. The security policy distributed by a GDOI GCKS Data-Security SA. The security policy distributed by a GDOI GCKS
describing traffic that is expected to be protected by group describing traffic that is expected to be protected by group
members. This document described the distribution of IPsec AH and members. This document described the distribution of IPsec AH
ESP Data-Security SAs. and ESP Data-Security SAs.
GCKS. A Group Controller/Key Server [RFC3740] that defines group Group Controller/Key Server A device that defines group policy and
policy and distributes keys for that policy. distributes keys for that policy.[RFC3740]
Group Member. An authorized member of a secure group, sending and/or Group Member. An authorized member of a secure group, sending and/or
receiving IP packets related to the group. receiving IP packets related to the group.
GROUPKEY-PULL. A protocol used by a GDOI Group Member to requst GROUPKEY-PULL. A protocol used by a GDOI Group Member to request
group policy and keying material. group policy and keying material.
GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates
of group policy and keying material to authorized group members. of group policy and keying material to authorized group
members.
Key Encrypting Key (KEK). The symmetric cipher key used to protect Key Encrypting Key. The symmetric cipher key used to protect the
the GROUPKEY-PUSH message. GROUPKEY-PUSH message.
Logical Key Hierarchy (LKH). A group management method defined in Logical Key Hierarchy). A group management method defined in Section
Section 5.4 of [RFC2627]. 5.4 of [RFC2627].
Re-key SA. The security policy protecting a GROUPKEY-PUSH protocol. Re-key SA. The security policy protecting a GROUPKEY-PUSH protocol.
Traffic Encryption Key (TEK). The symmetric cipher key used to Traffic Encryption Key. The symmetric cipher key used to protect a
protect a data security protocol (e.g., IPsec ESP). data security protocol (e.g., IPsec ESP).
1.3. GDOI Applications 1.3. Acronyms and Abbreviations
GDOI can be used to distribute keys for several secure multicast The following acronyms and abbreviations are used throughout this
applications, where different appliacations have different key document.
management requirements. This section outlines two example ways that
GDOI can be used. Other examples can be found in Section 10 of
[HD03].
A simple application is secure delivery of periodic multicast content AH IP Authentication Header
over an organization's IP network, perhaps a multicast video
broadcast. Assuming the content delivery timeframe is bounded and
the group membership is not expected to change over time, there is no
need for group policy to include a GROUPKEY-PUSH exchange, and
there's no need for the GCKS to distribute a Re-key SA. Thus, the
GDOI GCKS may only need to distribute a single set of Data-Security
SAs to protect the time-bounded broadcast.
In contrast, a persistent IP multicast application (e.g., stock- ATD Activation Time Delay
ticker delivery service) may have many group members, where the group
membership changes over time. A periodic change of Data-security SAs
may be desirable, and the potential for change in group membership
requires the use of a group management method enabling de-
authorization of group members. The GDOI GCKS will distribute the
current set of Data-Security SAs and a Re-key SA to registering group
members. It will then deliver regularly-scheduled GROUPKEY-PUSH
protocol delivering the new SAs for the group. Additionally, the
group membership on the GCKS may be frequently adjusted, which will
result in GROUPKEY-PUSH exchange delivering a new Rekey SAs protected
by a group management method. Each GROUPKEY-PUSH may include Data-
security SAs and/or a Rekey SA.
In each example the relevant policy is defined on the GCKS and DOI Domain of Interpretation
relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH
protocols. Specific policy choices configured by the GCKS
administrator depends on each application.
1.4. Extending GDOI DTD Deactivation Time Delay
ESP IP Encapsulating Security Payload
Not all secure multicast or multimedia applications can use IPsec ESP GCKS Group Controller/Key Server
or AH. Many Real Time Transport Protocol applications, for example,
require security above the IP layer to preserve RTP header
compression efficiencies and transport-independence [RFC3550].
Alternatively, GDOI can distribute message authentication code (MAC)
policy and keys for legacy applications that have defined their own
security associations [I-D.weis-gdoi-mac-tek].
In order to add a new data security protocol, a new RFC MUST specify GDOI Group Domain of Interpretation
the data-security SA parameters conveyed by GDOI for that security
protocol; these parameters are listed in Section 5.5.2 of this
document.
Data security protocol SAs MUST protect group traffic. GDOI provides GAP Group Associated Policy Payload
no restriction on whether that group traffic is transmitted as
unicast or multicast packets.
1.5. Forward and Backward Access Control GM Group Member
Through GROUPKEY-PUSH, the GDOI supports group management methods IV Initialization Vector
such as LKH (section 5.4 of [RFC2627]) that have the property of
denying access to a new group key by a member removed from the group
(forward access control) and to an old group key by a member added to
the group (backward access control). An unrelated notion to PFS,
"forward access control" and "backward access control" have been
called "perfect forward security" and "perfect backward security" in
the literature [RFC2627].
Group management algorithms providing forward and backward access KD Key Download Payload
control other than LKH have been proposed in the literature,
including OFT [OFT] and Subset Difference [NNL]. These algorithms
could be used with GDOI, but are not specified as a part of this
document.
1.5.1. Forward Access Control Requirements KEK Key Encryption Key
When group membership is altered using a group management algorithm LKH Lock Key Hierarchy
new Data-security SAs are usually also needed. New SAs ensure that
members who were denied access can no longer participate in the
group.
If forward access control is a desired property of the group, new SA Security Association
Data-security SAs MUST NOT be included in a GROUPKEY-PUSH message
which changes group membership. This is required because the new
Data-security SAs are not protected with the new KEK. Instead, two
sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first
changing the KEK, and the second (protected with the new KEK)
distributing the new Data-security SAs.
Note that in the above sequence, although the new KEK can effectively SAK SA KEK Payload
deny access to the group to some group members they will be able to
view the new KEK policy. If forward access control policy for the
group includes keeping the KEK policy secret as well as the KEK
itself secret, then two GROUPKEY-PUSH messages changing the KEK must
occur before the new Data-security SAs are transmitted.
If other methods of using LKH or other group management algorithms SEQ Sequence Number Payload
are added to GDOI, those methods MAY remove the above restrictions
requiring multiple GROUPKEY-PUSH messages, providing those methods SAT SA TEK Payload
specify how forward access control policy is maintained within a
single GROUPKEY-PUSH message. SID Sender-ID
TEK Traffic Encryption Key
2. GDOI Phase 1 protocol 2. GDOI Phase 1 protocol
The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be
protected by a "phase 1" protocol. The "phase 1" protocol can be any protected by a "phase 1" protocol. The "phase 1" protocol can be any
protocol which provides for the following protections: protocol which provides for the following protections:
o Peer Authentication o Peer Authentication
o Confidentiality o Confidentiality
skipping to change at page 10, line 31 skipping to change at page 9, line 31
participant to perpetrate a man-in-the-middle attack between a group participant to perpetrate a man-in-the-middle attack between a group
member and a GCKS [MP04]. member and a GCKS [MP04].
3.2. Messages 3.2. Messages
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a
which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH
payloads. When using the Phase 1 defined in this document, SKEYID_a payloads. When using the Phase 1 defined in this document, SKEYID_a
is derived according to [RFC2409]. As with the IKEv1 HASH payload is derived according to [RFC2409]. As with the IKEv1 HASH payload
generation (Section 5.5 of [RFC2409], each GROUPKEY-PULL message generation (Section 5.5 of [RFC2409], each GROUPKEY-PULL message
hashes a uniquely defined set of values. Nonces permute the HASH and hashes a uniquely defined set of values (described below). Nonces
provide some protection against replay attacks. Replay protection is permute the HASH and provide some protection against replay attacks.
important to protect the GCKS from attacks that a key management Replay protection is important to protect the GCKS from attacks that
server will attract. a key management server will attract.
The GROUPKEY-PULL uses nonces to guarantee "liveness", or against The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as
replay of a recent GROUPKEY-PULL message. The replay attack is only against replay of a recent GROUPKEY-PULL message. The replay attack
useful in the context of the current Phase 1. If a GROUPKEY-PULL is only possible in the context of the current Phase 1. If a
message is replayed based on a previous Phase 1, the HASH calculation GROUPKEY-PULL message is replayed based on a previous Phase 1, the
will fail due to a wrong SKEYID_a. The message will fail processing HASH calculation will fail due to a wrong SKEYID_a. The message will
before the nonce is ever evaluated. In order for either peer to get fail processing before the nonce is ever evaluated.
the benefit of the replay protection, it must postpone as much
processing as possible until it receives the message in the protocol
that proves the peer is live. For example, the Responder MUST NOT
adjust its internal state (e.g., keeping a record of the Initiator)
until it receives a message with Nr included properly in the HASH
payload.
Nonces require an additional message in the protocol exchange to In order for either peer to get the benefit of the replay protection,
ensure that the GCKS does not add a group member until it proves it must postpone as much processing as possible until it receives the
liveliness. The GROUPKEY-PULL member-initiator expects to find its message in the protocol that proves the peer is live. For example,
nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL the GCKS MUST NOT adjust its internal state (e.g., keeping a record
GCKS responder expects to see its nonce, Nr, in the HASH of a of the GM) until it receives a message with Nr included properly in
returned message before providing group-keying material as in the the HASH payload. This requirement ensures that replays of GDOI
following exchange. messages will not cause the GCKS to change the state of the group
until it has confirmation that the initiating group member is live.
Initiator (Member) Responder (GCKS) Group Member GCKS
------------------ ---------------- ------------ ----
HDR*, HASH(1), Ni, ID --> HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA <-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) --> HDR*, HASH(3) [,GAP] -->
<-- HDR*, HASH(4), [SEQ,] KD <-- HDR*, HASH(4), [SEQ,] KD
Hashes are computed as follows: * Protected by the Phase 1 SA, encryption occurs after HDR
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
message identifier (M-ID) as in IKEv1.
Hashes are computed in the manner described within RFC 2409. Each
HASH computation (shown below) is a prf over the message id (M-ID)
from the ISAKMP header concatenated with the entire message that
follows the hash including all payload headers, but excluding any
padding added for encryption. The GM expects to find its nonce, Ni,
in the HASH of a returned message. And the GCKS expects to see its
nonce, Nr, in the HASH of a returned message. HASH(2), HASH(3), and
HASH(4) also include nonce values previously passed in the protocol
(i.e., Ni or Nr minus the payload header). The nonce passed in Ni is
represented as Ni_b, and the nonce passed in Nr is represented as
Nr_b. The HASH payloads prove that the peer has the Phase 1 secret
(SKEYID_a) and the nonce for the exchange identified by message id,
M-ID.
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ | ] KD) HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD)
* Protected by the Phase 1 SA, encryption occurs after HDR In addition to the Nonce and HASH payloads, the GM identifies the
group it wishes to join through the ISAKMP ID payload.
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a The GCKS informs the member of the cryptographic policies of the
message identifier (M-ID) as in IKEv1. Note that nonces are included group in the SA payload, which describes the DOI, KEK and/or TEK
in the first two messages, with the GCKS returning only the SA policy keying material, authentication transforms, and other group policy.
payload before liveliness is proven. The HASH payloads [RFC2409] The SPIs are also determined by the GCKS and downloaded in the SA
prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce payload chain (see Section 5.2). The SA KEK attribute contains the
for the exchange identified by message id, M-ID. Once liveliness is ISAKMP cookie pair for the Re-key SA, which is not negotiated but
established, the last message completes the real processing of downloaded. Each SA TEK attribute contains a SPI as defined in
downloading the KD payload. Section 5.5 of this document.
In addition to the Nonce and HASH payloads, the member-initiator After receiving and parsing the SA payload, the GM responds with an
identifies the group it wishes to join through the ISAKMP ID payload. acknowledgement message proving its liveness. It optionally includes
The GCKS responder informs the member of the current value of the a GAP payload requesting resources.
sequence number in the SEQ payload; the sequence number provides
anti-replay state associated with a KEK. The SEQ payload has no
other use, and is omitted from the GROUPKEY_PULL exchange when a KEK
attribute is not included in the SA payload.
When a SEQ payload is included in the GROUPKEY-PULL exchange, it The GCKS informs the GM of the value of the sequence number in the
includes the most recently used sequence number for the group. At SEQ payload. This sequence number provides anti-replay state
the conclusion of a GROUPKEY-PULL exchange, the initiating group associated with a KEK, and its knowledge ensure that the GM will not
member MUST NOT accept any rekey message with both the KEK attribute accept GROUPKEY-PULL messages sent prior to the GM joining the group.
SPI value and a sequence number less than or equal to the one The SEQ payload has no other use, and is omitted from the
received during the GROUPKEY-PULL. When the first group member GROUPKEY_PULL exchange when a KEK attribute is not included in the SA
payload. When a SEQ payload is included in the GROUPKEY-PULL
exchange, it includes the most recently used sequence number for the
group. At the conclusion of a GROUPKEY-PULL exchange, the initiating
group member MUST NOT accept any rekey message with both the KEK
attribute SPI value and a sequence number less than or equal to the
one received during the GROUPKEY-PULL. When the first group member
initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence
Number of zero, since no GROUPKEY-PUSH messages have yet been sent. Number of zero, since no GROUPKEY-PUSH messages have yet been sent.
Note the sequence number increments only with GROUPKEY-PUSH messages. Note the sequence number increments only with GROUPKEY-PUSH messages.
The GROUPKEY-PULL exchange distributes the current sequence number to The GROUPKEY-PULL exchange distributes the current sequence number to
the group member. the group member. The sequence number resets to a value of one with
the usage of a new KEK attribute. Thus the first packet sent for a
The sequence number resets to a value of one with the usage of a new given Rekey SA will have a Sequence Number of 1. The sequence number
KEK attribute. Thus the first packet sent for a given Rekey SA will increments with each successive rekey.
have a Sequence Number of 1. The sequence number increments with
each successive rekey.
The GCKS responder informs the member of the cryptographic policies The GCKS always returns a KD payload containing keying material to
of the group in the SA payload, which describes the DOI, KEK and/or the GM. If a Re-key SA is defined in the SA payload, then KD will
TEK keying material, and authentication transforms. The SPIs are contain the KEK; if one or more Data-security SAs are defined in the
also determined by the GCKS and downloaded in the SA payload chain SA payload, KD will contain the TEKs.
(see Section 5.2). The SA KEK attribute contains the ISAKMP cookie
pair for the Re-key SA, which is not negotiated but downloaded. The
SA TEK attribute contains a SPI as defined in Section 5.5 of this
document. The second message downloads this SA payload. If a Re-key
SA is defined in the SA payload, then KD will contain the KEK; if one
or more Data-security SAs are defined in the SA payload, KD will
contain the TEKs. This is useful if there is an initial set of TEKs
for the particular group and can obviate the need for future TEK
GROUPKEY-PUSH messages (described in section 4).
3.2.1. ISAKMP Header Initialization 3.2.1. ISAKMP Header Initialization
Cookies are used in the ISAKMP header to identify a particular GDOI Cookies are used in the ISAKMP header to identify a particular GDOI
session. The GDOI GROUPKEY-PULL exchange uses cookies according to session. The GDOI GROUPKEY-PULL exchange uses cookies according to
ISAKMP [RFC2408]. ISAKMP [RFC2408].
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange. The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of
[RFC2408]). [RFC2408]).
3.3. Initiator Operations 3.3. Group Member Operations
Before a group member (GDOI initiator) contacts the GCKS, it must Before a GM contacts the GCKS, it must determine the group identifier
determine the group identifier and acceptable Phase 1 policy via an and acceptable Phase 1 policy via an out-of-band method. Phase 1 is
out-of-band method. Phase 1 is initiated using the GDOI DOI in the initiated using the GDOI DOI in the SA payload. Once Phase 1 is
SA payload. Once Phase 1 is complete, the initiator state machine complete, the GM state machine moves to the GDOI protocol.
moves to the GDOI protocol.
To construct the first GDOI message the initiator chooses Ni and To construct the first GDOI message the GM chooses Ni and creates a
creates a nonce payload, builds an identity payload including the nonce payload, builds an identity payload including the group
group identifier, and generates HASH(1). identifier, and generates HASH(1).
Upon receipt of the second GDOI message, the initiator validates Upon receipt of the second GDOI message, the GM validates HASH(2),
HASH(2), extracts the nonce Nr, and interprets the SA payload. The extracts the nonce Nr, and interprets the SA payload. The SA payload
SA payload contains policy describing the security protocol and contains policy describing the security protocol and cryptographic
cryptographic protocols used by the group. This policy describes the protocols used by the group. This policy describes the Re-key SA (if
Re-key SA (if present), Data-security SAs, and other group policy. present), Data-security SAs, and other group policy. If the policy
If the policy in the SA payload is acceptable to the initiator, it in the SA payload is acceptable to the GM, it continues the protocol.
continues the protocol. Otherwise, the GM SHOULD tear down the Phase 1 session after first
notifying the GCKS that it is doing so. If a Data-security SA
describes the use of a counter mode cipher, the GM determines whether
it requires more than one Sender-ID (SID) (see Section 3.5). If so,
it includes a GAP payload indicating how many SID values it requires.
The initiator constructs the third GDOI message by creating HASH(3). When constructing the third GDOI message, it first reviews each Data-
security SA given to it. If any include a cipher counter mode, it
needs to request for one or more Sender-IDs for its exclusive use
within the counter mode nonce. Do to this, the GM will include a GAP
payload with its request, as described in the Section 5.4 section of
this document. The GM the completes construction of the third GDOI
message by creating HASH(3).
Upon receipt of the fourth GDOI message, the initiator validates Upon receipt of the fourth GDOI message, the GM validates HASH(4).
HASH(4).
If SEQ payload is present, the sequence number in the SEQ payload If the SEQ payload is present, the sequence number in the SEQ payload
must be checked against any previously received sequence number for must be checked against any previously received sequence number for
this group. If it is less than the previously received number, it this group. If it is less than the previously received number, it
should be considered stale and ignored. This could happen if two should be considered stale and ignored.
GROUPKEY-PULL messages happened in parallel, and the sequence number
changed between the times the results of two GROUPKEY-PULL messages
were returned from the GCKS.
The initiator interprets the KD key packets, where each key packet The GM interprets the KD key packets, where each key packet includes
includes the keying material for SAs distributed in the SA payload. the keying material for SAs distributed in the SA payload. Keying
Keying material is matched by comparing the SPIs in the key packets material is matched by comparing the SPIs in the key packets to SPIs
to SPIs previously sent in the SA payloads. Once TEK keys and policy previously sent in the SA payloads. Once TEK keys and policy are
are matched, the initiator provides them to the data security matched, the GM provides them to the data security subsystem, and it
subsystem, and it is ready to send or receive packets matching the is ready to send or receive packets matching the TEK policy. If this
TEK policy. If this group has a KEK, the KEK policy and keys are group has a KEK, the KEK policy and keys are marked as ready for use,
marked as ready for use, and the initiator knows to expect the and the GM knows to expect the sequence number reset to 1 with the
sequence number reset to 1 with the next Rekey SA, which will be next Rekey SA, which will be encrypted with the new KEK attribute.
encrypted with the new KEK attribute. The initiator is now ready to The GM is now ready to receive GROUPKEY-PUSH messages.
receive GROUPKEY-PUSH messages.
If the KD payload included an LKH array of keys, the initiator takes If the KD payload included an LKH array of keys, the GM takes the
the last key in the array as the group KEK. The array is then stored last key in the array as the group KEK. The array is then stored
without further processing. without further processing.
3.4. Receiver Operations 3.4. GCKS Operations
The GCKS (responder) passively listens for incoming requests from The GCKS passively listens for incoming requests from group members.
group members. The Phase 1 authenticates the group member and sets The Phase 1 authenticates the group member and sets up the secure
up the secure session with them. session with them.
Upon receipt of the first GDOI message the GCKS validates HASH(1), Upon receipt of the first GDOI message the GCKS validates HASH(1),
extracts the Ni and group identifier in the ID payload. It verifies extracts the Ni and group identifier in the ID payload. It verifies
that its database contains the group information for the group that its database contains the group information for the group
identifier. identifier, and that the GM is authorized to participate in the
group.
The GCKS constructs the second GDOI message, including a nonce Nr, The GCKS constructs the second GDOI message, including a nonce Nr,
and the policy for the group in an SA payload, followed by SA GAP, SA and the policy for the group in an SA payload, followed by SA KEK,
KEK, and/or SA TEK payloads according to the GCKS policy. (See GAP, and/or SA TEK payloads according to the GCKS policy. (See
Section 5.2.1 for details on how the GCKS chooses which payloads to Section 5.2.1 for details on how the GCKS chooses which payloads to
send.) send.)
Upon receipt of the third GDOI message the GCKS validates HASH(3). Upon receipt of the third GDOI message the GCKS validates HASH(3).
If the message includes a GAP payload, it caches the requests
included in that payload for use of constructing the fourth GDOI
message.
The GCKS constructs the fourth GDOI message, including the SEQ The GCKS constructs the fourth GDOI message, including the SEQ
payload (if the GCKS sends rekey messages), and the KD payload payload (if the GCKS sends rekey messages), and the KD payload
containing keys corresponding to policy previously sent in the SA TEK containing keys corresponding to policy previously sent in the SA TEK
and SA KEK payloads. If a group management algorithm is defined as and SA KEK payloads. If a group management algorithm is defined as
part of group policy, the GCKS will first insert the group member part of group policy, the GCKS will first insert the group member
into the group management structure (e.g., a leaf in the LKH tree), into the group management structure (e.g., a leaf in the LKH tree),
and then create an LKH array of keys and include it in the KD and then create an LKH array of keys and include it in the KD
payload. The first key in the array is associated with the group payload. The first key in the array is associated with the group
member leaf node, followed by each LKH node above it in the tree, member leaf node, followed by each LKH node above it in the tree,
culminating with the root node (which is also the KEK). culminating with the root node (which is also the KEK). If one or
more Data-Security SAs distributed in the SA payload included a
counter mode of operation, the GCKS includes at least one SID value
in the KD payload, and possibly more depending on a request received
in the third GDOI message.
3.5. Counter-modes of operation
Several new counter-based modes of operation have been specified for
ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309],
AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These
counter-based modes require that no two senders in the group ever
send a packet with the same Initialization Vector (IV) using the same
cipher key and mode. This requirement is met in GDOI when the
following requirements are met:
o The GCKS distributes a unique key for each Data-Security SA.
o The GCKS uses the method described in [RFC6054], which assigns
each sender a portion of the IV space by provisioning each sender
with one or more unique SID values.
When at least one Data-Security SAs included in the group policy
includes a counter-mode, the GCKS automatically allocates and
distributes one SID to each group member acting in the role of sender
on the Data-Security SA. The SID value is used exclusively by the
group member to which it was allocated. The group member uses the
same SID for each Data-Security SA specifying the use of a counter-
based mode of operation. A GCKS MUST distribute unique keys for each
Data-Security SA including a counter-based mode of operation in order
to maintain a unique key and nonce usage.
When a group member receives a Data-Security SA in a SA TEK payload
for which it is a sender, it can choose to request one or more SID
values. Requesting a value of 1 is not necessary since the GCKS will
automatically allocate exactly one to the sending group member. A
group member MUST request as many SIDs matching the number of
encryption modules in which it will be installing the TEKs in the
outbound direction. Alternatively, a group member MAY request more
than one SID and use them serially. This could be useful when it is
anticipated that the group member will exhaust their range of Data-
Security SA nonces using a single SID too quickly (e.g., before the
time-based policy in the TEK expires).
When group policy includes a counter-based mode of operation, a GCKS
SHOULD use the following method to allocate SID values, which ensures
that each SID will be allocated to just one group member.
1. A GCKS maintains an SID-counter, which records which SIDs that
have been allocated. SIDs are allocated sequentially, with the
first SID allocated to be zero.
2. Each time an SID is allocated, the current value of the counter
is saved and allocated to the group member. The SID-counter is
then incremented in preparation for the next allocation.
3. When the GCKS distributes an Data-Security SA specifying a
counter-based mode of operation, and a group member is a sender,
a group member may request a count of SIDs in a GAP payload.
When the GCKS receives this request, it increments the SID-
counter once for each requested SID, and distributes each SID
value to the group member.
4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange
originated by a sender, regardless of whether a group member had
previously contacted the GCKS. In this way, the GCKS does not
have a requirement of maintaining a record of which SID values it
had previously allocated to each group member. More importantly,
since the GCKS cannot reliably detect whether the group member
had sent data on the current group Data-Security SAs it does not
know what Data-Security counter-mode nonce values that a group
member has used. By distributing new SID values, the key server
ensures that each time a conforming group member installs a Data-
Security SA it will use a unique set of counter-based mode
nonces.
5. When the SID-counter maintained by the GCKS reaches its final SID
value, no more SID values can be distributed. Before
distributing any new SID values, the GCKS MUST delete the Data-
Security SAs for the group, followed by creation of new Data-
Security SAs, and resetting the SID-counter to its initial value.
6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data-
Security SAs and the Rekey SA for the group. This will result in
the group members initiating a new GROUPKEY-PULL exchange, in
which they will receive both new SID values and new Data-Security
SAs. The new SID values can safely be used because they are only
used with the new Data-Security SAs. Note that deletion of the
Rekey SA is necessary to ensure that group members receiving a
GROUPKEY-PUSH exchange before the re-register do not
inadvertently use their old SIDs with the new Data-Security SAs.
Using the method above, at no time can two group members use the same
IV values with the same Data-Security SA key.
4. GROUPKEY-PUSH Message 4. GROUPKEY-PUSH Message
GDOI sends control information securely using group communications. GDOI sends control information securely using group communications.
Typically this will be using IP multicast distribution of a GROUPKEY- Typically this will be using IP multicast distribution of a GROUPKEY-
PUSH message but it can also be "pushed" using unicast delivery if IP PUSH message but it can also be "pushed" using unicast delivery if IP
multicast is not possible. The GROUPKEY-PUSH message replaces a Re- multicast is not possible. The GROUPKEY-PUSH message replaces a Re-
key SA KEK or KEK array, and/or creates a new Data-security SA. key SA KEK or KEK array, and/or creates a new Data-security SA.
Member GCKS or Delegate GM GCKS
------ ---------------- -- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG <---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Re-key SA KEK; encryption occurs after HDR * Protected by the Re-key SA KEK; encryption occurs after HDR
HDR is defined below. The SEQ payload is defined in the Payloads HDR is defined below. The SEQ payload is defined in the Payloads
section. One or more D (Delete) payloads (further described in section. One or more D (Delete) payloads (further described in
Section 5.9) optionally specify the deletion of existing group Section 5.9) optionally specify the deletion of existing group
policy. The SA defines the policy (e.g., protection suite) and policy. The SA defines the group policy for replacement Re-key SA
attributes (e.g., SPI) for a replacement Re-key SA and/or Data- and/or Data-security SAs as described in the Payloads section, with
security SAs. KD is the key download payload as described in the the KD providing keying material for those SAs.
Payloads section.
The SIG payload includes a signature of a hash of the entire The SIG payload includes a signature of a hash of the entire
GROUPKEY-PUSH message (excepting the SIG payload bytes) before it has GROUPKEY-PUSH message (excepting the SIG payload bytes) before it has
been encrypted. The HASH is taken over the string 'rekey', the been encrypted. The HASH is taken over the string 'rekey', the
GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG
payload. The prefixed string ensures that the signature of the Rekey payload. The prefixed string ensures that the signature of the Rekey
datagram cannot be used for any other purpose in the GDOI protocol. datagram cannot be used for any other purpose in the GDOI protocol.
After the SIG payload is created using the signature of the above The SIG payload is created using the signature of the above hash,
hash, with the receiver verifying the signature using a public key with the receiver verifying the signature using a public key
retrieved in policy received by a GROUPKEY-PULL exchange, or retrieved in a previous GDOI exchange. The current KEK encryption
distributed in an earlier GROUPKEY-PUSH message. The current KEK key (also previously distributed in a GROUPKEY-PULL exchange or
encryption key (previously distributed in a GROUPKEY-PULL exchange or
GROUPKEY-PUSH message) encrypts all the payloads following the GROUPKEY-PUSH message) encrypts all the payloads following the
GROUPKEY-PUSH HDR. Note: The rationale for this order of operations GROUPKEY-PUSH HDR. Note: The rationale for this order of operations
is given in Section 7.3.5. is given in Section 7.3.5.
If the SA defines the use of a single KEK or an LKH KEK array, KD If the SA defines the use of a single KEK or an LKH KEK array, KD
MUST contain a corresponding KEK or KEK array for a new Re-key SA, MUST contain a corresponding KEK or KEK array for a new Re-key SA,
which has a new cookie pair. When the KD payload carries a new SA which has a new cookie pair. When the KD payload carries a new SA
KEK attribute (section 5.3), a Re-key SA is replaced with a new SA KEK attribute (section 5.3), a Re-key SA is replaced with a new SA
having the same group identifier (ID specified in message 1 of having the same group identifier (ID specified in message 1 of
section 3.2) and incrementing the same sequence counter, which is section 3.2) and incrementing the same sequence counter, which is
skipping to change at page 16, line 25 skipping to change at page 17, line 23
A signing key should not be used in more than one context (e.g., used A signing key should not be used in more than one context (e.g., used
for host authentication and also for message authentication). Thus, for host authentication and also for message authentication). Thus,
the GCKS SHOULD NOT use the same key to sign the SIG payload in the the GCKS SHOULD NOT use the same key to sign the SIG payload in the
GROUPKEY-PUSH message as was used for authentication in the GROUPKEY- GROUPKEY-PUSH message as was used for authentication in the GROUPKEY-
PULL exchange. PULL exchange.
4.2. ISAKMP Header Initialization 4.2. ISAKMP Header Initialization
Unlike ISAKMP or IKEv1, the cookie pair is completely determined by Unlike ISAKMP or IKEv1, the cookie pair is completely determined by
the GCKS. The cookie pair in the GDOI ISAKMP header identifies the the GCKS. The cookie pair in the GDOI ISAKMP header identifies the
Re- key SA to differentiate the secure groups managed by a GCKS. Re-key SA to differentiate the secure groups managed by a GCKS.
Thus, GDOI uses the cookie fields as an SPI. Thus, GDOI uses the cookie fields as an SPI.
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Flags MUST have the Encryption bit set according to [RFC2008, Section Flags MUST have the Encryption bit set according to [RFC2008, Section
3.1]. All other bits MUST be set to zero. 3.1]. All other bits MUST be set to zero.
Message ID MUST be set to zero. Message ID MUST be set to zero.
Length is according to ISAKMP (Section 3.1 of [RFC2408]). Length is according to ISAKMP (Section 3.1 of [RFC2408]).
4.3. GCKS Operations 4.3. GCKS Operations
GCKS or its delegate may initiate a Rekey message for one of several GCKS may initiate a Rekey message for one of several reasons, e.g.,
reasons, e.g., the group membership has changed or keys are due to the group membership has changed or keys are due to expire.
expire.
To begin the rekey datagram the GCKS builds an ISAKMP HDR with the To begin the rekey datagram the GCKS builds an ISAKMP HDR with the
correct cookie pair, and a SEQ payload that includes a sequence correct cookie pair, and a SEQ payload that includes a sequence
number which is one greater than the previous rekey datagram. If the number which is one greater than the previous rekey datagram. If the
message is using the new KEK attribute for the first time, the SEQ is message is using the new KEK attribute for the first time, the SEQ is
reset to 1 in this message. reset to 1 in this message.
An SA payload is then added. This is identical in structure and An SA payload is then added. This is identical in structure and
meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there
are changes to the KEK (including due to group members being are changes to the KEK (including due to group members being
skipping to change at page 17, line 22 skipping to change at page 18, line 20
A KD payload is then added. This is identical in structure and A KD payload is then added. This is identical in structure and
meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an
SA_KEK attribute was included in the SA payload then corresponding SA_KEK attribute was included in the SA payload then corresponding
KEK keys (or a KEK update array) is included. A KEK update array is KEK keys (or a KEK update array) is included. A KEK update array is
created by first determining which group members have been excluded, created by first determining which group members have been excluded,
and then generating new keys as necessary and distribute LKH update and then generating new keys as necessary and distribute LKH update
arrays sufficient to provide the new KEK to remaining group members arrays sufficient to provide the new KEK to remaining group members
(see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent (see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent
for each SA_TEK attribute included in the SA payload. for each SA_TEK attribute included in the SA payload.
In the penultimate step, the initiator hashes the string "rekey" In the penultimate step, the GCKS creates the SIG payload and adds it
followed by the key management message already formed. The hash is to the datagram.
signed, placed in a SIG payload and added to the datagram.
Lastly, the payloads following the HDR are encrypted using the Lastly, the payloads following the HDR are encrypted using the
current KEK encryption key. The datagram can now be sent. current KEK encryption key. The datagram can now be sent.
4.4. Group Member Operations 4.4. Group Member Operations
A group member receiving the GROUPKEY-PUSH datagram matches the A group member receiving the GROUPKEY-PUSH datagram matches the
cookie pair in the ISAKMP HDR to an existing SA. The message is cookie pair in the ISAKMP HDR to an existing SA. The message is
decrypted, and the form of the datagram is validated. This weeds out decrypted, and the form of the datagram is validated. This weeds out
obvious ill-formed messages (which may be sent as part of a Denial of obvious ill-formed messages (which may be sent as part of a Denial of
Service attack on the group). Service attack on the group).
The sequence number in the SEQ payload is validated to ensure that it The sequence number in the SEQ payload is validated to ensure that it
is greater than the previously received sequence number, and that it is greater than the previously received sequence number, and that it
fits within a window of acceptable values. The SIG payload is then fits within a window of acceptable values. The SIG payload is then
validated. If the signature fails, the message is discarded. validated. If the signature fails, the message is discarded.
The SA and KD payloads are processed which results in a new GDOI The SA and KD payloads are processed which results in a new GDOI
Rekey SA (if the SA payload included an SA_KEK attribute) and/or new Rekey-SA (if the SA payload included an SA_KEK attribute) and/or new
IPsec SAs being added to the system. If the KD payload includes an Data-security SAs being added to the system. If the KD payload
LKH update array, the group member compares the LKH ID in each key includes an LKH update array, the group member compares the LKH ID in
update packet to the LKH IDs that it holds. If it finds a match, it each key update packet to the LKH IDs that it holds. If it finds a
decrypts the key using the key prior to it in the key array and match, it decrypts the key using the key prior to it in the key array
stores the new key in the LKH key array that it holds. The final and stores the new key in the LKH key array that it holds. The final
decryption yields the new group KEK. decryption yields the new group KEK.
If the SA payload includes Data-Security SA including a counter-modes
of operation and the receiving group member is a sender for that SA,
the group member uses its current SID value with the Data-Security
SAs to create counter-mode nonces. If it is a sender and does not
hold a current SID value, it MUST NOT install the Data-Security SAs.
It MAY initiate a GROUPKEY-PULL exchange to the GCKS in order to
obtain an SID value (along with current group policy).
5. Payloads and Defined Values 5. Payloads and Defined Values
This document specifies use of several ISAKMP payloads, which are This document specifies use of several ISAKMP payloads, which are
defined in accordance with RFC 2408. The following payloads are defined in accordance with RFC 2408. The following payloads are
extended or further specified. extended or further specified.
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
Security Association (SA) 1 Security Association (SA) 1
Identification (ID) 5 Identification (ID) 5
skipping to change at page 18, line 26 skipping to change at page 20, line 26
Several payload formats specific to the group security exchanges are Several payload formats specific to the group security exchanges are
required. required.
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
SA KEK Payload (SAK) 15 SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16 SA TEK Payload (SAT) 16
Key Download (KD) 17 Key Download (KD) 17
Sequence Number (SEQ) 18 Sequence Number (SEQ) 18
SA Group Associated Policy (GAP) TBD-1 Group Associated Policy (GAP) TBD-1
5.1. Identification Payload 5.1. Identification Payload
The Identification Payload is defined in RFC 2408. For the GDOI, it The Identification Payload is defined in RFC 2408. For the GDOI, it
is used to identify a group identity that will later be associated is used to identify a group identity that will later be associated
with Security Associations for the group. A group identity may map with Security Associations for the group. A group identity may map
to a specific IP multicast group, or may specify a more general to a specific IP multicast group, or may specify a more general
identifier, such as one that represents a set of related multicast identifier, such as one that represents a set of related multicast
streams. streams.
skipping to change at page 19, line 44 skipping to change at page 21, line 44
or a SAT Payload. See section 5.2.1 for a description of which or a SAT Payload. See section 5.2.1 for a description of which
circumstances are required for each payload type to be present. circumstances are required for each payload type to be present.
o RESERVED (2 octets) -- Must be zero. o RESERVED (2 octets) -- Must be zero.
5.2.1. Payloads following the SA payload 5.2.1. Payloads following the SA payload
Payloads that define specific security association attributes for the Payloads that define specific security association attributes for the
KEK and/or TEKs used by the group MUST follow the SA payload. How KEK and/or TEKs used by the group MUST follow the SA payload. How
many of each payload is dependent upon the group policy. There may many of each payload is dependent upon the group policy. There may
be zero or one SAK Payloads, zero or more GAP Payloads, and zero or be zero or one SAK Payload, zero or one GAP Payload, and zero or more
more SAT Payloads, where either one SAK or SAT payload MUST be SAT Payloads, where either one SAK or SAT payload MUST be present.
present. When present, the order of the SA Attributes payloads must When present, the order of the SA Attributes payloads must be: KEK,
be: KEK, GAP, and TEKs. GAP, and TEKs.
This latitude allows various group policies to be accommodated. For This latitude regarding SA Attributes payloads allows various group
example if the group policy does not require the use of a Re-key SA, policies to be accommodated. For example if the group policy does
the GCKS would not need to send an SA KEK attribute to the group not require the use of a Re-key SA, the GCKS would not need to send
member since all SA updates would be performed using the Registration an SA KEK attribute to the group member since all SA updates would be
SA. Alternatively, group policy might use a Re-key SA but choose to performed using the Registration SA. Alternatively, group policy
download a KEK to the group member only as part of the Registration might use a Re-key SA but choose to download a KEK to the group
SA. Therefore, the KEK policy (in the SA KEK attribute) would not be member only as part of the Registration SA. Therefore, the KEK
necessary as part of the Re-key SA message SA payload. policy (in the SA KEK attribute) would not be necessary as part of
the Re-key SA message SA payload.
Specifying multiple SATs allows multiple sessions to be part of the Specifying multiple SATs allows multiple sessions to be part of the
same group and multiple streams to be associated with a session same group and multiple streams to be associated with a session
(e.g., video, audio, and text) but each with individual security (e.g., video, audio, and text) but each with individual security
association policy. association policy.
A GAP payload allows for the distribution of group-wise policy, such A GAP payload allows for the distribution of group-wise policy, such
as instructions as to when to activate and de-activate SAs. as instructions as to when to activate and de-activate SAs.
5.3. SA KEK payload 5.3. SA KEK payload
skipping to change at page 22, line 5 skipping to change at page 24, line 5
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated by
the DST ID Type. the DST ID Type.
o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become must be the ISAKMP Header cookie pair where the first 8 octets become
the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" in the same and the second 8 octets become the "Responder Cookie" in the same
HDR. As described above, these cookies are assigned by the GCKS. HDR. As described above, these cookies are assigned by the GCKS.
o RESERVED2 (4 octets) -- Must be zero. o RESERVED2 (4 octets) -- Must be zero. This bytes represent fields
previously defined but no longer used by GDOI.
o KEK Attributes -- Contains KEK policy attributes associated with o KEK Attributes -- Contains KEK policy attributes associated with
the group. The following sections describe the possible attributes. the group. The following sections describe the possible attributes.
Any or all attributes may be optional, depending on the group policy. Any or all attributes may be optional, depending on the group policy.
5.3.1. KEK Attributes 5.3.1. KEK Attributes
The following attributes may be present in a SAK Payload. The The following attributes may be present in a SAK Payload. The
attributes must follow the format defined in ISAKMP (Section 3.3 of attributes must follow the format defined in ISAKMP (Section 3.3 of
[RFC2408]). In the table, attributes that are defined as TV are [RFC2408]). In the table, attributes that are defined as TV are
skipping to change at page 22, line 29 skipping to change at page 24, line 30
ID Class Value Type ID Class Value Type
-------- ----- ---- -------- ----- ----
RESERVED 0 RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B SIG_KEY_LENGTH 7 B
KE_OAKLEY_GROUP 8 B
Standards Action 9-127
Private Use 128-255
Unassigned 256-32767
The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a
GROUPKEY-PULL message. GROUPKEY-PULL message.
5.3.2. KEK_MANAGEMENT_ALGORITHM 5.3.2. KEK_MANAGEMENT_ALGORITHM
The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management
algorithm used to provide forward or backward access control (i.e., algorithm used to provide forward or backward access control (i.e.,
used to exclude group members). Defined values are specified in the used to exclude group members). Defined values are specified in the
following table. following table.
KEK Management Type Value KEK Management Type Value
------------------- ----- ------------------- -----
RESERVED 0 RESERVED 0
LKH 1 LKH 1
RESERVED 2-127 Standards Action 2-127
Private Use 128-255 Private Use 128-255
5.3.2.1. LKH 5.3.2.1. LKH
This type indicates the group management method described in Section This type indicates the group management method described in Section
5.4 of [RFC2627]. A general discussion of LKH operations can also be 5.4 of [RFC2627]. A general discussion of LKH operations can also be
found in Section 6.3 of Multicast and Group Security [HD03] found in Section 6.3 of Multicast and Group Security [HD03]
5.3.3. KEK_ALGORITHM 5.3.3. KEK_ALGORITHM
The KEK_ALGORITHM class specifies the encryption algorithm using with The KEK_ALGORITHM class specifies the encryption algorithm in which
the KEK. Defined values are specified in the following table. An the KEK is used to provide confidentiality for the GROUPKEY-PUSH
message. Defined values are specified in the following table. A
GDOI implementation MUST abort if it encounters an attribute or GDOI implementation MUST abort if it encounters an attribute or
capability that it does not understand. capability that it does not understand.
Algorithm Type Value Algorithm Type Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
KEK_ALG_DES 1 KEK_ALG_DES 1
KEK_ALG_3DES 2 KEK_ALG_3DES 2
KEK_ALG_AES 3 KEK_ALG_AES 3
RESERVED 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767
If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys
(e.g., LKH), and if the management algorithm does not specify the (e.g., LKH), and if the management algorithm does not specify the
algorithm for those keys, then the algorithm defined by the algorithm for those keys, then the algorithm defined by the
KEK_ALGORITHM attribute MUST be used for all keys which are included KEK_ALGORITHM attribute MUST be used for all keys which are included
as part of the management. as part of the management.
5.3.3.1. KEK_ALG_DES 5.3.3.1. KEK_ALG_DES
This type specifies DES using the Cipher Block Chaining (CBC) mode as This type specifies DES using the Cipher Block Chaining (CBC) mode as
skipping to change at page 24, line 8 skipping to change at page 26, line 14
5.3.3.3. KEK_ALG_AES 5.3.3.3. KEK_ALG_AES
This type specifies AES as described in [FIPS197]. The mode of This type specifies AES as described in [FIPS197]. The mode of
operation for AES is Cipher Block Chaining (CBC) as recommended in operation for AES is Cipher Block Chaining (CBC) as recommended in
[SP.800-38A]. [SP.800-38A].
5.3.4. KEK_KEY_LENGTH 5.3.4. KEK_KEY_LENGTH
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in
bits). The Group Controller/Key Server (GCKS) adds the KEK_KEY_LEN bits). The Group Controller/Key Server (GCKS) adds the
attribute to the SA payload when distributing KEK policy to group KEK_KEY_LENGTH attribute to the SA payload when distributing KEK
members. The group member verifies whether or not it has the policy to group members. The group member verifies whether or not it
capability of using a cipher key of that size. If the cipher has the capability of using a cipher key of that size. If the cipher
definition includes a fixed key length (e.g., KEK_ALG_3DES), the definition includes a fixed key length (e.g., KEK_ALG_3DES), the
group member can make its decision solely using the KEK_ALGORITHM group member can make its decision solely using the KEK_ALGORITHM
attribute and does not need the KEK_KEY_LEN attribute. Sending the attribute and does not need the KEK_KEY_LENGTH attribute. Sending
KEK_KEY_LEN attribute in the SA payload is OPTIONAL if the KEK cipher the KEK_KEY_LENGTH attribute in the SA payload is OPTIONAL if the KEK
has a fixed key length. Also, note that the KEK_KEY_LEN includes cipher has a fixed key length. Also, note that the KEK_KEY_LEN
only the actual length of the cipher key (the IV length is not includes only the actual length of the cipher key (the IV length is
included in this attribute). not included in this attribute).
5.3.5. KEK_KEY_LIFETIME 5.3.5. KEK_KEY_LIFETIME
The KEK_KEY_LIFETIME class specifies the maximum time for which the The KEK_KEY_LIFETIME class specifies the maximum time for which the
KEK is valid. The GCKS may refresh the KEK at any time before the KEK is valid. The GCKS may refresh the KEK at any time before the
end of the valid period. The value is a four (4) octet number end of the valid period. The value is a four (4) octet number
defining a valid time period in seconds. defining a valid time period in seconds.
5.3.6. SIG_HASH_ALGORITHM 5.3.6. SIG_HASH_ALGORITHM
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The
following table defines the algorithms for SIG_HASH_ALGORITHM. following table defines the algorithms for SIG_HASH_ALGORITHM.
Algorithm Type Value Algorithm Type Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
SIG_HASH_MD5 1 SIG_HASH_MD5 1
SIG_HASH_SHA1 2 SIG_HASH_SHA1 2
SIG_HASH_SHA256 TBD-2 SIG_HASH_SHA256 TBD-2
SIG_HASH_SHA384 TBD-3 SIG_HASH_SHA384 TBD-3
SIG_HASH_SHA512 TBD-4 SIG_HASH_SHA512 TBD-4
RESERVED 6-127 Standards Action 3-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767
The SHA hash algorithms are defined in the Secure Hash The SHA hash algorithms are defined in the Secure Hash
Standard[FIPS.180-2.2002]. Standard[FIPS.180-2.2002].
If the SIG_ALGORITHM is SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, or If the SIG_ALGORITHM is SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, or
SIG_ALG_ECDSA-521 the hash algorithm is implicit in the definition, SIG_ALG_ECDSA-521 the hash algorithm is implicit in the definition,
and SIG_HASH_ALGORITHM is not required to be present in a SAK and SIG_HASH_ALGORITHM is not required to be present in a SAK
Payload. Payload.
5.3.7. SIG_ALGORITHM 5.3.7. SIG_ALGORITHM
The SIG_ALGORITHM class specifies the SIG payload signature The SIG_ALGORITHM class specifies the SIG payload signature
algorithm. Defined values are specified in the following table. algorithm. Defined values are specified in the following table.
Algorithm Type Value Algorithm Type Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
SIG_ALG_RSA 1 SIG_ALG_RSA 1
SIG_ALG_DSS 2 SIG_ALG_DSS 2
SIG_ALG_ECDSS 3 SIG_ALG_ECDSS 3
SIG_ALG_RSA_PSS TBD-6 SIG_ALG_RSA_PSS TBD-6
SIG_ALG_ECDSA-256 TBD-7 SIG_ALG_ECDSA-256 TBD-7
SIG_ALG_ECDSA-384 TBD-8 SIG_ALG_ECDSA-384 TBD-8
SIG_ALG_ECDSA-521 TBD-9 SIG_ALG_ECDSA-521 TBD-9
RESERVED 8-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767
5.3.7.1. SIG_ALG_RSA 5.3.7.1. SIG_ALG_RSA
This algorithm specifies the RSA digital signature algorithm using This algorithm specifies the RSA digital signature algorithm using
the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447]. the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447].
5.3.7.2. SIG_ALG_DSS 5.3.7.2. SIG_ALG_DSS
This algorithm specifies the DSS digital signature algorithm as This algorithm specifies the DSS digital signature algorithm as
described in Section 4 of [FIPS186-3]. described in Section 4 of [FIPS186-3].
skipping to change at page 26, line 24 skipping to change at page 28, line 41
in [RFC5903]. The format of the signature in the SIG payload MUST be in [RFC5903]. The format of the signature in the SIG payload MUST be
as specified in [RFC4754]. as specified in [RFC4754].
5.3.8. SIG_KEY_LENGTH 5.3.8. SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key The SIG_KEY_LENGTH class specifies the length of the SIG payload key
in bits. in bits.
5.4. Group Associated Policy 5.4. Group Associated Policy
RFC 3547 provides for the distribution of policy in the GROUPKEY-PULL A GCKS may have group-specific policy that is not distributed in an
exchange in an SA payload. Policy can define GROUPKEY-PUSH policy SA TEK or SA KEK. Some of this policy is relevant to all group
(SA KEK) or traffic encryption policy (SA TEK) such as IPsec policy. members, and some is sender-specific policy for a particular group
There is a need to distribute group policy that fits into neither member. The former can be distributed in either a GROUPKEY-PULL or
category. Some of this policy is generic to the group, and some is GROUPKEY-PUSH exchange, whereas the latter MUST only be sent in a
sender-specific policy for a particular group member. GROUPKEY-PULL exchange. Additionally, a group member sometimes has
the need to make policy requests for resources of the GCKS in a
GROUPKEY-PULL exchange. GDOI distributes this associated group
policy and policy requests in the Group Associated Policy (GAP)
payload.
GDOI distributes this associated group policy in a new payload called The GAP payload can be distributed by the GCKS as part of the SA
the SA Group Associated Policy (SA GAP). The SA GAP payload follows payload. It follows any SA KEK payload, and is placed before any SA
any SA KEK payload, and is placed before any SA TEK payloads. In the TEK payloads. In the case that group policy does not include an SA
case that group policy does not include an SA KEK, the SA Attribute KEK, the SA Attribute Next Payload field in the SA payload MAY
Next Payload field in the SA payload MAY indicate the SA GAP payload. indicate the SA GAP payload.
The GAP payload can be optionally included by a group member in
message 3 of the GROUPKEY-PULL exchange in order to make policy
requests.
The SA GAP payload is defined as follows: The SA GAP payload is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Group Associated Policy Attributes ~ ! Group Associated Policy Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
skipping to change at page 27, line 15 skipping to change at page 29, line 40
o RESERVED (1 octet) -- Must be zero. o RESERVED (1 octet) -- Must be zero.
o Payload Length (2 octets) -- Length of this payload, including the o Payload Length (2 octets) -- Length of this payload, including the
SA GAP header and Attributes. SA GAP header and Attributes.
o Group Associated Policy Attributes (variable) -- Contains o Group Associated Policy Attributes (variable) -- Contains
attributes following the format defined in Section 3.3 of RFC attributes following the format defined in Section 3.3 of RFC
2408. 2408.
Several group associated policy attributes are defined in this memo. Several group associated policy attributes are defined in this memo.
An GDOI implementation MUST abort if it encounters and attribute or An GDOI implementation MUST abort if it encounters an attribute or
capability that it does not understand. capability that it does not understand. The values for these
attributes are included in the IANA Considerations section of this
5.4.1. ACTIVATION_TIME_DELAY memo.
This attribute allows a GCKS to set the Activation Time Delay for SAs
generated from TEKs. The value is in seconds.
5.4.2. DEACTIVATION_TIME_DELAY
This attribute allows a GCKS to set the Deactivation Time Delay for
SAs generated from TEKs. The value is in seconds. The values of
Activation Time Delay and Deactivation Time Delay are independant.
However, the Deactivation Time Delay vaue should be larger, which
allows new SAs to be activated before older SAs are deactivated.
Such a policy ensures that protected group traffic will always flow
without interruption.
5.4.3. SENDER_ID
Several new AES counter-based modes of operation have been specified
for ESP [RFC3686],[RFC4106],[RFC4309],[RFC4543] and AH [RFC4543].
These AES counter-based modes require that no two senders in the
group ever send a packet with the same IV. This requirement is met
using the method described in
[I-D.ietf-msec-ipsec-group-counter-modes], which requires each sender
to be allocated a unique Sender ID (SID). The SENDER_ID attribute is
used to distribute an SID to a group member during the GROUPKEY-PULL
message. Other algorithms with the same need may be defined in the
future; the sender MUST use the IV construction method described
above with those algorithms as well.
The SENDER_ID attribute value contains the following fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SID Length ! SID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o SID Length (1 octet) -- A natural number defining the number of
bits to be used in the SID field of the counter mode transform
nonce. The length of the SID is chosen by the GCKS administrator
based on the counter-based mode specification and the number of
expected group members. In accordance with
[I-D.ietf-msec-ipsec-group-counter-modes] an implementation MUST
support values of 8, 12, and 16.
o SID Value (variable) -- The Sender ID value allocated to the group
member.
5.4.3.1. GCKS Semantics
The GCKS maintains a SID counter (SIDC). It is incremented each time
a SENDER_ID attribute is distributed to a group member. The first
group member to register is given the SID of 1.
Any group member registering will be given a new SID value, which
allows group members to act as a group sender when an older SID value
becomes unusable (as described in the next section).
A GCKS MAY allocate multiple SID values in one SA GAP payload.
Allocating several SID values at the same time to a group member
expected to send at a high rate would obviate the need for the group
member to re-register as frequently.
If a GCKS allocates all SID values, it can no longer respond to GDOI 5.4.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY
registrations and must re-initialize the entire group. This is done
by including Delete Payload for all ESP and AH SAs in a GDOI rekey
message, resetting the SIDC to zero, and creating new ESP and AH SAs
that match the group policy. When group members re-register, the
SIDs are allocated again beginning with the value 1 as described
above. Each re-registering group member will be given a new SID and
the new group policy.
The SENDER_ID attribute MUST NOT be sent as part of a GROUPKEY-PUSH Section 4.2.1 of RFC 5374 specifies a key rollover method that
message, because distributing the same sender-specific policy to more requires two values be given it from the group key management
than one group member may reduce the security of the group. protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set
the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD
defines how long after receiving new SAs that they are to be
activated by the GM. The ATD value is in seconds.
5.4.3.2. Group Member Semantics The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation
Time Delay (DTD) for previously distributed SAs. The DTD defines how
long after receiving new SAs that it should deactivate SAs that are
destroyed by the re-key event. The value is in seconds.
The SENDER_ID attribute value distributed to the group member MUST be The values of ATD and DTD are independent. However, the DTD value
used by that group member as the Sender Identifier (SID) field should be larger, which allows new SAs to be activated before older
portion of the IV. The SID is used for all counter mode SAs SAs are deactivated. Such a policy ensures that protected group
distributed by the GCKS to be used for communications sent as a part traffic will always flow without interruption.
of this group.
When the Sender-Specific IV (SSIV) field for any IPsec SA is 5.4.2. SENDER_ID_REQUEST
exhausted, the group member MUST no longer act as a sender using its
active SID. The group member SHOULD re-register, during which time
the GCKS will issue a new SID to the group member. The new SID
replaces the existing SID used by this group member, and also resets
the SSIV value to its starting value. A group member MAY re-register
prior to the actual exhaustion of the SSIV field to avoid dropping
data packets due to the exhaustion of available SSIV values combined
with a particular SID value.
A group member MUST NOT process a SENDER_ID attribute present in a The SENDER_ID_REQUEST attribute is used by a group member to request
GROUPKEY-PUSH message. SIDs during the GROUPKEY-PULL message, and includes a count of how
many SID values it desires.
5.5. SA TEK Payload 5.5. SA TEK Payload
The SA TEK (SAT) payload contains security attributes for a single The SA TEK (SAT) payload contains security attributes for a single
TEK associated with a group. TEK associated with a group.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
skipping to change at page 30, line 7 skipping to change at page 31, line 4
payload types for this message are another SAT Payload or zero to payload types for this message are another SAT Payload or zero to
indicate there are no more security association attributes. indicate there are no more security association attributes.
o RESERVED (1 octet) -- Must be zero. o RESERVED (1 octet) -- Must be zero.
o Payload Length (2 octets) -- Length of this payload, including the o Payload Length (2 octets) -- Length of this payload, including the
TEK Protocol-Specific Payload. TEK Protocol-Specific Payload.
o Protocol-ID (1 octet) -- Value specifying the Security Protocol. o Protocol-ID (1 octet) -- Value specifying the Security Protocol.
The following table defines values for the Security Protocol The following table defines values for the Security Protocol
Protocol ID Value Protocol ID Value
----------- ----- ----------- -----
RESERVED 0 RESERVED 0
GDOI_PROTO_IPSEC_ESP 1 GDOI_PROTO_IPSEC_ESP 1
GDOI_PROTO_IPSEC_AH TBD-5 GDOI_PROTO_IPSEC_AH TBD-5
RESERVED 3-127 Standards Action 3-127
Private Use 128-255 Private Use 128-255
o TEK Protocol-Specific Payload (variable) -- Payload which describes o TEK Protocol-Specific Payload (variable) -- Payload which describes
the attributes specific for the Protocol-ID. the attributes specific for the Protocol-ID.
5.5.1. GDOI_PROTO_IPSEC_ESP/GDOI_PROTO_IPSEC_AH 5.5.1. GDOI_PROTO_IPSEC_ESP/GDOI_PROTO_IPSEC_AH
The TEK Protocol-Specific payload for ESP and AH is as follows: The TEK Protocol-Specific payload for ESP and AH is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 32, line 5 skipping to change at page 32, line 48
GDOI_PROTO_IPSEC_ESP and GDOI_PROTO_IPSEC_AH excluding the Group GDOI_PROTO_IPSEC_ESP and GDOI_PROTO_IPSEC_AH excluding the Group
Description (section 4.5 of [RFC2407], which MUST NOT be sent by a Description (section 4.5 of [RFC2407], which MUST NOT be sent by a
GDOI implementation and is ignored by a GDOI implementation if GDOI implementation and is ignored by a GDOI implementation if
received. The following attributes MUST be supported by an received. The following attributes MUST be supported by an
implementation supporting ESP and AH: SA Life Type, SA Life Duration, implementation supporting ESP and AH: SA Life Type, SA Life Duration,
Encapsulation Mode. An implementation supporting ESP must also Encapsulation Mode. An implementation supporting ESP must also
support the Authentication Algorithm attribute if the ESP transform support the Authentication Algorithm attribute if the ESP transform
includes authentication/ The Authentication Algorithm attribute of includes authentication/ The Authentication Algorithm attribute of
the IPsec DOI is group authentication in GDOI. the IPsec DOI is group authentication in GDOI.
5.5.1.1. Harmonization with RFC 5374 5.5.1.1. New IPsec Security Association Attributes
The Multicast Extensions to the Security Architecture for the The Multicast Extensions to the Security Architecture for the
Internet Protocol (RFC 5374) introduces new requirements for a group Internet Protocol (RFC 5374) introduces new requirements for a group
key management system distributing IPsec policy. The following key management system distributing IPsec policy. It also defines new
sections describe new GDOI requirements that result from harmonizing attributes as part of the Group Security Policy Database (GSPD).
with that document. These attributes describe policy that a group key management system
must convey to a group member in order to support those extensions.
5.5.1.1.1. Group Security Policy Database Attributes The GDOI SA TEK payload distributes IPsec policy using IPsec security
association attributes defined in [ISAKMP-REG]. This section defines
RFC 5374 describes new attributes as part of the Group Security how GDOI can convey the new attributes as IPsec Security Association
Policy Database (GSPD). These attributes describe policy that a Attributes.
group key management system must convey to a group member in order to
support those extensions. The GDOI SA TEK payload distributes IPsec
policy using IPsec security association attributes defined in
[ISAKMP-REG]. This section defines how GDOI can convey the new
attributes as IPsec Security Association Attributes.
5.5.1.1.2. Address Preservation 5.5.1.1.1. Address Preservation
Applications use the extensions in RFC 5374 to copy the IP addresses Applications use the extensions in RFC 5374 to copy the IP addresses
into the outer IP header when encapsulating an IP packet as an IPsec into the outer IP header when encapsulating an IP packet as an IPsec
tunnel mode packet. This allows an IP multicast packet to continue tunnel mode packet. This allows an IP multicast packet to continue
to be routed as a IP multiast packet. In order for the GDOI group to be routed as a IP multicast packet. In order for the GDOI group
member to appropriately set up the GSPD, the GCKS must provide that member to appropriately set up the GSPD, the GCKS must provide that
policy to the group member. policy to the group member.
Depending on group policy, several address preservation methods are Depending on group policy, several address preservation methods are
possible: no address preservation ("None"), preservation of the possible: no address preservation ("None"), preservation of the
original source address ("Source-Only"), preservation of the original original source address ("Source-Only"), preservation of the original
destination address ("Destination-Only"), or both addresses ("Source- destination address ("Destination-Only"), or both addresses ("Source-
And-Destination"). This memo adds the "Address Preservation" And-Destination"). The IANA Considerations section of this memo adds
security association attribute. If this attribute is not included in the "Address Preservation" security association attribute. If this
a GDOI SA TEK payload provided by a GCKS, then Source-And-Destination attribute is not included in a GDOI SA TEK payload provided by a
address preservation has been defined for the SA TEK. GCKS, then Source-And-Destination address preservation has been
defined for the SA TEK.
5.5.1.1.3. SA Direction 5.5.1.1.2. SA Direction
Depending on group policy, an IPsec SA created from an SA TEK payload Depending on group policy, an IPsec SA created from an SA TEK payload
may be required in one or both directions. SA TEK policy used by may be required in one or both directions. SA TEK policy used by
multiple senders is required to be installed in both the sending and multiple senders is required to be installed in both the sending and
receiving direction ("Symmetric"), whereas SA TEK for a single sender receiving direction ("Symmetric"), whereas SA TEK for a single sender
should only be installed in the receiving direction by receivers should only be installed in the receiving direction by receivers
("Receiver-Only") and in the sending direction by the sender ("Receiver-Only") and in the sending direction by the sender
("Sender-Only"). This memo adds the "SA Direction" security ("Sender-Only"). The IANA Considerations section of this memo adds
association attribute. If the attribute is not included in a GDOI SA the "SA Direction" security association attribute.
TEK payload, then the IPsec SA is treated as a Symmetric IPsec SA.
5.5.1.1.4. Re-key rollover
Section 4.2.1 of RFC 5374 specifies a key rollover method that
requires two values be given it from the group key management
protocol. The Activation Time Delay (ATD) attribute allows the GCKS
to specify how long after the start of a re-key event that a group
member is to activate new TEKs. The Deactivation Time Delay (DTD)
attribute allows the GCKS to specify how long after the start of a
re-key event that a group member is to deactivate existing TEKs.
This memo adds new attributes by which a GCKS can relay these values An SA TEK payload that does not include the SA Direction attribute is
to group members as part of the Group Associated Policy described in treated as a Symmetric IPsec SA. Note that unless Symmetric may be
Section 5. the only value that can be meaningfully described for an SA TEK
distributed in an GROUPKEY-PUSH message. Alternatively, Receiver-
Only could be distributed, but group senders would need to be
configured to not receive GROUPKEY-PUSH messages in order to retain
their role.
5.5.2. Other Security Protocols 5.5.2. Other Security Protocols
Besides ESP and AH, GDOI should serve to establish SAs for secure Besides ESP and AH, GDOI should serve to establish SAs for secure
groups needed by other Security Protocols that operate at the groups needed by other Security Protocols that operate at the
transport, application, and internetwork layers. These other transport, application, and internetwork layers. These other
Security Protocols, however, are in the process of being developed or Security Protocols, however, are in the process of being developed or
do not yet exist. do not yet exist.
The following information needs to be provided for a Security The following information needs to be provided for a Security
skipping to change at page 34, line 30 skipping to change at page 35, line 29
the message, then this field will be zero. the message, then this field will be zero.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Payload Length (2 octets) -- Length in octets of the current o Payload Length (2 octets) -- Length in octets of the current
payload, including the generic payload header. payload, including the generic payload header.
o Number of Key Packets (2 octets) -- Contains the total number of o Number of Key Packets (2 octets) -- Contains the total number of
both TEK and Rekey arrays being passed in this data block. both TEK and Rekey arrays being passed in this data block.
o Key Packets Several types of key packets are defined. Each Key o Key Packets (variable) -- Several types of key packets are defined.
Packet has the following format. Each Key Packet has the following format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length ! ! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~ ! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~ ~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data o Key Download (KD) Type (1 octet) -- Identifier for the Key Data
field of this Key Packet. field of this Key Packet.
Key Download Type Value Key Download Type Value
----------------- ----- ----------------- -----
RESERVED 0 RESERVED 0
TEK 1 TEK 1
KEK 2 KEK 2
LKH 3 LKH 3
RESERVED 4-127 SID TBD-7
Standards Action 4-127
Private Use 128-255 Private Use 128-255
"KEK" is a single key whereas LKH is an array of key-encrypting keys. "KEK" is a single key whereas LKH is an array of key-encrypting keys.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Key Download Length (2 octets) -- Length in octets of the Key o Key Download Length (2 octets) -- Length in octets of the Key
Packet data, including the Key Packet header. Packet data, including the Key Packet header.
o SPI Size (1 octet) -- Value specifying the length in octets of the o SPI Size (1 octet) -- Value specifying the length in octets of the
skipping to change at page 35, line 47 skipping to change at page 37, line 11
(Section 3.3 of [RFC2408]). In the table, attributes defined as TV (Section 3.3 of [RFC2408]). In the table, attributes defined as TV
are marked as Basic (B); attributes defined as TLV are marked as are marked as Basic (B); attributes defined as TLV are marked as
Variable (V). Variable (V).
TEK Class Value Type TEK Class Value Type
--------- ----- ---- --------- ----- ----
RESERVED 0 RESERVED 0
TEK_ALGORITHM_KEY 1 V TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V TEK_SOURCE_AUTH_KEY 3 V
Standards Action 4-127
Private Use 128-255
Unassigned 256-32767
If no TEK key packets are included in a Registration KD payload, the If no TEK key packets are included in a Registration KD payload, the
group member can expect to receive the TEK as part of a Re-key SA. group member can expect to receive the TEK as part of a Re-key SA.
At least one TEK must be included in each Re-key KD payload. At least one TEK must be included in each Re-key KD payload.
Multiple TEKs may be included if multiple streams associated with the Multiple TEKs may be included if multiple streams associated with the
SA are to be rekeyed. SA are to be rekeyed.
When an algorithm specification specifies the format of the keying When an algorithm specification specifies the format of the keying
material, the value transported in the KD payload for that key is material, the value transported in the KD payload for that key is
passed according to that specification. The keying material may passed according to that specification. The keying material may
skipping to change at page 37, line 11 skipping to change at page 38, line 26
be present. The attributes must follow the format defined in ISAKMP be present. The attributes must follow the format defined in ISAKMP
(Section 3.3 of [RFC2408]). In the table, attributes defined as TV (Section 3.3 of [RFC2408]). In the table, attributes defined as TV
are marked as Basic (B); attributes defined as TLV are marked as are marked as Basic (B); attributes defined as TLV are marked as
Variable (V). Variable (V).
KEK Class Value Type KEK Class Value Type
--------- ----- ---- --------- ----- ----
RESERVED 0 RESERVED 0
KEK_ALGORITHM_KEY 1 V KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V SIG_ALGORITHM_KEY 2 V
Standards Action 3-127
Private Use 128-255
Unassigned 256-32767
If the KEK key packet is included, there MUST be only one present in If the KEK key packet is included, there MUST be only one present in
the KD payload. the KD payload.
5.6.2.1. KEK_ALGORITHM_KEY 5.6.2.1. KEK_ALGORITHM_KEY
The KEK_ALGORITHM_KEY class declares the encryption key for this SPI The KEK_ALGORITHM_KEY class declares the encryption key for this SPI
is contained in the Key Packet Attribute. The encryption algorithm is contained in the Key Packet Attribute. The encryption algorithm
that will use this key was specified in the SAK payload. that will use this key was specified in the SAK payload.
If the mode of operation for the algorithm requires an Initialization If the mode of operation for the algorithm requires an IV, an
Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY explicit IV MUST be included in the KEK_ALGORITHM_KEY before the
before the actual key. actual key.
5.6.2.2. SIG_ALGORITHM_KEY 5.6.2.2. SIG_ALGORITHM_KEY
The SIG_ALGORITHM_KEY class declares that the public key for this SPI The SIG_ALGORITHM_KEY class declares that the public key for this SPI
is contained in the Key Packet Attribute, which may be useful when no is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload. will use this key was specified in the SAK payload.
5.6.3. LKH Download Type 5.6.3. LKH Download Type
skipping to change at page 38, line 11 skipping to change at page 39, line 22
(Section 3.3 of [RFC2408]). In the table, attributes defined as TV (Section 3.3 of [RFC2408]). In the table, attributes defined as TV
are marked as Basic (B); attributes defined as TLV are marked as are marked as Basic (B); attributes defined as TLV are marked as
Variable (V). Variable (V).
KEK Class Value Type KEK Class Value Type
--------- ----- ---- --------- ----- ----
RESERVED 0 RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V SIG_ALGORITHM_KEY 3 V
RESERVED 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767
If an LKH key packet is included in the KD payload, there must be If an LKH key packet is included in the KD payload, there must be
only one present. only one present.
5.6.3.1. LKH_DOWNLOAD_ARRAY 5.6.3.1. LKH_DOWNLOAD_ARRAY
This attribute is used to download a set of keys to a group member. This attribute is used to download a set of keys to a group member.
It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the
GROUPKEY-PUSH is sent to more than the group member. If an GROUPKEY-PUSH is sent to more than the group member. If an
LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must
skipping to change at page 39, line 44 skipping to change at page 41, line 5
longer valid for use. A time value of zero indicates that this key longer valid for use. A time value of zero indicates that this key
does not have an expiration time. does not have an expiration time.
o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely
identify a key within an LKH ID. Each new key distributed by the identify a key within an LKH ID. Each new key distributed by the
GCKS for this node will have a key handle identity distinct from GCKS for this node will have a key handle identity distinct from
previous or successive key handles specified for this node. previous or successive key handles specified for this node.
o Key Data (variable length) -- Key data, which is dependent on the o Key Data (variable length) -- Key data, which is dependent on the
Key Type algorithm for its format. If the mode of operation for the Key Type algorithm for its format. If the mode of operation for the
algorithm requires an Initialization Vector (IV), an explicit IV MUST algorithm requires an IV, an explicit IV MUST be included in the Key
be included in the Key Data field prepended to the actual key. Data field prepended to the actual key.
The Key Creation Date and Key expiration Dates MAY be zero. This is The Key Creation Date and Key expiration Dates MAY be zero. This is
necessary in the case where time synchronization within the group is necessary in the case where time synchronization within the group is
not possible. not possible.
The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute
contains the Leaf identifier and key for the group member. The rest contains the Leaf identifier and key for the group member. The rest
of the LKH Key structures contain keys along the path of the key tree of the LKH Key structures contain keys along the path of the key tree
in order from the leaf, culminating in the group KEK. in order from the leaf, culminating in the group KEK.
skipping to change at page 41, line 14 skipping to change at page 42, line 25
LKH Key is encrypted under the key defined by the LKH ID and Key LKH Key is encrypted under the key defined by the LKH ID and Key
Handle found in the LKH_UPDATE_ARRAY header. Handle found in the LKH_UPDATE_ARRAY header.
5.6.3.3. SIG_ALGORITHM_KEY 5.6.3.3. SIG_ALGORITHM_KEY
The SIG_ALGORITHM_KEY class declares that the public key for this SPI The SIG_ALGORITHM_KEY class declares that the public key for this SPI
is contained in the Key Packet Attribute, which may be useful when no is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload. will use this key was specified in the SAK payload.
5.6.4. SID Download Type
This attribute is used to download one or more Sender-ID (SID) values
for the exclusive use of a group member.
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Standards Action 3-128
Private Use 129-255
Unassigned 256-32767
Because a SID value is intended for a single group member, the SID
Download type MUST NOT be distributed in a GROUPKEY_PUSH message
distributed to multiple group members.
5.6.4.1. NUMBER_OF_SID_BITS
The NUMBER_OF_SID_BITS class declares how many bits of the cipher
nonce in which to represent a SID value. This value is applied to
each SID value distributed in the SID Download.
5.6.4.2. SID_VALUE
The SID_VALUE class declares a single SID value for the exclusive use
of the a group member. Multiple SID_VALUE attributes MAY be included
in a SID Download.
5.6.4.3. Group Member Semantics
The SID_VALUE attribute value distributed to the group member MUST be
used by that group member as the SID field portion of the IV for all
Data-Security SAs including a counter-based mode of operation
distributed by the GCKS as a part of this group.
When the Sender-Specific IV (SSIV) field for any Data-Security SA is
exhausted, the group member MUST no longer act as a sender on that SA
using its active SID. The group member SHOULD re-register, at which
time the GCKS will issue a new SID to the group member, along with
either the same Data-Security SAs or replacement ones. The new SID
replaces the existing SID used by this group member, and also resets
the SSIV value to its starting value. A group member MAY re-register
prior to the actual exhaustion of the SSIV field to avoid dropping
data packets due to the exhaustion of available SSIV values combined
with a particular SID value.
A group member MUST NOT process an SID Download Type KD payload
present in a GROUPKEY-PUSH message.
5.6.4.4. GCKS Semantics
If any KD payload includes keying material that is associated with a
counter-mode of operation, an SID Download Type KD payload containing
at least one SID_VALUE attribute MUST be included.
The GCKS MUST NOT send the SID Download Type KD payload as part of a
GROUPKEY-PUSH message, because distributing the same sender-specific
policy to more than one group member will reduce the security of the
group.
5.7. Sequence Number Payload 5.7. Sequence Number Payload
The Sequence Number Payload (SEQ) provides an anti-replay protection The Sequence Number Payload (SEQ) provides an anti-replay protection
for GROUPKEY-PUSH messages. Its use is similar to the Sequence for GROUPKEY-PUSH messages. Its use is similar to the Sequence
Number field defined in the IPsec ESP protocol [RFC4303]. Number field defined in the IPsec ESP protocol [RFC4303].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
skipping to change at page 41, line 37 skipping to change at page 44, line 22
The Sequence Number Payload fields are defined as follows: The Sequence Number Payload fields are defined as follows:
o Next Payload (1 octet) -- Identifier for the payload type of the o Next Payload (1 octet) -- Identifier for the payload type of the
next payload in the message. If the current payload is the last in next payload in the message. If the current payload is the last in
the message, then this field will be zero. the message, then this field will be zero.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Payload Length (2 octets) -- Length in octets of the current o Payload Length (2 octets) -- Length in octets of the current
payload, including the generic payload header. payload, including the generic payload header. Must be a value of 8.
o Sequence Number (4 octets) -- This field contains a monotonically o Sequence Number (4 octets) -- This field contains a monotonically
increasing counter value for the group. It is initialized to zero by increasing counter value for the group. It is initialized to zero by
the GCKS, and incremented in each subsequently-transmitted message. the GCKS, and incremented in each subsequently-transmitted message.
Thus the first packet sent for a given Rekey SA will have a Sequence Thus the first packet sent for a given Rekey SA will have a Sequence
Number of 1. The GDOI implementation keeps a sequence counter as an Number of 1. The GDOI implementation keeps a sequence counter as an
attribute for the Rekey SA and increments the counter upon receipt of attribute for the Rekey SA and increments the counter upon receipt of
a GROUPKEY-PUSH message. The current value of the sequence number a GROUPKEY-PUSH message. The current value of the sequence number
must be transmitted to group members as a part of the Registration SA must be transmitted to group members as a part of the Registration SA
payload. A group member must keep a sliding receive window. The payload. A group member must keep a sliding receive window. The
skipping to change at page 45, line 8 skipping to change at page 48, line 8
The following table lists the requirements for Security Protocol The following table lists the requirements for Security Protocol
support for an implementation. support for an implementation.
Requirement KEK Management Algorithm Requirement KEK Management Algorithm
----------- --------------------- ----------- ---------------------
MUST GDOI_PROTO_IPSEC_ESP MUST GDOI_PROTO_IPSEC_ESP
7. Security Considerations 7. Security Considerations
GDOI is a security association (SA) management protocol for groups of GDOI is a security association (SA) management protocol for groups of
senders and receivers. Unlike a data security protocol, SA senders and receivers. This protocol performs authentication of
management includes a key establishment protocol to securely communicating protocol participants (Group Member, Group Controller/
establish keys at communication endpoints. This protocol performs Key Server). It provides confidentiality of key management messages,
entity authentication of the GDOI member or Group Controller/Key and it provides source authentication of those messages. GDOI
Server (GCKS), it provides confidentiality of key management includes defenses against man-in-middle, connection hijacking,
messages, and it provides source authentication of those messages. replay, reflection, and denial-of-service (DOS) attacks on unsecured
This protocol also uses best-known practices for defense against man- networks. GDOI assumes the network is not secure and may be under
in-middle, connection hijacking, replay, reflection, and denial-of- the complete control of an attacker.
service (DOS) attacks on unsecured networks [STS], [RFC2522],
[SKEME]. GDOI assumes the network is not secure and may be under the
complete control of an attacker.
GDOI assumes that the host computer is secure even though the network GDOI assumes that the group members and GCKS are secure even though
is insecure. GDOI ultimately establishes keys among members of a the network is insecure. GDOI ultimately establishes keys among
group, which MUST be trusted to use those keys in an authorized members of a group, which MUST be trusted to use those keys in an
manner according to group policy. The security of GDOI, therefore, authorized manner according to group policy. An GDOI entity
is as good as the degree to which group members can be trusted to compromised by an attacker may reveal the secrets necessary to
protect authenticators, encryption keys, decryption keys, and message eavesdrop on group traffic and/or take the identity of a group
authentication keys. sender, so host security is of the utmost important once. The latter
threat could be mitigated by using source origin authentication in
the Data-Security SAs (e.g., the use of RSA signatures [RFC4359] or
TESLA [RFC4082]). The choice of Data-Security SAs is a matter of
group policy and is not within the scope of this memo.
There are three phases of GDOI as described in this document: an There are three phases of GDOI as described in this document: an
ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is ISAKMP Phase 1 protocol, the GROUPKEY-PULL exchange protected by the
protected by the ISAKMP Phase 1 protocol, and a new message called ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message. Each phase
GROUPKEY-PUSH. Each phase is considered separately below. is considered separately below.
7.1. ISAKMP Phase 1 7.1. ISAKMP Phase 1
As described in this document, GDOI uses the Phase 1 exchanges GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the
defined in [RFC2409] to protect the GROUPKEY-PULL exchange. GROUPKEY-PULL exchange. Therefore all security properties and
Therefore all security properties and considerations of those considerations of those exchanges (as noted in [RFC2409]) are
exchanges (as noted in [RFC2409]) are relevant for GDOI. relevant for GDOI.
GDOI may inherit the problems of its ancestor protocols [FS00], such GDOI may inherit the problems of its ancestor protocols [FS00], such
as identity exposure, absence of unidirectional authentication, or as identity exposure, absence of unidirectional authentication, or
stateful cookies [PK01]. GDOI could benefit, however, from stateful cookies [PK01].
improvements to its ancestor protocols just as it benefits from years
of experience and work embodied in those protocols. To reap the
benefits of future IKE improvements, however, GDOI would need to be
revised in a future standards-track RFC, which is beyond the scope of
this specification.
7.1.1. Authentication 7.1.1. Authentication
Authentication is provided via the mechanisms defined in [RFC2409], Authentication is provided via the mechanisms defined in [RFC2409],
namely Pre-Shared Keys or Public Key encryption. namely Pre-Shared Keys or Public Key encryption.
7.1.2. Confidentiality 7.1.2. Confidentiality
Confidentiality is achieved in Phase 1 through a Diffie-Hellman Confidentiality is achieved in Phase 1 through a Diffie-Hellman
exchange that provides keying material, and through negotiation of exchange that provides keying material, and through negotiation of
skipping to change at page 46, line 43 skipping to change at page 49, line 43
7.1.5. Denial of Service Protection 7.1.5. Denial of Service Protection
A denial of service attacker sends messages to a GDOI entity to cause A denial of service attacker sends messages to a GDOI entity to cause
that entity to perform unneeded message authentication operations. that entity to perform unneeded message authentication operations.
GDOI uses the Phase 1 cookie mechanism to identify spurious messages GDOI uses the Phase 1 cookie mechanism to identify spurious messages
prior to cryptographic hash processing. This is a "weak" form of prior to cryptographic hash processing. This is a "weak" form of
denial of service protection in that the GDOI entity must check for denial of service protection in that the GDOI entity must check for
good cookies, which can be successfully imitated by a sophisticated good cookies, which can be successfully imitated by a sophisticated
attacker. The Phase 1 cookie mechanism is stateful, and commits attacker. The Phase 1 cookie mechanism is stateful, and commits
memory resources for cookies, but stateless cookies are a better memory resources for cookies.
defense against denial of service attacks.
7.2. GROUPKEY-PULL Exchange 7.2. GROUPKEY-PULL Exchange
The GROUPKEY-PULL exchange allows a group member to request SAs and The GROUPKEY-PULL exchange allows a group member to request SAs and
keys from a GCKS. It runs as a "phase 2" protocol under protection keys from a GCKS. It runs as a "phase 2" protocol under protection
of the Phase 1 security association. of the Phase 1 security association.
7.2.1. Authentication 7.2.1. Authentication
Peer authentication is not required in the GROUPKEY-PULL protocol. Peer authentication is not required in the GROUPKEY-PULL protocol.
skipping to change at page 47, line 29 skipping to change at page 50, line 29
Confidentiality is provided by the Phase 1 security association, Confidentiality is provided by the Phase 1 security association,
after the manner described in [RFC2409]. after the manner described in [RFC2409].
7.2.3. Man-in-the-Middle Attack Protection 7.2.3. Man-in-the-Middle Attack Protection
Message authentication (described above) includes a secret known only Message authentication (described above) includes a secret known only
to the group member and GCKS when constructing a HASH payload. This to the group member and GCKS when constructing a HASH payload. This
prevents man-in-the-middle and connection-hijacking attacks because prevents man-in-the-middle and connection-hijacking attacks because
an attacker would not be able to change the message undetected. an attacker would not be able to change the message undetected.
7.2.4. Replay/Reflection Attack Protection 7.2.4. Replay Protection
Nonces provide freshness of the GROUPKEY-PULL exchange. The group A GROUPKEY-PULL message identifies its messages using a cookie pair
member and GCKS exchange nonce values first two messages. These from the Phase 1 exchange that precedes it. A GROUPKEY-PULL message
nonces are included in subsequent HASH payload calculations. The with invalid cookies will be discarded. Therefore, GDOI messages
Group member and GCKS MUST NOT perform any computationally expensive that are not associated with a current GDOI session will be discarded
tasks before receiving a HASH with its own nonce included. The GCKS without further processing.
MUST NOT update the group management state (e.g., LKH key tree) until
it receives the third message in the exchange with a valid HASH
payload including its own nonce.
Implementations SHOULD keep a record of recently received GROUPKEY- Replayed GDOI messages that are associated with a current GDOI
PULL messages and reject messages that have already been processed. session will be decrypted and authenticated. The M-ID in the HDR
This enables an early discard of the replayed messages. identifies a session. Replayed packets will be processed according
to the state machine of that session. Packets not matching that
state machine will be discarded without processing.
7.2.5. Denial of Service Protection 7.2.5. Denial of Service Protection
A GROUPKEY-PULL message identifies its messages using a cookie pair GCKS implementations SHOULD keep a record of recently received
from the Phase 1 exchange that precedes it. The cookies provide a GROUPKEY-PULL messages (e.g., a hash of the packet) and reject
weak form of denial of service protection as described above, in the messages that have already been processed. This provides Denial of
sense that a GROUPKEY-PULL message with invalid cookies will be Service and Replay Protection of previously sent messages. An
discarded. implementation MAY choose to rate-limit the receipt of GDOI messages
in order to mitigate avoid overloading its computational resources.
The replay protection mechanisms described above provide the basis The GCKS SHOULD NOT perform any computationally expensive tasks
for denial of service protection. before receiving a HASH with its own nonce included. The GCKS MUST
NOT update the group management state (e.g., LKH key tree, SID-
counter) until it receives the third message in the exchange with a
valid HASH payload including its own nonce.
7.2.6. Authorization 7.2.6. Authorization
A GCKS implementation should maintain an authorization list of A GCKS implementation SHOULD maintain an authorization list of
authorized group members. Group members will specifically list each authorized group members. Group members MUST specifically list each
authorized GCKS in its Group Peer Authorization Database (GPAD) authorized GCKS in its Group Peer Authorization Database (GPAD)
[RFC5374]. [RFC5374].
7.3. GROUPKEY-PUSH Exchange 7.3. GROUPKEY-PUSH Exchange
The GROUPKEY-PUSH exchange is a single message that allows a GCKS to The GROUPKEY-PUSH exchange is a single message that allows a GCKS to
send SAs and keys to group members. This is likely to be sent to all send SAs and keys to group members. This is likely to be sent to all
members using an IP multicast group. This provides an efficient members using an IP multicast group. This message provides an
rekey and group membership adjustment capability. efficient rekey and group membership adjustment capability.
7.3.1. Authentication 7.3.1. Authentication
The GROUPKEY-PULL exchange identifies a public key that is used for The GROUPKEY-PULL exchange distributes a public key that is used for
message authentication. The GROUPKEY-PUSH message is digitally message authentication. The GROUPKEY-PUSH message is digitally
signed using the corresponding private key held by the GCKS or its signed using the corresponding private key held by the GCKS. This
delegate. This digital signature provides source authentication for digital signature provides source authentication for the message.
the message. Thus, GDOI protects the GCKS from impersonation in Thus, GDOI protects the GCKS from impersonation in group
group environments. environments.
7.3.2. Confidentiality 7.3.2. Confidentiality
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key The GCKS encrypts the GROUPKEY-PUSH message with an encryption key
that was established by the GROUPKEY-PULL exchange. that was distributed in the GROUPKEY-PULL exchange or a previous
GROUPKEY-PUSH exchange. The encryption key may be a simple KEK, or
the result of a group management method (e.g., LKH) calculation.
7.3.3. Man-in-the-Middle Attack Protection 7.3.3. Man-in-the-Middle Attack Protection
This combination of confidentiality and message authentication This combination of confidentiality and message authentication
services protects the GROUPKEY-PUSH message from man-in-middle and services protects the GROUPKEY-PUSH message from man-in-middle and
connection-hijacking attacks. connection-hijacking attacks.
7.3.4. Replay/Reflection Attack Protection 7.3.4. Replay/Reflection Attack Protection
The GROUPKEY-PUSH message includes a monotonically increasing The GROUPKEY-PUSH message includes a monotonically increasing
sequence number to protect against replay and reflection attacks. A sequence number to protect against replay and reflection attacks. A
group member will recognize a replayed message by comparing the group member will discard sequence numbers associated with the
sequence number to a sliding window, in the same manner as the ESP current KEK SPI that have the same or lower value as the most
protocol uses sequence numbers. recently received replay number.
Implementations SHOULD keep a record of recently received GROUPKEY- Implementations SHOULD keep a record (e.g., a hash value) of recently
PUSH messages and reject duplicate messages. This enables an early received GROUPKEY-PUSH messages and reject duplicate messages prior
to performing cryptographic operations. This enables an early
discard of the replayed messages. discard of the replayed messages.
7.3.5. Denial of Service Protection 7.3.5. Denial of Service Protection
A cookie pair identifies the security association for the GROUPKEY- A cookie pair identifies the security association for the GROUPKEY-
PUSH message. The cookies thus serve as a weak form of denial-of- PUSH message. The cookies thus serve as a weak form of denial-of-
service protection for the GROUPKEY-PUSH message. service protection for the GROUPKEY-PUSH message.
The digital signature used for message authentication has a much The digital signature used for message authentication has a much
greater computational cost than a message authentication code and greater computational cost than a message authentication code and
skipping to change at page 49, line 32 skipping to change at page 52, line 37
where the least expensive cryptographic operation is performed first. where the least expensive cryptographic operation is performed first.
The group member first decrypts the message using a symmetric cipher. The group member first decrypts the message using a symmetric cipher.
If it is a validly formed message then the sequence number is checked If it is a validly formed message then the sequence number is checked
against the replay window. Only if the sequence number is valid is against the replay window. Only if the sequence number is valid is
the digital signature verified. Thus in order for a denial of the digital signature verified. Thus in order for a denial of
service attack to be mounted, an attacker would need to know both the service attack to be mounted, an attacker would need to know both the
symmetric encryption key used for confidentiality, and a valid symmetric encryption key used for confidentiality, and a valid
sequence number. Generally speaking this means only current group sequence number. Generally speaking this means only current group
members can effectively deploy a denial of service attack. members can effectively deploy a denial of service attack.
7.3.6. Forward Access Control 7.4. Forward and Backward Access Control
If a group management algorithm (such as LKH) is used, forward access Through GROUPKEY-PUSH, the GDOI supports group management methods
control may not be ensured in some cases. This can happen if some such as LKH (section 5.4 of [RFC2627]) that have the property of
group members are denied access to the group in the same GROUPKEY- denying access to a new group key by a member removed from the group
PUSH message as new policy and TEKs are delivered to the group. As (forward access control) and to an old group key by a member added to
discussed in Section 1.5.1, forward access control can be maintained the group (backward access control). The concepts "forward access
by sending multiple GROUPKEY-PUSH messages, where the group control" and "backward access control" have also been described as
membership changes are sent from the GCKS separate from the new "perfect forward security" and "perfect backward security"
policy and TEKs. respectively in the literature [RFC2627].
Group management algorithms providing forward and backward access
control other than LKH have been proposed in the literature,
including OFT [OFT] and Subset Difference [NNL]. These algorithms
could be used with GDOI, but are not specified as a part of this
document.
7.4.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm
new Data-security SAs are usually also needed. New SAs ensure that
members who were denied access can no longer participate in the
group.
If forward access control is a desired property of the group, new
Data-security SAs MUST NOT be included in a GROUPKEY-PUSH message
which changes group membership. This is required because the new
Data-security SAs are not protected with the new KEK. Instead, two
sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first
changing the KEK, and the second (protected with the new KEK)
distributing the new Data-security SAs.
Note that in the above sequence, although the new KEK can effectively
deny access to the group to some group members they will be able to
view the new KEK policy. If forward access control policy for the
group includes keeping the KEK policy secret as well as the KEK
itself secret, then two GROUPKEY-PUSH messages changing the KEK must
occur before the new Data-security SAs are transmitted.
If other methods of using LKH or other group management algorithms
are added to GDOI, those methods MAY remove the above restrictions
requiring multiple GROUPKEY-PUSH messages, providing those methods
specify how forward access control policy is maintained within a
single GROUPKEY-PUSH message.
7.4.2. Backward Access Control Requirements
If backward access control is a desired property of the group, a new
member MUST NOT be given Data-security SAs that were used prior to it
joining the group. This can be accomplished if the GCKS provides
only the Rekey SA to the new member in a GROUPKEY-PULL exchange,
followed by a GROUPKEY-PUSH message that both deletes current Data-
security SAs, and provides new replacement Data-security SAs. The
new group member will effectively join the group at such time as the
existing members begin sending on the Data-security SAs.
If there is a possibility that the new group member has stored
GROUPKEY-PUSH messages delivered prior to joining the group, then the
above procedure is not sufficient. In this case, to achieve backward
access control the GCKS needs to return a new Rekey SA to the group
member in a GROUPKEY-PULL exchange rather than the existing one. The
GCKS would subsequently deliver two GROUPKEY-PUSH messages. The
first, intended for existing group members, distributes the new
Rekey-SA to existing members. The GCKS would then deliver the second
GROUPKEY-PUSH message using the new Rekey-SA that both deletes
current Data-security SAs, and provides new replacement Data-security
SAs. Both preexisting and new members would process the second
GROUPKEY-PUSH message, and all would be able to communicate using the
new Data-security SAs.
7.5. Derivation of keying material
A GCKS distributes keying material associated with Data-Security SAs
and the Rekey SA. Because these security associations are used by a
set of group members, this keying material is not related to any pair
wise connection, and there is no requirement in The Multicast Group
Security Architecture [RFC3740] for group members to permute group
keying material. Because the GCKS is solely responsible for the
generation of the keying material, the GCKS MUST derive the keying
material using a strong random number generator. Because there are
no interoperability concerns with key generation, no method is
prescribed in GDOI.
8. IANA Considerations 8. IANA Considerations
This memo requests IANA to make several additions to existing This memo requests IANA to make several additions to existing
registries, and to add sever new GDOI registries. When the new registries, and to add sever new GDOI registries. When the new
registries are added, the following terms are to be applied as registries are added, the following terms are to be applied as
described in the Guidelines for Writing an IANA Considerations described in the Guidelines for Writing an IANA Considerations
Section in RFCs [RFC5226]: Standards Action, and Private Use. Section in RFCs [RFC5226]: Standards Action, and Private Use.
8.1. Additions to current registries 8.1. Additions to current registries
skipping to change at page 50, line 36 skipping to change at page 55, line 36
A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned
from the RESERVED space. The new algorithm id should be called from the RESERVED space. The new algorithm id should be called
GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a
value of TBD-5. value of TBD-5.
A new Next Payload Type [ISAKMP-REG] should be assigned. The new A new Next Payload Type [ISAKMP-REG] should be assigned. The new
type is called "SA Group Associated Policy (GAP)", and has a value of type is called "SA Group Associated Policy (GAP)", and has a value of
TBD-1. TBD-1.
A new Key Download Type Section 5.6 should be assigned. The new type
is called "SID", and has a value of TBD-7.
8.2. New registries 8.2. New registries
A new namespace should be created in the GDOI Payloads registry A new namespace should be created in the GDOI Payloads registry
[GDOI-REG] to describe SA GAP Payload Values. The following rules [GDOI-REG] to describe SA GAP Payload Values. The following rules
apply to define the attributes in SA SSA Payload Values: apply to define the attributes in SA SSA Payload Values:
Attribute Type Value Type Attribute Type Value Type
---- ----- ---- ---- ----- ----
RESERVED 0 RESERVED 0
ACTIVATION_TIME_DELAY 1 B ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B DEACTIVATION_TIME_DELAY 2 B
SENDER_ID 3 V SENDER_ID_REQUEST 3 B
Standards Action 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767
A new IPsec Security Association Attribute [ISAKMP-REG] defining the A new IPsec Security Association Attribute [ISAKMP-REG] defining the
preservation of IP addresses is needed. The attribute class is preservation of IP addresses is needed. The attribute class is
called "Address Preservation", and it is a Basic type. The following called "Address Preservation", and it is a Basic type. The following
rules apply to define the values of the attribute: rules apply to define the values of the attribute:
Name Value Name Value
---- ----- ---- -----
Reserved 0 Reserved 0
None 1 None 1
skipping to change at page 52, line 5 skipping to change at page 56, line 44
Name Value Name Value
---- ----- ---- -----
Reserved 0 Reserved 0
Sender-Only 1 Sender-Only 1
Receiver-Only 2 Receiver-Only 2
Symmetric 3 Symmetric 3
Standards Action 4-61439 Standards Action 4-61439
Private Use 61440-65535 Private Use 61440-65535
When the SID "Key Download Type" (described in the previous section)
has a set of attributes. The attributes must follow the format
defined in ISAKMP (Section 3.3 of [RFC2408]). In the table,
attributes defined as TV are marked as Basic (B); attributes defined
as TLV are marked as Variable (V).
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Standards Action 3-128
Private Use 129-255
Unassigned 256-32767
8.3. Cleanup of existing registries
Several existing GDOI Payloads registries do not use the terms in RFC
5226 and/or do not describe the entire range of possible values. The
following sections correct these registries.
8.3.1. Pop Algorithm
Values 4-127 are to be designated Standards Action. Values 256-32767
are to be added and designated Unassigned.
8.3.2. KEK Attributes
Values 9-127 are to added and designated Standards Action. Values
128-255 are to be added and designated Private Use. Values 256-32767
are to be added and designated Unassigned.
8.3.3. KEK_MANAGEMENT_ALGORITHM
Values 2-127 are to be designated Standards Action. Values 256-65535
are to be added and designated Unassigned.
8.3.4. KEK_ALGORITHM
Values 4-127 are to be designated Standards Action. Values 256-65535
are to be added and designated Unassigned.
8.3.5. SIG_HASH_ALGORITHM
Values 3-127 are to be designated Standards Action. Values 256-65535
are to be added and designated Unassigned.
8.3.6. SIG_ALGORITHM
Values 4-127 are to be designated Standards Action. Values 256-65535
are to be added and designated Unassigned.
8.3.7. SA TEK Payload Values
Values 2-127 are to be designated Standards Action.
8.3.8. Key Download Types
Values 4-127 are to be designated Standards Action.
8.3.9. TEK Download Type
Values 4-127 are to be added and designated Standards Action. Values
128-255 are to be added and designated Private Use. Values 256-32767
are to be added and designated Unassigned.
8.3.10. KEK Download Type
Values 3-127 are to be designated Standards Action. Values 128-255
are to be added and designated Private Use. Values 256-32767 are to
be added and designated Unassigned.
8.3.11. LKH Download Type
Values 4-127 are to be designated Standards Action. Values 256-32767
are to be added and designated Unassigned.
9. Acknowledgements 9. Acknowledgements
This text updates RFC 3547, and the authors with to thank Mark This text updates RFC 3547, and the authors wish to thank Mark
Baugher and Hugh Harney for their extensive contributions. Baugher and Hugh Harney for their extensive contributions that led to
this updated version of GDOI.
The authors are grateful to Catherine Meadows for her careful review The authors are grateful to Catherine Meadows for her careful review
and suggestions for mitigating the man-in-the-middle attack she had and suggestions for mitigating the man-in-the-middle attack she had
previously identified. Yoav Nir provided many useful technical and previously identified. Yoav Nir and Vincent Roca provided many
editorial comments and suggestions for improvement. useful technical and editorial comments and suggestions for
improvement.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-msec-ipsec-group-counter-modes]
McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic",
draft-ietf-msec-ipsec-group-counter-modes-06 (work in
progress), September 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic", RFC 6054,
November 2010.
10.2. Informative References 10.2. Informative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[FIPS186-3] [FIPS186-3]
"Digital Signature Standard (DSS)", United States of "Digital Signature Standard (DSS)", United States of
America, National Institute of Science and America, National Institute of Science and
skipping to change at page 54, line 25 skipping to change at page 61, line 22
Interpretation (GDOI) Payload Type Values", IANA Registry, Interpretation (GDOI) Payload Type Values", IANA Registry,
December 2004, December 2004,
<http://www.iana.org/assignments/gdoi-payloads>. <http://www.iana.org/assignments/gdoi-payloads>.
[HD03] Hardjono, T. and L. Dondeti, "Multicast and Group [HD03] Hardjono, T. and L. Dondeti, "Multicast and Group
Security", Artech House Computer Security Series, ISBN Security", Artech House Computer Security Series, ISBN
1-58053-342-6, 2003. 1-58053-342-6, 2003.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-01 Authentication Code Policy", draft-weis-gdoi-mac-tek-02
(work in progress), June 2010. (work in progress), March 2011.
[ISAKMP-REG] [ISAKMP-REG]
"'Magic Numbers' for ISAKMP Protocol", "'Magic Numbers' for ISAKMP Protocol",
<http://www.iana.org/assignments/isakmp-registry>. <http://www.iana.org/assignments/isakmp-registry>.
[MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and [MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and
Defending the GDOI Protocol", ESORICS 2004 pp. 53-72, Defending the GDOI Protocol", ESORICS 2004 pp. 53-72,
September 2004. September 2004.
[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and
skipping to change at page 55, line 19 skipping to change at page 62, line 18
[RFC2407] Piper, D., "The Internet IP Security Domain of [RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998. Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999. Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 55, line 48 skipping to change at page 62, line 44
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005. RFC 4106, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005. RFC 4309, December 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", "Kerberized Internet Negotiation of Keys (KINK)",
RFC 4430, March 2006. RFC 4430, March 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006. May 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)", the Elliptic Curve Digital Signature Algorithm (ECDSA)",
skipping to change at page 56, line 39 skipping to change at page 63, line 43
May 2008. May 2008.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
June 2010. June 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium San Diego, 1996.
[SP.800-131] [SP.800-131]
Barker, E. and A. Roginsky, "Recommendation for the Barker, E. and A. Roginsky, "Recommendation for the
Transitioning of Cryptographic Algorithms and Key Transitioning of Cryptographic Algorithms and Key
Lengths", United States of America, National Institute of Lengths", United States of America, National Institute of
Science and Technology DRAFT NIST Special Publication 800- Science and Technology DRAFT NIST Special Publication 800-
131, June 2010. 131, June 2010.
[SP.800-38A] [SP.800-38A]
Dworkin, M., "Recommendation for Block Cipher Modes of Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", United States of America, National Institute Operation", United States of America, National Institute
of Science and Technology NIST Special Publication 800-38A of Science and Technology NIST Special Publication 800-38A
2001 Edition, December 2001. 2001 Edition, December 2001.
[STS] Diffie, W., Van Oorschot, P., and M. Wiener, Appendix A. Extending GDOI
"Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic
Publishers, 1992.
Appendix A. Alternate GDOI Phase 1 protocols A.1. Alternate GDOI Phase 1 protocols
This section describes a manner in which other protocols could be This section describes a manner in which other protocols could be
used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1
protocol. However, they are not specified as a part of this protocol. However, they are not specified as a part of this
document. A separate document MUST be written in order for another document. A separate document MUST be written in order for another
protocol to be used as a GDOI Phase 1 protocol. protocol to be used as a GDOI Phase 1 protocol.
Other possible phase 1 protocols are also described in [RFC4046]. Other possible phase 1 protocols are also described in [RFC4046].
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Any GDOI phase 1 protocol MUST satisfy the requirements specified in
Section 2 of this document. Section 2 of this document.
A.1. IKEv2 Exchange A.1.1. IKEv2 Exchange
Version 2 of the IKE protocol (IKEv2) [RFC5996] has been published. Version 2 of the IKE protocol (IKEv2) [RFC5996] has been published.
That protocol simplifies IKE processing, and combines the two phases That protocol simplifies IKE processing, and combines the two phases
of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during phase 1, of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during phase 1,
which was not possible in IKE. However, IKEv2 also defines a phase 2 which was not possible in IKE. However, IKEv2 also defines a phase 2
protocol. The phase 2 protocol is protected by the Phase 1, similar protocol. The phase 2 protocol is protected by the Phase 1, similar
in concept to how IKE Quick Mode is protected by the IKE Phase 1 in concept to how IKE Quick Mode is protected by the IKE Phase 1
protocols in [RFC2409]. protocols in [RFC2409].
It would be possible to define GDOI as a phase 2 protocol protected It would be possible to define GDOI as a phase 2 protocol protected
by an IKEv2 initial exchange. Alternatively, it would be possible to by an IKEv2 initial exchange. Alternatively, it would be possible to
define a new protocol re-using some of the IKEv2 initial exchange define a new protocol re-using some of the IKEv2 initial exchange
(e.g., IKE_SA_INIT). (e.g., IKE_SA_INIT).
A.2. KINK Protocol A.1.2. KINK Protocol
The Kerberized Internet Negotiation of Keys (KINK) [RFC4430] has The Kerberized Internet Negotiation of Keys (KINK) [RFC4430] has
defined a method of encapsulating an IKEv1 Quick Mode [RFC2409] defined a method of encapsulating an IKEv1 Quick Mode [RFC2409]
encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK
provides a low-latency, computationally inexpensive, easily managed, provides a low-latency, computationally inexpensive, easily managed,
and cryptographically sound method of setting up IPsec security and cryptographically sound method of setting up IPsec security
associations. associations.
The KINK message format includes a GDOI field in the KINK header. The KINK message format includes a DOI field in the KINK header. The
The [RFC4430] document defines the DOI for the IPsec DOI. [RFC4430] document defines the DOI for the IPsec DOI.
A new DOI for KINK could be defined which would encapsulate a A new DOI for KINK could be defined which would encapsulate a
GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP
payloads. As such, GDOI would benefit from the computational payloads. As such, GDOI would benefit from the computational
efficiencies of KINK. efficiencies of KINK.
Appendix B. Significant Changes from RFC 3547 A.2. Supporting new SA TEK types
Not all secure multicast or multimedia applications can use IPsec ESP
or AH. Many Real Time Transport Protocol applications, for example,
require security above the IP layer to preserve RTP header
compression efficiencies and transport-independence [RFC3550].
Alternatively, GDOI can distribute message authentication code (MAC)
policy and keys for legacy applications that have defined their own
security associations [I-D.weis-gdoi-mac-tek].
In order to add a new data security protocol, a new RFC MUST specify
the data-security SA parameters conveyed by GDOI for that security
protocol; these parameters are listed in Section 5.5.2 of this
document.
Data security protocol SAs MUST protect group traffic. GDOI provides
no restriction on whether that group traffic is transmitted as
unicast or multicast packets.
Appendix B. GDOI Applications
GDOI can be used to distribute keys for several secure multicast
applications, where different applications have different key
management requirements. This section outlines two example ways that
GDOI can be used. Other examples can be found in Section 10 of
[HD03].
A simple application is secure delivery of periodic multicast content
over an organization's IP network, perhaps a multicast video
broadcast. Assuming the content delivery time frame is bounded and
the group membership is not expected to change over time, there is no
need for group policy to include a GROUPKEY-PUSH exchange, and
there's no need for the GCKS to distribute a Re-key SA. Thus, the
GDOI GCKS may only need to distribute a single set of Data-Security
SAs to protect the time-bounded broadcast.
In contrast, a persistent IP multicast application (e.g., stock-
ticker delivery service) may have many group members, where the group
membership changes over time. A periodic change of Data-security SAs
may be desirable, and the potential for change in group membership
requires the use of a group management method enabling de-
authorization of group members. The GDOI GCKS will distribute the
current set of Data-Security SAs and a Re-key SA to registering group
members. It will then deliver regularly-scheduled GROUPKEY-PUSH
protocol delivering the new SAs for the group. Additionally, the
group membership on the GCKS may be frequently adjusted, which will
result in GROUPKEY-PUSH exchange delivering a new Rekey SAs protected
by a group management method. Each GROUPKEY-PUSH may include Data-
security SAs and/or a Rekey SA.
In each example the relevant policy is defined on the GCKS and
relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH
protocols. Specific policy choices configured by the GCKS
administrator depends on each application.
Appendix C. Significant Changes from RFC 3547
The following significant changes have been made from RFC 3547. The following significant changes have been made from RFC 3547.
o The Proof of Possession (POP) payload was removed from the o The Proof of Possession (POP) payload was removed from the
GROUPKEY-PULL exchange. It provided an alternate form of GROUPKEY-PULL exchange. It provided an alternate form of
authorization, but its use was underspecified. Furthermore, authorization, but its use was underspecified. Furthermore,
Meadows and Pavlovic [MP04] discussed a man-in-the-middle attack Meadows and Pavlovic [MP04] discussed a man-in-the-middle attack
on the POP authorization method, which would require changes to on the POP authorization method, which would require changes to
its semantics. No known implementation of RFC 3547 supported the its semantics. No known implementation of RFC 3547 supported the
POP payload, so it was removed. Removal of the POP payload POP payload, so it was removed. Removal of the POP payload
skipping to change at page 59, line 45 skipping to change at page 68, line 45
o Supported cryptographic algorithms were changed to meet current o Supported cryptographic algorithms were changed to meet current
guidance. Implementations are required to support AES with 128- guidance. Implementations are required to support AES with 128-
bit keys to encrypt the rekey message, and SHA-256 for bit keys to encrypt the rekey message, and SHA-256 for
cryptographic signatures. The use of DES is deprecated. cryptographic signatures. The use of DES is deprecated.
o New protocol support for AH. o New protocol support for AH.
o New protocol definitions were added to conform to the most recent o New protocol definitions were added to conform to the most recent
Security Architecture for the Internet Protocol [RFC4301] and the Security Architecture for the Internet Protocol [RFC4301] and the
Multicast Extensions to the Security Architecture for the Internet Multicast Extensions to the Security Architecture for the Internet
Protocol[RFC5374]. This includes addition of the GAP payload Protocol[RFC5374]. This includes addition of the GAP payload.
o New protocol definitions were added to support Using Counter Modes o New protocol definitions and semantics were added to support Using
with ESP and AH to Protect Group Counter Modes with ESP and AH to Protect Group Traffic[RFC6054].
Traffic[I-D.ietf-msec-ipsec-group-counter-modes].
o Specification to IANA to better clarify the use of the GDOI
Payloads registry.
Authors' Addresses Authors' Addresses
Brian Weis Brian Weis
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, California 95134-1706 San Jose, California 95134-1706
USA USA
Phone: +1-408-526-4796 Phone: +1-408-526-4796
 End of changes. 168 change blocks. 
617 lines changed or deleted 887 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/