draft-ietf-msec-gdoi-update-11.txt   rfc6407.txt 
Obsoletes: 3547 (once approved) B. Weis Internet Engineering Task Force (IETF) B. Weis
Internet-Draft S. Rowles Request for Comments: 6407 S. Rowles
Intended status: Standards Track Cisco Systems Obsoletes: 3547 Cisco Systems
Expires: February 13, 2012 T. Hardjono Category: Standards Track T. Hardjono
MIT ISSN: 2070-1721 MIT
August 12, 2011 October 2011
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-11
Abstract Abstract
This document describes the Group Domain of Interpretation (GDOI) This document describes the Group Domain of Interpretation (GDOI)
protocol specified in RFC 3547. The GDOI provides group key protocol specified in RFC 3547. The GDOI provides group key
management to support secure group communications according to the management to support secure group communications according to the
architecture specified in RFC 4046. The GDOI manages group security architecture specified in RFC 4046. The GDOI manages group security
associations, which are used by IPsec and potentially other data associations, which are used by IPsec and potentially other data
security protocols. This document replaces RFC 3547. security protocols. This document replaces RFC 3547.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 13, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6407.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 22 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7
2. GDOI Phase 1 Protocol . . . . . . . . . . . . . . . . . . . . 8
2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 9 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 10 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 12
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13
3.3. Group Member Operations . . . . . . . . . . . . . . . . . 13 3.5. Counter-Modes of Operation . . . . . . . . . . . . . . . . 14
3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 14 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16
3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 15 4.1. Use of Signature Keys . . . . . . . . . . . . . . . . . . 17
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 18 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17
4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 19 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 19 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19
4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 19 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
4.4. Group Member Operations . . . . . . . . . . . . . . . . . 20 5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.3. SA KEK Payload . . . . . . . . . . . . . . . . . . . . . . 21
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 22 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 22 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Security Association Payload . . . . . . . . . . . . . . . 23 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 24 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 44
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 31 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 33 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 38 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 47 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 50 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.4. Forward and Backward Access Control . . . . . . . . . . . 51
7.5. Derivation of Keying Material . . . . . . . . . . . . . . 53
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 52 8.1. Additions to Current Registries . . . . . . . . . . . . . 53
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 53 8.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 54
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 55 8.3. Cleanup of Existing Registries . . . . . . . . . . . . . . 55
7.4. Forward and Backward Access Control . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
7.5. Derivation of keying material . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . . 58
8.1. Additions to current registries . . . . . . . . . . . . . 59 Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 62
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 59 Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 62
8.3. Cleanup of existing registries . . . . . . . . . . . . . . 61
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 68
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
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 Internet Security Association and Key Management Protocol
key management system. The GDOI distributes security associations (ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key
(SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and management system. The GDOI distributes security associations (SAs)
potentially other data security protocols used in group applications. for IPsec Authentication Header (AH) [RFC4302] and Encapsulating
The GDOI uses the group key management model defined in [RFC4046], Security Payload (ESP) [RFC4303] protocols and potentially other data
and described more generally by "The Multicast Group Security security protocols used in group applications. The GDOI uses the
Architecture" [RFC3740]. group key management model defined in [RFC4046], and described more
generally by "The Multicast Group Security 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
A group member contacts ("registers with") a GCKS to join the group. 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")
with 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 (Section 2.3 of
Phase 1 security association provides mutual authentication and [RFC2408]). A Phase 1 security association provides mutual
authorization, and a security association that is used by the authentication and authorization, and a security association that is
protocol participants to execute a phase 2 exchange. This document used by the protocol participants to execute a Phase 2 exchange.
incorporates (i.e., uses but does not re-define) the Phase 1 security This document incorporates (i.e., uses but does not redefine) the
association definition from the Internet DOI [RFC2407], [RFC2409]. Phase 1 security association definition from the Internet DOI
The GDOI includes two new phase 2 ISAKMP exchanges (protocols), as [RFC2407], [RFC2409]. Although RFCs 2407, 2408, and 2409 were
well as necessary new payload definitions to the ISAKMP standard (p. obsoleted by [RFC4306] (and subsequently [RFC5996]), they are used by
14 of [RFC2408]). These two new protocols are: this document because the protocol definitions remain relevant for
ISAKMP protocols other than IKEv2.
The GDOI includes two new Phase 2 ISAKMP exchanges (protocols), as
well as necessary new payload definitions to the ISAKMP standard
(Section 2.1 of [RFC2408]). These two new protocols are:
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 protocol group members using a IP multicast address. The rekey protocol
is 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 ("Rekey SA") are 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 7.4), at the conclusion of the GROUPKEY-PUSH described in Section 7.4), at the conclusion of the GROUPKEY-PUSH
exchange some members of the group may have been de-authorized exchange, some members of the group may have been de-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 |
skipping to change at page 5, line 35 skipping to change at page 5, line 29
| +-----------------+ +-----------------+ | | +-----------------+ +-----------------+ |
| | ^ | | | ^ |
| v | | | v | |
| +-Data Security Protocol (e.g., ESP)-+ | | +-Data Security Protocol (e.g., ESP)-+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 1. Group Key Management Model Figure 1. Group Key Management Model
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 Rekey 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.
GDOI defines several payload types used to distribute policy and GDOI defines several payload types used to distribute policy and
keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols: keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols:
Security Association (SA), SA KEK, SA TEK, Group Associated Policy Security Association (SA), SA KEK, SA TEK, Group Associated Policy
(GAP) , Sequence Number (SEQ), and Key Download (KD). Format and (GAP), Sequence Number (SEQ), and Key Download (KD). Format and
usage of these payloads are defined in later sections of this memo. usage of these payloads are defined in later sections of this memo.
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 protocol SAs, a Re-key associations protect one or more data security protocol SAs, a Rekey
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 members. This document described the distribution of IPsec AH
and ESP Data-Security SAs. and ESP Data-Security SAs.
Group Controller/Key Server A device that defines group policy and Group Controller/Key Server A device that defines group policy and
distributes keys for that policy.[RFC3740] 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 request 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 of group policy and keying material to authorized group
members. members.
Key Encrypting Key. The symmetric cipher key used to protect the Key Encrypting Key. The symmetric cipher key used to protect the
GROUPKEY-PUSH message. GROUPKEY-PUSH message.
Logical Key Hierarchy. A group management method defined in Section Logical Key Hierarchy. A group management method defined in Section
5.4 of [RFC2627]. 5.4 of [RFC2627].
Re-key SA. The security policy protecting a GROUPKEY-PUSH protocol. Rekey SA. The security policy protecting a GROUPKEY-PUSH protocol.
SA Attribute Payload A payload that follows the Security Association SA Attribute Payload A payload that follows the Security Association
payload that describe group security attributes associated with payload and that describes group security attributes associated
the security association. SA Attribute Payloads include the with the security association. SA Attribute payloads include
SAK, SAT and GAP payloads. the SAK, SAT, and GAP payloads.
Security Parameter Index An arbitrary value that is used by a Security Parameter Index An arbitrary value that is used by a
receiver to identify a Security Association such as IPsec ESP receiver to identify a security association such as an IPsec
Security Association or a Re-key SA. ESP Security Association or a Rekey SA.
Traffic Encryption Key. The symmetric cipher key used to protect a Traffic Encryption Key. The symmetric cipher key used to protect a
data security protocol (e.g., IPsec ESP). data security protocol (e.g., IPsec ESP).
1.3. Acronyms and Abbreviations 1.3. Acronyms and Abbreviations
The following acronyms and abbreviations are used throughout this The following acronyms and abbreviations are used throughout this
document. document.
AH IP Authentication Header AH IP Authentication Header
skipping to change at page 8, line 4 skipping to change at page 7, line 47
SA Security Association SA Security Association
SAK SA KEK Payload SAK SA KEK Payload
SEQ Sequence Number Payload SEQ Sequence Number Payload
SAT SA TEK Payload SAT SA TEK Payload
SID Sender-ID SID Sender-ID
SPI Security Parameter Index SPI Security Parameter Index
SSIV Sender-Specific ID SSIV Sender-Specific IV
TEK Traffic Encryption Key TEK Traffic Encryption Key
TLV Type/Length/Value TLV Type/Length/Value
TV Type/Value TV Type/Value
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 that 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 that provides for the following protections:
o Peer Authentication o Peer Authentication
o Confidentiality o Confidentiality
o Message Integrity o Message Integrity
The following sections describe one such "phase 1" protocol. Other The following sections describe one such Phase 1 protocol. Other
protocols which may be potential "phase 1" protocols are described in protocols which may be potential Phase 1 protocols are described in
Appendix A. However, the use of the protocols listed there are not Appendix A. However, the use of the protocols listed there are not
considered part of this document. considered part of this document.
This document defines how the ISAKMP phase 1 exchanges as defined in This document defines how the ISAKMP Phase 1 exchanges as defined in
[RFC2409] can be used a "phase 1" protocol for GDOI. The following [RFC2409] can be used a Phase 1 protocol for GDOI. The following
sections define characteristics of the ISAKMP phase 1 protocols that sections define characteristics of the ISAKMP Phase 1 protocols that
are unique for these exchanges when used for GDOI. are unique for these exchanges when used for GDOI.
Section 7.1 describes how the ISAKMP Phase 1 protocols meet the Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
requirements of a GDOI "phase 1" protocol. requirements of a GDOI Phase 1 protocol.
2.1. DOI value 2.1. DOI value
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI The Phase 1 SA payload has a DOI value. That value MUST be the GDOI
DOI value as defined later in this document. DOI value as defined later in this document.
2.2. UDP port 2.2. UDP port
IANA has assigned port 848 for the use of GDOI, which allows for an IANA has assigned port 848 for the use of GDOI; this allows for an
implementation to use separate ISAKMP implementations to service GDOI implementation to use separate ISAKMP implementations to service GDOI
and IKE [RFC5996]. A GCKS SHOULD listen on this port for GROUPKEY- and the Internet Key Exchange Protocol (IKE) [RFC5996]. A GCKS
PULL exchanges, and the GCKS MAY use this port to distribute SHOULD listen on this port for GROUPKEY-PULL exchanges, and the GCKS
GROUPKEY-PUSH messages. An ISAKMP phase 1 exchange implementation MAY use this port to distribute GROUPKEY-PUSH messages. An ISAKMP
supporting NAT Traversal [RFC3947] MAY move to port 4500 to process Phase 1 exchange implementation supporting NAT traversal [RFC3947]
the GROUPKEY-PULL exchange. MAY move to port 4500 to process the GROUPKEY-PULL exchange.
3. GROUPKEY-PULL Exchange 3. GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Re-key The goal of the GROUPKEY-PULL exchange is to establish a Rekey and/or
and/or Data-security SAs at the member for a particular group. A Data-Security SAs at the member for a particular group. A Phase 1 SA
Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL
GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange
exchange downloads the data security keys (TEKs) and/or group key downloads the data security keys (TEKs) and/or group key encrypting
encrypting key (KEK) or KEK array under the protection of the Phase 1 key (KEK) or KEK array under the protection of the Phase 1 SA.
SA.
3.1. Authorization 3.1. Authorization
It is important that a group member explicitly trust entities that it It is important that a group member explicitly trust entities that it
expects to act as a GCKS for a particular group. When no expects to act as a GCKS for a particular group. When no
authorization is performed, it is possible for a rogue GDOI authorization is performed, it is possible for a rogue GDOI
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]. Group members MUST specifically list each member and a GCKS [MP04]. A group member MUST specifically list each
authorized GCKS in its Group Peer Authorization Database (GPAD) authorized GCKS in its Group Peer Authorization Database (GPAD)
[RFC5374]. A group member MUST ensure that the Phase 1 identity of [RFC5374]. A group member MUST ensure that the Phase 1 identity of
the GCKS is an authorized GCKS. the GCKS is an authorized GCKS.
It is important that a GCKS explicitly authorize group members before It is important that a GCKS explicitly authorize group members before
providing them with group policy and keying material. A GCKS providing them with group policy and keying material. A GCKS
implementation SHOULD have a method of authorizing group members implementation SHOULD have a method of authorizing group members
(e.g., by maintaining an authorization list). When the GCKS performs (e.g., by maintaining an authorization list). When the GCKS performs
authorization, it MUST use the Phase 1 identity to authorize the authorization, it MUST use the Phase 1 identity to authorize the
GROUPKEY-PULL request for group policy and keying material. GROUPKEY-PULL request for group policy and keying material.
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 ISAKMP HASH payloads which is the "key" in the keyed hash used in the ISAKMP HASH payloads
[RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1 [RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1
defined in this document, SKEYID_a is derived according to [RFC2409]. defined in this document, SKEYID_a is derived according to [RFC2409].
Each GROUPKEY-PULL message hashes a uniquely defined set of values Each GROUPKEY-PULL message hashes a uniquely defined set of values
(described below) and includes the result in the HASH payload. (described below) and includes the result in the HASH payload.
Nonces permute the HASH and provide some protection against replay Nonces permute the HASH and provide some protection against replay
attacks. Replay protection is important to protect the GCKS from attacks. Replay protection is important to protect the GCKS from
attacks that a key management server will attract. attacks that a key management server will attract.
The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as
skipping to change at page 11, line 19 skipping to change at page 10, line 21
messages will not cause the GCKS to change the state of the group messages will not cause the GCKS to change the state of the group
until it has confirmation that the initiating group member is live. until it has confirmation that the initiating group member is live.
Group Member GCKS Group Member GCKS
------------ ---- ------------ ----
(1) HDR*, HASH(1), Ni, ID --> (1) HDR*, HASH(1), Ni, ID -->
(2) <-- HDR*, HASH(2), Nr, SA (2) <-- HDR*, HASH(2), Nr, SA
(3) HDR*, HASH(3) [,GAP] --> (3) HDR*, HASH(3) [,GAP] -->
(4) <-- HDR*, HASH(4), [SEQ,] KD (4) <-- HDR*, HASH(4), [SEQ,] KD
* Protected by the Phase 1 SA, encryption occurs after HDR * Protected by the Phase 1 SA; encryption occurs after HDR
Figure 2. GROUPKEY-PULL Exchange Figure 2. GROUPKEY-PULL Exchange
Figure 2 demonstrates the four messages that are part of a GROUPKEY- Figure 2 demonstrates the four messages that are part of a GROUPKEY-
PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1 PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1
cookies and a message identifier (M-ID) as in ISAKMP. Following each cookies and a message identifier (M-ID) as in ISAKMP. Following each
HDR is a set of payloads conveying requests (messages one and three HDR is a set of payloads conveying requests (messages 1 and 3
originated by the group member, or group policy and/or keying originated by the group member), or group policy and/or keying
material (messages two and four originated by the GCKS). material (messages 2 and 4 originated by the GCKS).
Hashes are computed in the manner described within [RFC2409]. The Hashes are computed in the manner described within [RFC2409]. The
HASH computation for each message is unique, shown in Figure 2 and HASH computation for each message is unique; it is shown in Figure 2
below as HASH(n) where (n) represents the GROUPKEY-PULL message and below as HASH(n) where (n) represents the GROUPKEY-PULL message
number. Each HASH calculation is a pseudo-random function ("prf") number. Each HASH calculation is a pseudo-random function ("prf")
over the message id (M-ID) from the ISAKMP header concatenated with over the message ID (M-ID) from the ISAKMP header concatenated with
the entire message that follows the hash including all payload the entire message that follows the hash including all payload
headers, but excluding any padding added for encryption. The GM headers, but excluding any padding added for encryption. The GM
expects to find its nonce, Ni, in the HASH of a returned message. expects to find its nonce, Ni, in the HASH of a returned message, and
And the GCKS expects to see its nonce, Nr, in the HASH of a returned 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 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 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 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 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 that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the
exchange identified by message id, M-ID. 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 [ | GAP ]) 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)
In addition to the Nonce and HASH payloads, the GM identifies the In addition to the Nonce and HASH payloads, the GM identifies the
group it wishes to join through the ISAKMP ID payload. group it wishes to join through the ISAKMP ID payload.
The GCKS informs the member of the cryptographic policies of the The GCKS informs the member of the cryptographic policies of the
group in the SA payload, which describes the DOI, KEK and/or TEK group in the SA payload, which describes the DOI, KEK, and/or TEK
keying material, authentication transforms, and other group policy. keying material, authentication transforms, and other group policy.
Each SPI is also determined by the GCKS and downloaded in the SA Each SPI is also determined by the GCKS and downloaded in the SA
payload chain (see Section 5.2). The SA KEK attribute contains the payload chain (see Section 5.2). The SA KEK attribute contains the
ISAKMP cookie pair for the Re-key SA, which is not negotiated but ISAKMP cookie pair for the Rekey SA, which is not negotiated but
downloaded. Each SA TEK attribute contains a SPI as defined in downloaded. Each SA TEK attribute contains a SPI as defined in
Section 5.5 of this document. Section 5.5 of this document.
After receiving and parsing the SA payload, the GM responds with an After receiving and parsing the SA payload, the GM responds with an
acknowledgement message proving its liveness. It optionally includes acknowledgement message proving its liveness. It optionally includes
a GAP payload requesting resources. a GAP payload requesting resources.
The GCKS informs the GM of the value of the sequence number in the The GCKS informs the GM of the value of the sequence number in the
SEQ payload. This sequence number provides anti-replay state SEQ payload. This sequence number provides anti-replay state
associated with a KEK, and its knowledge ensures that the GM will not associated with a KEK, and its knowledge ensures that the GM will not
accept GROUPKEY-PUSH messages sent prior to the GM joining the group. accept GROUPKEY-PUSH messages sent prior to the GM joining the group.
The SEQ payload has no other use, and is omitted from the GROUPKEY- 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. 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 When a SEQ payload is included in the GROUPKEY-PULL exchange, it
includes the most recently used sequence number for the group. At includes the most recently used sequence number for the group. At
the conclusion of a GROUPKEY-PULL exchange, the initiating group the conclusion of a GROUPKEY-PULL exchange, the initiating group
member MUST NOT accept any rekey message with both the KEK attribute 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 SPI value and a sequence number less than or equal to the one
received during the GROUPKEY-PULL exchange. When the first group received during the GROUPKEY-PULL exchange. When the first group
member initiates a GROUPKEY-PULL exchange, the GCKS provides a member initiates a GROUPKEY-PULL exchange, the GCKS provides a
Sequence Number of zero, since no GROUPKEY-PUSH messages have yet Sequence Number of zero, since no GROUPKEY-PUSH messages have yet
been sent. Note the sequence number increments only with GROUPKEY- been sent. Note the sequence number increments only with GROUPKEY-
PUSH messages. The GROUPKEY-PULL exchange distributes the current PUSH messages. The GROUPKEY-PULL exchange distributes the current
sequence number to the group member. The sequence number resets to a sequence number to the group member. The sequence number resets to a
value of one with the usage of a new KEK attribute. Thus the first value of one with the usage of a new KEK attribute. Thus, the first
packet sent for a given Rekey SA will have a Sequence Number of 1. packet sent for a given Rekey SA will have a Sequence Number of 1.
The sequence number increments with each successive rekey. The sequence number increments with each successive rekey.
The GCKS always returns a KD payload containing keying material to The GCKS always returns a KD payload containing keying material to
the GM. If a Re-key SA is defined in the SA payload, then KD will the GM. If a Rekey SA is defined in the SA payload, then KD will
contain the KEK; if one or more Data-security SAs are defined in the contain the KEK; if one or more Data-Security SAs are defined in the
SA payload, KD will contain the TEKs. SA payload, KD will contain the TEKs.
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).
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]). The Commit flag is not useful because there is no [RFC2408]). The Commit flag is not useful because there is no
synchronization between the GROUPKEY-PULL exchange and the data synchronization between the GROUPKEY-PULL exchange and the data
traffic protected by the policy distributed by the GROUPKEY-PULL traffic protected by the policy distributed by the GROUPKEY-PULL
exchange. exchange.
3.3. Group Member Operations 3.3. Group Member Operations
Before a GM contacts the GCKS, it needs to determine the group Before a GM contacts the GCKS, it needs to determine the group
identifier and acceptable Phase 1 policy via an out-of-band method. identifier and acceptable Phase 1 policy via an out-of-band method.
Phase 1 is initiated using the GDOI DOI in the SA payload. Once Phase 1 is initiated using the GDOI DOI in the SA payload. Once
Phase 1 is complete, the GM state machine moves to the GDOI protocol. Phase 1 is complete, the GM state machine moves to the GDOI protocol.
To construct the first GDOI message the GM chooses Ni and creates a To construct the first GDOI message, the GM chooses Ni, creates a
nonce payload, builds an identity payload including the group nonce payload, builds an identity payload including the group
identifier, and generates HASH(1). identifier, and generates HASH(1).
Upon receipt of the second GDOI message, the GM validates HASH(2), Upon receipt of the second GDOI message, the GM validates HASH(2),
extracts the nonce Nr, and interprets the SA payload (including its extracts the nonce Nr, and interprets the SA payload (including its
SA Attribute Payloads) . The SA payload contains policy describing SA Attribute payloads) . The SA payload contains policy describing
the security protocol and cryptographic protocols used by the group. the security protocol and cryptographic protocols used by the group.
This policy describes the Re-key SA (if present), Data-security SAs, This policy describes the Rekey SA (if present), Data-Security SAs,
and other group policy. If the policy in the SA payload is and other group policy. If the policy in the SA payload is
acceptable to the GM, it continues the protocol. Otherwise, the GM acceptable to the GM, it continues the protocol. Otherwise, the GM
SHOULD tear down the Phase 1 session after notifying the GCKS with an SHOULD tear down the Phase 1 session after notifying the GCKS with an
ISAKMP Informational Exchange containing a Delete payload. ISAKMP Informational Exchange containing a Delete payload.
When constructing the third GDOI message, it first reviews each Data- When constructing the third GDOI message, it first reviews each Data-
security SA given to it. If any describe the use of a counter mode Security SA given to it. If any describe the use of a counter mode
cipher, the GM determines whether it requires more than one Sender-ID cipher, the GM determines whether it requires more than one Sender-ID
(SID) (see Section 3.5). If so, it requests the required number of (SID) (see Section 3.5). If so, it requests the required number of
Sender-IDs for its exclusive use within the counter mode nonce as Sender-IDs for its exclusive use within the counter mode nonce as
described in the Section 5.4 section of this document. The GM the described in Section 5.4 of this document. The GM then completes
completes construction of the third GDOI message by creating HASH(3). construction of the third GDOI message by creating HASH(3).
Upon receipt of the fourth GDOI message, the GM validates HASH(4). Upon receipt of the fourth GDOI message, the GM validates HASH(4).
If the SEQ payload is present, the sequence number included in the If the SEQ payload is present, the sequence number included in the
SEQ payload asserts the lowest acceptable sequence number present in SEQ payload asserts the lowest acceptable sequence number present in
a future GROUPKEY-PUSH message. But if the the KEK associated with a future GROUPKEY-PUSH message. But if the KEK associated with this
this sequence number had been previously installed, due to the sequence number had been previously installed, due to the
asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages,
this sequence number may be lower than the sequence number contained this sequence number may be lower than the sequence number contained
in the most recently received GROUPKEY-PUSH message. In this case, in the most recently received GROUPKEY-PUSH message. In this case,
the sequence number value in the SEQ payload MUST be considered stale the sequence number value in the SEQ payload MUST be considered stale
and ignored. and ignored.
The GM interprets the KD key packets, where each key packet includes The GM interprets the KD key packets, where each key packet includes
the keying material for SAs distributed in the SA payload. Keying the keying material for SAs distributed in the SA payload. Keying
material is matched by comparing the SPI in each key packet to SPI material is matched by comparing the SPI in each key packet to SPI
values previously sent in the SA payloads. Once TEK keys and policy values previously sent in the SA payloads. Once TEKs and policy are
are matched, the GM provides them to the data security subsystem, and matched, the GM provides them to the data security subsystem, and it
it is ready to send or receive packets matching the TEK policy. If is ready to send or receive packets matching the TEK policy. If this
this group has a KEK, the KEK policy and keys are marked as ready for group has a KEK, the KEK policy and keys are marked as ready for use,
use and the GM knows to expect a sequence number not less than the and the GM knows to expect a sequence number not less than the one
one distributed in the SEQ payload. The GM is now ready to receive distributed in the SEQ payload. The GM is now ready to receive
GROUPKEY-PUSH messages. GROUPKEY-PUSH messages.
If the KD payload included an LKH array of keys, the GM takes the If the KD payload included an LKH array of keys, the GM takes 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. GCKS Operations 3.4. GCKS Operations
The GCKS passively listens for incoming requests from group members. The GCKS passively listens for incoming requests from group members.
The Phase 1 authenticates the group member and sets up the secure The Phase 1 authenticates the group member and sets 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 and extracts the Ni and group identifier in the ID payload. It
that its database contains the group information for the group verifies that its database contains the group information for the
identifier, and that the GM is authorized to participate in the group identifier and that the GM is authorized to participate in the
group. 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 and the policy for the group in an SA payload, followed by SA
Attribute Payloads (i.e, SA KEK, GAP, and/or SA TEK payloads) Attribute payloads (i.e, SA KEK, GAP, and/or SA TEK payloads)
according to the GCKS policy. (See Section 5.2.1 for details on how according to the GCKS policy. (See Section 5.2.1 for details on how
the GCKS chooses which payloads to send.) the GCKS chooses which payloads to 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 If the message includes a GAP payload, it caches the requests
included in that payload for use of constructing the fourth GDOI included in that payload for the use of constructing the fourth GDOI
message. 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). If one or culminating with the root node (which is also the KEK). If one or
more Data-Security SAs distributed in the SA payload included a more Data-Security SAs distributed in the SA payload included a
counter mode of operation, the GCKS includes at least one SID value 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 KD payload, and possibly more depending on a request received
in the third GDOI message. in the third GDOI message.
3.5. Counter-modes of operation 3.5. Counter-Modes of Operation
Several new counter-based modes of operation have been specified for Several new counter-based modes of operation have been specified for
ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309],
AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These
counter-based modes require that no two senders in the group ever counter-based modes require that no two senders in the group ever
send a packet with the same Initialization Vector (IV) using the same send a packet with the same Initialization Vector (IV) using the same
cipher key and mode. This requirement is met in GDOI when the cipher key and mode. This requirement is met in GDOI when the
following requirements are met: following requirements are met:
o The GCKS distributes a unique key for each Data-Security SA. o The GCKS distributes a unique key for each Data-Security SA.
skipping to change at page 16, line 15 skipping to change at page 15, line 9
outbound direction. Alternatively, a group member MAY request more outbound direction. Alternatively, a group member MAY request more
than one SID and use them serially. This could be useful when it is 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- anticipated that the group member will exhaust their range of Data-
Security SA nonces using a single SID too quickly (e.g., before the Security SA nonces using a single SID too quickly (e.g., before the
time-based policy in the TEK expires). time-based policy in the TEK expires).
When group policy includes a counter-based mode of operation, a GCKS When group policy includes a counter-based mode of operation, a GCKS
SHOULD use the following method to allocate SID values, which ensures SHOULD use the following method to allocate SID values, which ensures
that each SID will be allocated to just one group member. that each SID will be allocated to just one group member.
1. A GCKS maintains an SID-counter, which records which SIDs have 1. A GCKS maintains a SID-counter, which records which SIDs have
been allocated. SIDs are allocated sequentially, with the first been allocated. SIDs are allocated sequentially, with the first
SID allocated to be zero. SID allocated to be zero.
2. Each time an SID is allocated, the current value of the counter 2. Each time a SID is allocated, the current value of the counter is
is saved and allocated to the group member. The SID-counter is saved and allocated to the group member. The SID-counter is then
then incremented in preparation for the next allocation. incremented in preparation for the next allocation.
3. When the GCKS distributes a Data-Security SA specifying a 3. When the GCKS distributes a Data-Security SA specifying a
counter-based mode of operation, and a group member is a sender, 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. a group member may request a count of SIDs in a GAP payload.
When the GCKS receives this request, it increments the SID- When the GCKS receives this request, it increments the SID-
counter once for each requested SID, and distributes each SID counter once for each requested SID, and distributes each SID
value to the group member. value to the group member.
4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange 4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange
originated by a sender, regardless of whether a group member had originated by a sender, regardless of whether a group member had
previously contacted the GCKS. In this way, the GCKS does not previously contacted the GCKS. In this way, the GCKS does not
have a requirement of maintaining a record of which SID values it have a requirement of maintaining a record of which SID values it
had previously allocated to each group member. More importantly, had previously allocated to each group member. More importantly,
since the GCKS cannot reliably detect whether the group member since the GCKS cannot reliably detect whether the group member
had sent data on the current group Data-Security SAs it does not had sent data on the current group Data-Security SAs, it does not
know what Data-Security counter-mode nonce values that a group know which Data-Security counter-mode nonce values a group member
member has used. By distributing new SID values, the key server has used. By distributing new SID values, the key server ensures
ensures that each time a conforming group member installs a Data- that each time a conforming group member installs a Data-Security
Security SA it will use a unique set of counter-based mode SA it will use a unique set of counter-based mode nonces.
nonces.
5. When the SID-counter maintained by the GCKS reaches its final SID 5. When the SID-counter maintained by the GCKS reaches its final SID
value, no more SID values can be distributed. Before value, no more SID values can be distributed. Before
distributing any new SID values, the GCKS MUST delete the Data- distributing any new SID values, the GCKS MUST delete the Data-
Security SAs for the group, followed by creation of new Data- Security SAs for the group, followed by creation of new Data-
Security SAs, and resetting the SID-counter to its initial value. Security SAs, and resetting the SID-counter to its initial value.
6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data- 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 Security SAs and the Rekey SA for the group. This will result in
the group members initiating a new GROUPKEY-PULL exchange, in the group members initiating a new GROUPKEY-PULL exchange, in
skipping to change at page 18, line 8 skipping to change at page 16, line 11
Rekey SA is necessary to ensure that group members receiving a Rekey SA is necessary to ensure that group members receiving a
GROUPKEY-PUSH exchange before the re-register do not GROUPKEY-PUSH exchange before the re-register do not
inadvertently use their old SIDs with the new Data-Security SAs. 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 Using the method above, at no time can two group members use the same
IV values with the same Data-Security SA key. 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
PUSH message but it can also be "pushed" using unicast delivery if IP GROUPKEY-PUSH message, but it can also be "pushed" using unicast
multicast is not possible. The GROUPKEY-PUSH message replaces a Re- delivery if IP multicast is not possible. The GROUPKEY-PUSH message
key SA KEK or KEK array, and/or creates a new Data-security SA. replaces a Rekey SA KEK or KEK array, and/or it creates a new Data-
Security SA.
GM GCKS 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 Rekey SA KEK; encryption occurs after HDR
Figure 3. GROUPKEY-PUSH Message Figure 3. GROUPKEY-PUSH Message
HDR is defined below. The SEQ payload is defined in the Payloads HDR is defined below. The SEQ payload is defined in Section 5
section. One or more D (Delete) payloads (further described in ("Payloads"). 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 group policy for replacement Re-key SA policy. The SA defines the group policy for replacement Rekey SA
and/or Data-security SAs as described in the Payloads section, with and/or Data-Security SAs as described in Section 5, with the KD
the KD providing keying material for those SAs. providing keying material for those SAs.
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 octets) before it GROUPKEY-PUSH message (excepting the SIG payload octets) before it
has been encrypted. The HASH is taken over the string 'rekey', the has 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.
The SIG payload is created using the signature of the above hash, The SIG payload is created using the signature of the above hash,
with the receiver verifying the signature using a public key with the receiver verifying the signature using a public key
retrieved in a previous GDOI exchange. The current KEK encryption retrieved in a previous GDOI exchange. The current KEK (also
key (also previously distributed in a GROUPKEY-PULL exchange or previously distributed in a GROUPKEY-PULL exchange or GROUPKEY-PUSH
GROUPKEY-PUSH message) encrypts all the payloads following the message) encrypts all the payloads following the GROUPKEY-PUSH HDR.
GROUPKEY-PUSH HDR. Note: The rationale for this order of operations Note: The rationale for this order of operations is given in
is given in Section 7.3.5. 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 Rekey 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 Rekey 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
initialized in message 4 of section 3.2. Note the first packet for initialized in message 4 of Section 3.2. Note the first packet for
the given Rekey SA encrypted with the new KEK attribute will have a the given Rekey SA encrypted with the new KEK attribute will have a
Sequence number of 1. If the SA defines an SA TEK payload, this Sequence number of 1. If the SA defines an SA TEK payload, this
informs the member that a new Data-security SA has been created, with informs the member that a new Data-Security SA has been created, with
keying material carried in KD (Section 5.6). keying material carried in KD (Section 5.6).
If the SA defines a large LKH KEK array (e.g., during group If the SA defines a large LKH KEK array (e.g., during group
initialization and batched rekeying), parts of the array MAY be sent initialization and batched rekeying), parts of the array MAY be sent
in different unique GROUPKEY-PUSH datagrams. However, each of the in different unique GROUPKEY-PUSH datagrams. However, each of the
GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH
datagram. This results in each datagram containing a sequence number datagram. This results in each datagram containing a sequence number
and the policy in the SA payload, which corresponds to the KEK array and the policy in the SA payload, which corresponds to the KEK array
portion sent in the KD payload. portion sent in the KD payload.
4.1. Use of signature keys 4.1. Use of Signature Keys
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, the cookie pair is completely determined by the GCKS. Unlike ISAKMP, the cookie pair is completely determined by the GCKS.
The cookie pair in the GDOI ISAKMP header identifies the Re-key SA to The cookie pair in the GDOI ISAKMP header identifies the Rekey SA to
differentiate the secure groups managed by a GCKS. Thus, GDOI uses differentiate the secure groups managed by a GCKS. Thus, GDOI uses
the cookie fields as an SPI. 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).
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 Section 3.1 of Flags MUST have the Encryption bit set according to Section 3.1 of
[RFC2408]. All other bits MUST be set to zero. [RFC2408]. 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 may initiate a Rekey message for one of several reasons, e.g., GCKS may initiate a Rekey message for one of several reasons, e.g.,
the group membership has changed or keys are due to expire. the group membership has changed or keys are due to 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 that is 1 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 an 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
excluded, in the case of LKH), an SA_KEK attribute is added to the excluded, in the case of LKH), an SA_KEK attribute is added to the
SA. If there are one or more new TEKs then SA_TEK attributes are SA. If there are one or more new TEKs, then SA_TEK attributes are
added to describe that policy. added to describe that policy.
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 KEKs (or a KEK update array) are 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,
generating new keys as necessary, and then distributing LKH update generating new keys as necessary, and then distributing 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). TEKs are also sent for
for each SA_TEK attribute included in the SA payload. each SA_TEK attribute included in the SA payload.
In the penultimate step, the GCKS creates the SIG payload and adds it In the penultimate step, the GCKS creates the SIG payload and adds it
to the datagram. 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. 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-
Service attack on the group). of-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. The SIG is greater than the previously received sequence number. The SIG
payload is then validated. If the signature fails, the message is payload is then validated. If the signature fails, the message is
discarded. 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
Data-security SAs being added to the system. If the KD payload Data-Security SAs being added to the system. If the KD payload
includes an LKH update array, the group member compares the LKH ID in includes an LKH update array, the group member compares the LKH ID in
each key update packet to the LKH IDs that it holds. If it finds a each key update packet to the LKH IDs that it holds. If it finds a
match, it decrypts the key using the key prior to it in the key array match, it decrypts the key using the key prior to it in the key array
and 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 one or more Data-Security SA including a If the SA payload includes one or more Data-Security SAs including a
counter-modes of operation and the receiving group member is a sender counter-mode of operation and if the receiving group member is a
for that SA, the group member uses its current SID value with the sender for that SA, the group member uses its current SID value with
Data-Security SAs to create counter-mode nonces. If it is a sender the Data-Security SAs to create counter-mode nonces. If it is a
and does not hold a current SID value, it MUST NOT install the Data- sender and does not hold a current SID value, it MUST NOT install the
Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the GCKS Data-Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the
in order to obtain an SID value (along with current group policy). GCKS in order to obtain a 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 [RFC2408]. The following payloads are defined in accordance with [RFC2408]. The following payloads are
used as defined in [RFC2408]. used as defined in [RFC2408].
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
Hash Payload (HASH) 8 Hash Payload (HASH) 8
skipping to change at page 22, line 30 skipping to change at page 19, line 42
Security Association (SA) 1 Security Association (SA) 1
Identification (ID) 5 Identification (ID) 5
Nonce (N) 10 Nonce (N) 10
Delete (D) 12 Delete (D) 12
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 (SAK) 15
SA TEK Payload (SAT) 16 SA TEK (SAT) 16
Key Download (KD) 17 Key Download (KD) 17
Sequence Number (SEQ) 18 Sequence Number (SEQ) 18
Group Associated Policy (GAP) TBD-1 Group Associated Policy (GAP) 22
All multi-octet fields in GDOI payloads representing integers are All multi-octet fields in GDOI payloads representing integers are
laid out in big endian order (also known as "most significant byte laid out in big endian order (also known as "most significant byte
first", or "network byte order"). first" or "network byte order").
All payloads including an ISAKMP Generic Payload Header create a All payloads including an ISAKMP Generic Payload Header create a
Payload Length field that includes the length of the generic payload Payload Length field that includes the length of the generic payload
header (Section 3.2 of [RFC2408]). header (Section 3.2 of [RFC2408]).
5.1. Identification Payload 5.1. Identification Payload
The Identification Payload is defined in [RFC2408]. For the GDOI, it The Identification payload is defined in [RFC2408]. 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 IPv4 or IPv6 multicast address, or may specify a more to a specific IPv4 or IPv6 multicast address, or may specify a more
general identifier, such as one that represents a set of related general identifier, such as one that represents a set of related
multicast streams. multicast streams.
When used with the GDOI, the DOI Specific ID Data field MUST be set When used with the GDOI, the DOI-Specific ID Data field MUST be set
to 0. to 0.
When used with the GDOI, the ID_KEY_ID ID Type MUST be supported by a When used with the GDOI, the ID_KEY_ID ID Type MUST be supported by a
conforming implementation, and MUST specify a four (4)-octet group conforming implementation and MUST specify a 4-octet group identifier
identifier as its value. Implementations MAY also support other ID as its value. Implementations MAY also support other ID Types.
Types.
5.2. Security Association Payload 5.2. Security Association Payload
The Security Association payload is defined in [RFC2408]. For the The Security Association payload is defined in [RFC2408]. For the
GDOI, it is used by the GCKS to assert security attributes for both GDOI, it is used by the GCKS to assert security attributes for both
Re-key and Data-security SAs. Rekey and Data-Security SAs.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI ! ! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation ! ! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 ! ! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 4. Security Association Payload Figure 4. Security Association Payload
The Security Association Payload fields are defined as follows: The Security Association payload fields are defined as follows:
o Next Payload (1 octet) -- Identifies the next payload for the o Next Payload (1 octet) -- Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The
next payload MUST NOT be a SA Attribute Payload; it MUST be the next next payload MUST NOT be an SA Attribute payload; it MUST be the
payload following the Security Association type payload. next payload following the Security Association type payload.
o RESERVED (1 octet) -- MUST be zero. o RESERVED (1 octet) -- MUST be zero.
o Payload Length (2 octets) -- Is the octet length of the current o Payload Length (2 octets) -- Is the octet length of the current
payload including the generic header and all TEK and KEK payloads. payload including the generic header and all TEK and KEK payloads.
o DOI (4 octets) -- Is the GDOI, which is value 2. o DOI (4 octets) -- Is the GDOI, which is value 2.
o Situation (4 octets) -- MUST be zero. o Situation (4 octets) -- MUST be zero.
o SA Attribute Next Payload (2 octets) -- MUST be the code for an SA o SA Attribute Next Payload (2 octets) -- MUST be the code for an SA
Attribute Payload type. See Section 5.2.1 for a description of which Attribute payload type. See Section 5.2.1 for a description of
circumstances are required for each payload type to be present. which 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. SA Attribute Payloads 5.2.1. SA Attribute Payloads
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 Payload, zero or one GAP Payload, and zero or more be zero or one SAK payload, zero or one GAP payload, and zero or more
SAT Payloads, where either one SAK or SAT payload MUST be present. SAT payloads, where either one SAK or SAT payload MUST be present.
When present, the order of the SA Attributes payloads MUST be: SAK, When present, the order of the SA Attribute payloads MUST be: SAK,
GAP, and SATs. GAP, and SATs.
This latitude regarding SA Attributes payloads allows various group This latitude regarding SA Attribute payloads allows various group
policies to be accommodated. For example if the group policy does policies to be accommodated. For example, if the group policy does
not require the use of a Re-key SA, the GCKS would not need to send not require the use of a Rekey SA, the GCKS would not need to send an
an SA KEK attribute to the group member since all SA updates would be SA KEK attribute to the group member since all SA updates would be
performed using the Registration SA. Alternatively, group policy performed using the Registration SA. Alternatively, group policy
might use a Re-key SA but choose to download a KEK to the group might use a Rekey SA but choose to download a KEK to the group member
member only as part of the Registration SA. Therefore, the KEK only as part of the Registration SA. Therefore, the KEK policy (in
policy (in the SA KEK attribute) would not be necessary as part of the SA KEK attribute) would not be necessary as part of the Rekey SA
the Re-key SA message SA payload. 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 groupwide policy, such A GAP payload allows for the distribution of group-wide policy, such
as instructions as to when to activate and de-activate SAs. as instructions as to when to activate and deactivate SAs.
5.3. SA KEK payload 5.3. SA KEK Payload
The SA KEK (SAK) payload contains security attributes for the KEK The SA KEK (SAK) payload contains security attributes for the KEK
method for a group and parameters specific to the GROUPKEY-PULL method for a group and parameters specific to the GROUPKEY-PULL
operation. The source and destination identities describe the operation. The source and destination identities describe the
identities used for the GROUPKEY-PULL datagram. identities used for the GROUPKEY-PULL datagram.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port ! ! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~ !SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len! ! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~ ! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ! ! !
~ SPI ~ ~ SPI ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! RESERVED2 ! ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~ ~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 5. SA KEK Payload Figure 5. SA KEK Payload
The SAK Payload fields are defined as follows: The SAK payload fields are defined as follows:
o Next Payload (1 octet) -- Identifies the next payload for the o Next Payload (1 octet) -- Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next
payload types for this message are a GAP Payload, SAT Payload or zero payload types for this message are a GAP payload, SAT payload, or
to indicate that no SA Attribute payloads follow. zero to indicate that no SA Attribute payloads follow.
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
KEK attributes. KEK attributes.
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., o Protocol (1 octet) -- Value describing an IP protocol ID (e.g.,
UDP/TCP) [PROTOCOL-REG] for the GROUPKEY-PUSH datagram. UDP/TCP) [PROT-REG] for the GROUPKEY-PUSH datagram.
o SRC ID Type (1 octet) -- Value describing the identity information o SRC ID Type (1 octet) -- Value describing the identity information
found in the SRC Identification Data field. Defined values are found in the SRC Identification Data field. Defined values are
specified by the IPsec Identification Type section in the IANA specified by the IPsec Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG]. ISAKMP registry [ISAKMP-REG].
o SRC ID Port (2 octets) -- Value specifying a port associated with o SRC ID Port (2 octets) -- Value specifying a port associated with
the source Id. A value of zero means that the SRC ID Port field MUST the source ID. A value of zero means that the SRC ID Port field
be ignored. MUST be ignored.
o SRC ID Data Len (1 octet) -- Value specifying the length (in o SRC ID Data Len (1 octet) -- Value specifying the length (in
octets) of the SRC Identification Data field. octets) of the SRC Identification Data field.
o SRC Identification Data (variable length) -- Value, as indicated by o SRC Identification Data (variable length) -- Value, as indicated
the SRC ID Type. by the SRC ID Type.
o DST ID Type (1 octet) -- Value describing the identity information o DST ID Type (1 octet) -- Value describing the identity information
found in the DST Identification Data field. Defined values are found in the DST Identification Data field. Defined values are
specified by the IPsec Identification Type section in the IANA specified by the IPsec Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG]. ISAKMP registry [ISAKMP-REG].
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g.,
UDP/TCP) [PROTOCOL-REG]. UDP/TCP) [PROT-REG].
o DST ID Port (2 octets) -- Value specifying a port associated with o DST ID Port (2 octets) -- Value specifying a port associated with
the source Id. the source ID.
o DST ID Data Len (1 octet) -- Value specifying the length (in o DST ID Data Len (1 octet) -- Value specifying the length (in
octets) of the DST Identification Data field. octets) of the DST Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated
the DST ID Type. by 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
is the ISAKMP Header cookie pair where the first 8 octets become the is the ISAKMP Header cookie pair where the first 8 octets become
"Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP
the second 8 octets become the "Responder Cookie" in the same HDR. HDR, and the second 8 octets become the "Responder Cookie" in the
As described above, these cookies are assigned by the GCKS. same HDR. As described above, these cookies are assigned by the
GCKS.
o RESERVED2 (4 octets) -- MUST be zero. These octets represent o RESERVED2 (4 octets) -- MUST be zero. These octets represent
fields previously defined but no longer used by GDOI. 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 attributes may be present in a SAK Payload. the group. The following attributes may be present in a SAK
The attributes must follow the format defined in ISAKMP (Section 3.3 payload. The attributes must follow the format defined in ISAKMP
of [RFC2408]). In the table, attributes that are defined as TV are (Section 3.3 of [RFC2408]). In the table, attributes that are
marked as Basic (B); attributes that are defined as TLV are marked as defined as TV are marked as Basic (B); attributes that are defined
Variable (V). as TLV are marked as Variable (V).
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
RESERVED 8 B RESERVED 8 B
Standards Action 9-127 Unassigned 9-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others The KEK_ALGORITHM and SIG_ALGORITHM attributes MUST be included;
are OPTIONAL, and included depending on group policy. The others are OPTIONAL and are included depending on group policy. The
KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a
GROUPKEY-PULL message, and MUST be ignored if present. GROUPKEY-PULL message, and MUST be ignored if present.
5.3.1. KEK_MANAGEMENT_ALGORITHM 5.3.1. 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
Standards Action 2-127 Unassigned 2-127
Private Use 128-255 Private Use 128-255
Unassigned 256-65535
5.3.1.1. LKH 5.3.1.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.2. KEK_ALGORITHM 5.3.2. KEK_ALGORITHM
The KEK_ALGORITHM class specifies the encryption algorithm in which The KEK_ALGORITHM class specifies the encryption algorithm in which
the KEK is used to provide confidentiality for the GROUPKEY-PUSH the KEK is used to provide confidentiality for the GROUPKEY-PUSH
message. Defined values are specified in the following table. A 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
Standards Action 4-127 Unassigned 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys If a KEK_MANAGEMENT_ALGORITHM is defined that specifies 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 that are included
as part of the management. as part of the management.
5.3.2.1. KEK_ALG_DES 5.3.2.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
described in [FIPS81]. described in [FIPS81].
5.3.2.2. KEK_ALG_3DES 5.3.2.2. KEK_ALG_3DES
This type specifies 3DES using three independent keys as described in This type specifies 3DES using three independent keys as described in
"Keying Option 1" in [FIPS46-3]. "Keying Option 1" in [FIPS46-3].
5.3.2.3. KEK_ALG_AES 5.3.2.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 defined in operation for AES is CBC as defined in [SP.800-38A].
[SP.800-38A].
5.3.3. KEK_KEY_LENGTH 5.3.3. 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 bits). The Group Controller/Key Server (GCKS) adds the
KEK_KEY_LENGTH attribute to the SA payload when distributing KEK KEK_KEY_LENGTH attribute to the SA payload when distributing KEK
policy to group members. The group member verifies whether or not it policy to group members. The group member verifies whether or not it
has the 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_LENGTH attribute. Sending attribute and does not need the KEK_KEY_LENGTH attribute. Sending
the KEK_KEY_LENGTH attribute in the SA payload is OPTIONAL if the KEK the KEK_KEY_LENGTH attribute in the SA payload is OPTIONAL if the KEK
cipher has a fixed key length. Also, note that the KEK_KEY_LEN cipher has a fixed key length. Also, note that the KEK_KEY_LEN
includes only the actual length of the cipher key (the IV length is includes only the actual length of the cipher key (the IV length is
not included in this attribute). not included in this attribute).
5.3.4. KEK_KEY_LIFETIME 5.3.4. 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 4-octet number defining a
defining a valid time period in seconds. valid time period in seconds.
5.3.5. SIG_HASH_ALGORITHM 5.3.5. 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 3
SIG_HASH_SHA384 TBD-3 SIG_HASH_SHA384 4
SIG_HASH_SHA512 TBD-4 SIG_HASH_SHA512 5
Standards Action 3-127 Unassigned 6-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-65535
The SHA hash algorithms are defined in the Secure Hash
Standard[FIPS180-3.2008]. The SHA hash algorithms are defined in the Secure Hash Standard
[FIPS180-3.2008].
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 OPTIONAL in a SAK Payload. and SIG_HASH_ALGORITHM is OPTIONAL in a SAK payload.
5.3.6. SIG_ALGORITHM 5.3.6. 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_ECDSA-256 TBD-7 SIG_ALG_ECDSA-256 4
SIG_ALG_ECDSA-384 TBD-8 SIG_ALG_ECDSA-384 5
SIG_ALG_ECDSA-521 TBD-9 SIG_ALG_ECDSA-521 6
Standards Action 4-127 Unassigned 7-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-65535
5.3.6.1. SIG_ALG_RSA 5.3.6.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.6.2. SIG_ALG_DSS 5.3.6.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].
5.3.6.3. SIG_ALG_ECDSS 5.3.6.3. SIG_ALG_ECDSS
This algorithm specifies the Elliptic Curve digital signature This algorithm specifies the Elliptic Curve Digital Signature
algorithm as described in Section 5 of [FIPS186-3]. This definition Algorithm as described in Section 5 of [FIPS186-3]. This definition
is deprecated in favor of the SIG_ALG_ECDSA family of algorithms. is deprecated in favor of the SIG_ALG_ECDSA family of algorithms.
5.3.6.4. SIG_ALG_ECDSA-256 5.3.6.4. SIG_ALG_ECDSA-256
This algorithm specifies the 256-bit Random ECP Group, as described This algorithm specifies the 256-bit Random ECP Group, as described
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.6.5. SIG_ALG_ECDSA-384 5.3.6.5. SIG_ALG_ECDSA-384
skipping to change at page 31, line 20 skipping to change at page 28, line 5
5.4. Group Associated Policy 5.4. Group Associated Policy
A GCKS may have group-specific policy that is not distributed in an A GCKS may have group-specific policy that is not distributed in an
SA TEK or SA KEK. Some of this policy is relevant to all group SA TEK or SA KEK. Some of this policy is relevant to all group
members, and some is sender-specific policy for a particular group members, and some is sender-specific policy for a particular group
member. The former can be distributed in either a GROUPKEY-PULL or member. The former can be distributed in either a GROUPKEY-PULL or
GROUPKEY-PUSH exchange, whereas the latter MUST only be sent in a GROUPKEY-PUSH exchange, whereas the latter MUST only be sent in a
GROUPKEY-PULL exchange. Additionally, a group member sometimes has GROUPKEY-PULL exchange. Additionally, a group member sometimes has
the need to make policy requests for resources of the GCKS in a the need to make policy requests for resources of the GCKS in a
GROUPKEY-PULL exchange. GDOI distributes this associated group GROUPKEY-PULL exchange. GDOI distributes this associated group
policy and policy requests in the Group Associated Policy (GAP) policy and the policy requests in the Group Associated Policy (GAP)
payload. payload.
The GAP payload can be distributed by the GCKS as part of the SA The GAP payload can be distributed by the GCKS as part of the SA
payload. It follows any SA KEK payload, and is placed before any SA payload. It follows any SA KEK payload and is placed before any SA
TEK payloads. In the case that group policy does not include an SA TEK payloads. In the case that group policy does not include an SA
KEK, the SA Attribute Next Payload field in the SA payload MAY KEK, the SA Attribute Next Payload field in the SA payload MAY
indicate the GAP payload. indicate the GAP payload.
The GAP payload can be optionally included by a group member in The GAP payload can be optionally included by a group member in
message 3 of the GROUPKEY-PULL exchange in order to make policy message 3 of the GROUPKEY-PULL exchange in order to make policy
requests. requests.
The GAP payload is defined as follows: The GAP payload is defined as follows:
skipping to change at page 32, line 22 skipping to change at page 29, line 11
[RFC2408]. In the table, attributes that are defined as TV are [RFC2408]. In the table, attributes that are defined as TV are
marked as Basic (B); attributes that are defined as TLV are marked marked as Basic (B); attributes that are defined as TLV are marked
as Variable (V). as Variable (V).
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_REQUEST 3 B SENDER_ID_REQUEST 3 B
Standards Action 4-127 Unassigned 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
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 an attribute or A GDOI implementation MUST abort if it encounters an attribute or
capability that it does not understand. The values for these capability that it does not understand. The values for these
attributes are included in the IANA Considerations section of this attributes are included in the IANA Considerations section of this
memo. memo.
5.4.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY 5.4.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY
Section 4.2.1 of [RFC5374] specifies a key rollover method that Section 4.2.1 of [RFC5374] specifies a key rollover method that
requires two values be given it from the group key management requires two values be given it from the group key management
protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set
the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD
defines how long after receiving new SAs that they are to be defines how long after receiving new SAs that they are to be
activated by the GM. The ATD value is in seconds. activated by the GM. The ATD value is in seconds.
The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation
Time Delay (DTD) for previously distributed SAs. The DTD defines how Time Delay (DTD) for previously distributed SAs. The DTD defines how
long after receiving new SAs that it SHOULD deactivate SAs that are long after receiving new SAs that it SHOULD deactivate SAs that are
destroyed by the re-key event. The value is in seconds. destroyed by the rekey event. The value is in seconds.
The values of ATD and DTD are independent. However, the most The values of ATD and DTD are independent. However, the most
effective policy will have the DTD value to be the larger value as effective policy will have the DTD value be the larger value, as this
this allows new SAs to be activated before older SAs are deactivated. allows new SAs to be activated before older SAs are deactivated.
Such a policy ensures that protected group traffic will always flow Such a policy ensures that protected group traffic will always flow
without interruption. without interruption.
5.4.2. SENDER_ID_REQUEST 5.4.2. SENDER_ID_REQUEST
The SENDER_ID_REQUEST attribute is used by a group member to request The SENDER_ID_REQUEST attribute is used by a group member to request
SIDs during the GROUPKEY-PULL message, and includes a count of how SIDs during the GROUPKEY-PULL message, and includes a count of how
many SID values it desires. 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~ ! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 7. SA TEK Payload Figure 7. SA TEK Payload
The SAT Payload fields are defined as follows: The SAT payload fields are defined as follows:
o Next Payload (1 octet) -- Identifies the next payload for the o Next Payload (1 octet) -- Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next
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.
The following table defines values for the Security Protocol.
o Protocol-ID (1 octet) -- Value specifying 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 2
Standards Action 3-127 Unassigned 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
the attributes specific for the Protocol-ID. describes 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port ! ! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~ !SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len! ! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~ ! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI ! ! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~ ! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 8. ESP/AH TEK Payload Figure 8. ESP/AH TEK Payload
The SAT Payload fields are defined as follows: The SAT payload fields are defined as follows:
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., o Protocol (1 octet) -- Value describing an IP protocol ID (e.g.,
UDP/TCP) [PROTOCOL-REG]. A value of zero means that the Protocol UDP/TCP) [PROT-REG]. A value of zero means that the Protocol
field MUST be ignored. field MUST be ignored.
o SRC ID Type (1 octet) -- Value describing the identity information o SRC ID Type (1 octet) -- Value describing the identity information
found in the SRC Identification Data field. Defined values are found in the SRC Identification Data field. Defined values are
specified by the IPsec Identification Type section in the IANA specified by the IPsec Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG]. ISAKMP registry [ISAKMP-REG].
o SRC ID Port (2 octets) -- Value specifying a port associated with o SRC ID Port (2 octets) -- Value specifying a port associated with
the source Id. A value of zero means that the SRC ID Port field MUST the source ID. A value of zero means that the SRC ID Port field
be ignored. MUST be ignored.
o SRC ID Data Len (1 octet) -- Value specifying the length (in o SRC ID Data Len (1 octet) -- Value specifying the length (in
octets) of the SRC Identification Data field. octets) of the SRC Identification Data field.
o SRC Identification Data (variable length) -- Value, as indicated by o SRC Identification Data (variable length) -- Value, as indicated
the SRC ID Type. Set to three octets of zero for multiple-source by the SRC ID Type. Set to 3 octets or zero for multiple-source
multicast groups that use a common TEK for all senders. multicast groups that use a common TEK for all senders.
o DST ID Type (1 octet) -- Value describing the identity information o DST ID Type (1 octet) -- Value describing the identity information
found in the DST Identification Data field. Defined values are found in the DST Identification Data field. Defined values are
specified by the IPsec Identification Type section in the IANA specified by the IPsec Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG]. ISAKMP registry [ISAKMP-REG].
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g.,
UDP/TCP) [PROTOCOL-REG]. A value of zero means that the DST Id Prot UDP/TCP) [PROT-REG]. A value of zero means that the DST ID Prot
field MUST be ignored. field MUST be ignored.
o DST ID Port (2 octets) -- Value specifying a port associated with o DST ID Port (2 octets) -- Value specifying a port associated with
the source Id. A value of zero means that the DST ID Port field MUST the source ID. A value of zero means that the DST ID Port field
be ignored. MUST be ignored.
o DST ID Data Len (1 octet) -- Value specifying the length (in o DST ID Data Len (1 octet) -- Value specifying the length (in
octets) of the DST Identification Data field. octets) of the DST Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated
the DST ID Type. by the DST ID Type.
o Transform ID (1 octet) -- Value specifying which ESP or AH o Transform ID (1 octet) -- Value specifying which ESP or AH
transform is to be used. The list of valid values is defined in the transform is to be used. The list of valid values is defined in
IPsec ESP or IPsec AH Transform Identifiers section of the IANA the IPsec ESP or IPsec AH Transform Identifiers section of the
isakmpd-registry [ISAKMP-REG]. IANA ISAKMP registry [ISAKMP-REG].
o SPI (4 octets) -- Security Parameter Index for ESP. o SPI (4 octets) -- Security Parameter Index for ESP.
o RFC 2407 Attributes -- ESP and AH Attributes from Section 4.5 of o RFC 2407 Attributes -- ESP and AH Attributes from Section 4.5 of
[RFC2407]. The GDOI supports all IPsec DOI SA Attributes for [RFC2407]. The GDOI supports all IPsec DOI SA Attributes for
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
GDOI implementation and is ignored by a GDOI implementation if a 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
Encapsulation Mode. An implementation supporting ESP MUST also Duration, and Encapsulation Mode. An implementation supporting
support the Authentication Algorithm attribute if the ESP transform ESP MUST also support the Authentication Algorithm attribute if
includes authentication. The Authentication Algorithm attribute of the ESP transform includes authentication. The Authentication
the IPsec DOI is group authentication in GDOI. Algorithm attribute of the IPsec DOI is group authentication in
GDOI.
5.5.1.1. New IPsec Security Association Attributes 5.5.1.1. New IPsec Security Association Attributes
The Multicast Extensions to the Security Architecture for the "Multicast Extensions to the Security Architecture for the Internet
Internet Protocol (RFC 5374) introduces new requirements for a group Protocol" (RFC 5374) introduces new requirements for a group key
key management system distributing IPsec policy. It also defines new management system distributing IPsec policy. It also defines new
attributes as part of the Group Security Policy Database (GSPD). attributes as part of the Group Security Policy Database (GSPD).
These attributes describe policy that a group key management system These attributes describe policy that a group key management system
must convey to a group member in order to support those extensions. must convey to a group member in order to support those extensions.
The GDOI SA TEK payload distributes IPsec policy using IPsec security The GDOI SA TEK payload distributes IPsec policy using IPsec security
association attributes defined in [ISAKMP-REG]. This section defines association attributes defined in [ISAKMP-REG]. This section defines
how GDOI can convey the new attributes as IPsec Security Association how GDOI can convey the new attributes as IPsec Security Association
Attributes. Attributes.
5.5.1.1.1. Address Preservation 5.5.1.1.1. Address Preservation
skipping to change at page 36, line 34 skipping to change at page 33, line 21
the necessary policy so that the GDOI group member can appropriately the necessary policy so that the GDOI group member can appropriately
set up the GSPD. The following table defines values for the Address set up the GSPD. The following table defines values for the Address
Preservation attribute. Preservation attribute.
Address Preservation Type Value Address Preservation Type Value
------------------------- ----- ------------------------- -----
Reserved 0 Reserved 0
None 1 None 1
Source-Only 2 Source-Only 2
Destination-Only 3 Destination-Only 3
Source-And-Destination 4 Source-and-Destination 4
Standards Action 5-61439 Unassigned 5-61439
Private Use 61440-65535 Private Use 61440-65535
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"). If this attribute is not included in a GDOI SA and-Destination"). If this attribute is not included in a GDOI SA
TEK payload provided by a GCKS, then Source-And-Destination address TEK payload provided by a GCKS, then Source-and-Destination address
preservation has been defined for the SA TEK. preservation has been defined for the SA TEK.
5.5.1.1.2. 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
is defined to be in the sending and/or receiving direction. The is defined to be in the sending and/or receiving direction. The
following table defines values for the SA Direction attribute. following table defines values for the SA Direction attribute.
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 Unassigned 4-61439
Private Use 61440-65535 Private Use 61440-65535
SA TEK policy used by multiple senders MUST be installed in both the SA TEK policy used by multiple senders MUST be installed in both the
sending and receiving direction ("Symmetric"), whereas SA TEK for a sending and receiving direction ("Symmetric"), whereas SA TEK for a
single sender SHOULD be installed in the receiving direction by single sender SHOULD be installed in the receiving direction by
receivers ("Receiver-Only") and in the sending direction by the receivers ("Receiver-Only") and in the sending direction by the
sender ("Sender-Only"). sender ("Sender-Only").
An SA TEK payload that does not include the SA Direction attribute is An SA TEK payload that does not include the SA Direction attribute is
treated as a Symmetric IPsec SA. Note that Symmetric is the only treated as a Symmetric IPsec SA. Note that Symmetric is the only
value that can be meaningfully described for an SA TEK distributed in value that can be meaningfully described for an SA TEK distributed in
an GROUPKEY-PUSH message. Alternatively, Receiver-Only could be a GROUPKEY-PUSH message. Alternatively, Receiver-Only could be
distributed, but group senders would need to be configured to not distributed, but group senders would need to be configured to not
receive GROUPKEY-PUSH messages in order to retain their role. 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
Protocol to the GDOI. Protocol to the GDOI.
o The Protocol-ID for the particular Security Protocol o The Protocol-ID for the particular Security Protocol
o The SPI Size o The SPI Size
o The method of SPI generation o The method of SPI generation
o The transforms, attributes and keys needed by the Security o The transforms, attributes, and keys needed by the Security
Protocol Protocol
All Security Protocols MUST provide the information in the bulleted All Security Protocols MUST provide the information in the bulleted
list above to guide the GDOI specification for that protocol. list above to guide the GDOI specification for that protocol.
Definitions for the support of those Security Protocols in GDOI will Definitions for the support of those Security Protocols in GDOI will
be specified in separate documents. be specified in separate documents.
A Security Protocol MAY protect traffic at any level of the network A Security Protocol MAY protect traffic at any level of the network
stack. However, in all cases applications of the Security Protocol stack. However, in all cases, applications of the Security Protocol
MUST protect traffic which MAY be shared by more than two entities. MUST protect traffic that MAY be shared by more than two entities.
5.6. Key Download Payload 5.6. Key Download Payload
The Key Download Payload contains group keys for the group specified The Key Download payload contains group keys for the group specified
in the SA Payload. These key download payloads can have several in the SA payload. These Key Download payloads can have several
security attributes applied to them based upon the security policy of security attributes applied to them based upon the security policy of
the group as defined by the associated SA Payload. the group as defined by the associated SA payload.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 ! ! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~ ~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 9. Key Download Payload Figure 9. Key Download Payload
The Key Download Payload fields are defined as follows: The Key Download 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
the message, then this field will be zero. in 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
key packets being passed in this data block. key packets being passed in this data block.
o Key Packets (variable) -- Several types of key packets are defined. o Key Packets (variable) -- Several types of key packets are
Each Key Packet has the following format. defined. 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 10. Key Packet Figure 10. Key Packet
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
SID TBD-6 SID 4
Standards Action 4-127 Unassigned 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
SPI as defined by the Protocol-Id. SPI as defined by the Protocol-ID.
o SPI (variable length) -- Security Parameter Index which matches a o SPI (variable length) -- Security Parameter Index, which matches a
SPI previously sent in an SAK or SAT Payload. SPI previously sent in a SAK or SAT payload.
o Key Packet Attributes (variable length) -- Contains Key o Key Packet Attributes (variable length) -- Contains key
information. The format of this field is specific to the value of information. The format of this field is specific to the value of
the KD Type field. The following sections describe the format of the KD Type field. The following sections describe the format of
each KD Type. each KD Type.
5.6.1. TEK Download Type 5.6.1. TEK Download Type
The following attributes may be present in a TEK Download Type. The following attributes may be present in a TEK Download Type.
Exactly one attribute matching each type sent in the SAT payload MUST Exactly one attribute matching each type sent in the SAT payload MUST
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).
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 Unassigned 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 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 Rekey SA. At
At least one TEK must be included in each Re-key KD payload. least one TEK must be included in each Rekey KD payload. Multiple
Multiple TEKs may be included if multiple streams associated with the TEKs may be included if multiple streams associated with the SA are
SA are to be rekeyed. 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
contain information besides a key. For example, The Use of Galois/ contain information besides a key. For example, "The Use of Galois/
Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)"
[RFC4106] defines a salt value as part of KEYMAT. [RFC4106] defines a salt value as part of KEYMAT.
5.6.1.1. TEK_ALGORITHM_KEY 5.6.1.1. TEK_ALGORITHM_KEY
The TEK_ALGORITHM_KEY class declares that the encryption key for this The TEK_ALGORITHM_KEY class declares that the encryption key for this
SPI is contained as the Key Packet Attribute. The encryption SPI is contained as the Key Packet Attribute. The encryption
algorithm that will use this key was specified in the SAT payload. algorithm that will use this key was specified in the SAT payload.
In the case that the algorithm requires multiple keys (e.g., 3DES), In the case that the algorithm requires multiple keys (e.g., 3DES),
all keys will be included in one attribute. all keys will be included in one attribute.
DES keys will consist of 64 bits (the 56 key bits with parity bit). DES keys will consist of 64 bits (the 56 key bits with parity bits).
Triple DES keys will be specified as a single 192 bit attribute Triple DES keys will be specified as a single 192-bit attribute
(including parity bits) in the order that the keys are to be used for (including parity bits) in the order that the keys are to be used for
encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3).
5.6.1.2. TEK_INTEGRITY_KEY 5.6.1.2. TEK_INTEGRITY_KEY
The TEK_INTEGRITY_KEY class declares that the integrity key for this The TEK_INTEGRITY_KEY class declares that the integrity key for this
SPI is contained as the Key Packet Attribute. The integrity SPI is contained as the Key Packet Attribute. The integrity
algorithm that will use this key was specified in the SAT payload. algorithm that will use this key was specified in the SAT payload.
Thus, GDOI assumes that both the symmetric encryption and integrity Thus, GDOI assumes that both the symmetric encryption and integrity
keys are pushed to the GM. HMAC-SHA1 keys will consist of 160 bits keys are pushed to the GM. HMAC-SHA1 keys will consist of 160 bits
[RFC2404], HMAC-MD5 keys will consist of 128 bits [RFC2403]. HMAC- [RFC2404], and HMAC-MD5 keys will consist of 128 bits [RFC2403].
SHA2 and AES-GMAC keys will have a key length equal to the output HMAC-SHA2 and AES-GMAC keys will have a key length equal to the
length of the hash functions [RFC4868][RFC4543]. output length of the hash functions [RFC4868] [RFC4543].
5.6.1.3. TEK_SOURCE_AUTH_KEY 5.6.1.3. TEK_SOURCE_AUTH_KEY
The TEK_SOURCE_AUTH_KEY class declares that the source authentication The TEK_SOURCE_AUTH_KEY class declares that the source authentication
key for this SPI is contained in the Key Packet Attribute. The key for this SPI is contained in the Key Packet Attribute. The
source authentication algorithm that will use this key was specified source authentication algorithm that will use this key was specified
in the SAT payload. in the SAT payload.
5.6.2. KEK Download Type 5.6.2. KEK Download Type
skipping to change at page 41, line 32 skipping to change at page 38, line 19
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 Unassigned 3-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 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
skipping to change at page 42, line 29 skipping to change at page 39, 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).
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
Standards Action 4-127 Unassigned 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 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
skipping to change at page 43, line 18 skipping to change at page 39, line 42
! LKH Version ! # of LKH Keys ! RESERVED ! ! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys ! ! LKH Keys !
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11. LKH Download Array Figure 11. LKH Download Array
The KEK_LKH attribute fields are defined as follows: The KEK_LKH attribute fields are defined as follows:
o LKH version (1 octet) -- Version of the LKH data format. Must be o LKH version (1 octet) -- Version of the LKH data format. Must be
one. one.
o Number of LKH Keys (2 octets) -- This value is the number of o Number of LKH Keys (2 octets) -- This value is the number of
distinct LKH keys in this sequence. distinct LKH keys in this sequence.
o RESERVED (1 octet) -- Unused, set to zero. Each LKH Key is defined o RESERVED (1 octet) -- Unused; set to zero. Each LKH Key is
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! RESERVED ! ! LKH ID ! Key Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Date ! ! Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key expiration Date ! ! Key Expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle ! ! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Key Data ~ ~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. LKH Key Figure 12. LKH Key
o LKH ID (2 octets) -- Identity of the LKH node. A GCKS is free to o LKH ID (2 octets) -- Identity of the LKH node. A GCKS is free to
choose the ID in an implementation-specific manner (e.g., the choose the ID in an implementation-specific manner (e.g., the
position of this key in a binary tree structure used by LKH). position of this key in a binary tree structure used by LKH).
o Key Type (1 octet) -- Encryption algorithm for which this key data o Key Type (1 octet) -- Encryption algorithm for which this key data
is to be used. This value is specified in Section 5.3.3. is to be used. This value is specified in Section 5.3.3.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused; set to zero.
o Key Creation Date (4 octets) -- Unsigned time value defining a o Key Creation Date (4 octets) -- Unsigned time value defining a
valid time period in seconds representing the number of seconds since valid time period in seconds representing the number of seconds
0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated
Time (UTC), without including leap seconds. [RFC5905]. This is the Universal Time (UTC), without including leap seconds. [RFC5905].
time when this key data was originally generated. A time value of This is the time when this key data was originally generated. A
zero indicates that there is no time before which this key is not time value of zero indicates that there is no time before which
valid. this key is not valid.
o Key Expiration Date (4 octets) -- Unsigned time value defining a o Key Expiration Date (4 octets) -- Unsigned time value defining a
valid time period in seconds representing the number of seconds since valid time period in seconds representing the number of seconds
0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated
Time (UTC), without including leap seconds. [RFC5905]. This is the Universal Time (UTC), without including leap seconds. [RFC5905].
time when this key is no longer valid for use. A time value of zero This is the time when this key is no longer valid for use. A time
indicates that this key does not have an expiration time. value of zero indicates that this key 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
algorithm requires an IV, an explicit IV MUST be included in the Key the algorithm requires an IV, an explicit IV MUST be included in
Data field prepended to the actual key. the 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.
5.6.3.2. LKH_UPDATE_ARRAY 5.6.3.2. LKH_UPDATE_ARRAY
skipping to change at page 45, line 20 skipping to change at page 41, line 44
! LKH ID ! RESERVED2 ! ! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle ! ! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys ! ! LKH Keys !
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. LKH Update Array Figure 13. LKH Update Array
o LKH version (1 octet) -- Version of the LKH data format. Must be o LKH version (1 octet) -- Version of the LKH data format. Must be
one. one.
o Number of LKH Keys (2 octets) -- Number of distinct LKH keys in o Number of LKH Keys (2 octets) -- Number of distinct LKH keys in
this sequence. this sequence.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused; set to zero.
o LKH ID (2 octets) -- Node identifier associated with the key used o LKH ID (2 octets) -- Node identifier associated with the key used
to encrypt the first LKH Key. to encrypt the first LKH Key.
o RESERVED2 (2 octets) -- Unused, set to zero. o RESERVED2 (2 octets) -- Unused; set to zero.
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 the key within the LKH ID used to encrypt the first LKH Key. identify the key within the LKH ID used to encrypt the first LKH
Key.
The LKH Keys are as defined in the previous section. The LKH Key The LKH Keys are as defined in the previous section. The LKH Key
structures contain keys along the path of the key tree in order from structures contain keys along the path of the key tree in order from
the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the
group KEK. The Key Data field of each LKH Key is encrypted with the group KEK. The Key Data field of each LKH Key is encrypted with the
LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first
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
skipping to change at page 46, line 10 skipping to change at page 42, line 34
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 5.6.4. SID Download Type
This attribute is used to download one or more Sender-ID (SID) values This attribute is used to download one or more Sender-ID (SID) values
for the exclusive use of a group member. for the exclusive use of a group member.
The SID Download Type does not require a SPI. When the KD Type is The SID Download Type does not require an SPI. When the KD Type is
SID, the SPI Size field MUST be zero, and the SPI field is omitted. SID, the SPI Size field MUST be zero, and the SPI field is omitted.
SID Class Value Type SID Class Value Type
--------- ----- ---- --------- ----- ----
RESERVED 0 RESERVED 0
NUMBER_OF_SID_BITS 1 B NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V SID_VALUE 2 V
Standards Action 3-128 Unassigned 3-128
Private Use 129-255 Private Use 129-255
Unassigned 256-32767 Unassigned 256-32767
Because a SID value is intended for a single group member, the SID Because a SID value is intended for a single group member, the SID
Download type MUST NOT be distributed in a GROUPKEY-PUSH message Download type MUST NOT be distributed in a GROUPKEY-PUSH message
distributed to multiple group members. distributed to multiple group members.
5.6.4.1. NUMBER_OF_SID_BITS 5.6.4.1. NUMBER_OF_SID_BITS
The NUMBER_OF_SID_BITS class declares how many bits of the cipher 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 nonce in which to represent a SID value. This value is applied to
each SID value distributed in the SID Download. each SID value distributed in the SID Download.
5.6.4.2. SID_VALUE 5.6.4.2. SID_VALUE
The SID_VALUE class declares a single SID value for the exclusive use 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 of the group member. Multiple SID_VALUE attributes MAY be included
in a SID Download. in a SID Download.
5.6.4.3. Group Member Semantics 5.6.4.3. Group Member Semantics
The SID_VALUE attribute value distributed to the group member MUST be 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 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 Data-Security SAs including a counter-based mode of operation
distributed by the GCKS as a part of this group. distributed by the GCKS as a part of this group.
When the Sender-Specific IV (SSIV) field for any Data-Security SA is 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 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 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 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 either the same Data-Security SAs or replacement ones. The new SID
replaces the existing SID used by this group member, and also resets 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 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 prior to the actual exhaustion of the SSIV field to avoid dropping
data packets due to the exhaustion of available SSIV values combined data packets due to the exhaustion of available SSIV values combined
with a particular SID value. with a particular SID value.
GROUPKEY-PUSH message may include Data-Security SAs that are GROUPKEY-PUSH message may include Data-Security SAs that are
distributed to the group member for the first time. An SID distributed to the group member for the first time. A SID previously
previously issued to the receiving group member is used with counter- issued to the receiving group member is used with counter-based mode
based mode of operation Data-Security SAs on which the group member of operation Data-Security SAs on which the group member acts as a
acts as a sender. Because this Data-Security SA has not previously sender. Because this Data-Security SA has not previously been used
been used for transmission, the SSIV field should be set to its for transmission, the SSIV field should be set to its starting value.
starting value.
5.6.4.4. GCKS Semantics 5.6.4.4. GCKS Semantics
If any KD payload includes keying material that is associated with a If any KD payload includes keying material that is associated with a
counter-mode of operation, an SID Download Type KD payload containing counter-mode of operation, a SID Download Type KD payload containing
at least one SID_VALUE attribute MUST be included. at least one SID_VALUE attribute MUST be included.
The GCKS MUST NOT send the SID Download Type KD payload as part of a The GCKS MUST NOT send the SID Download Type KD payload as part of a
GROUPKEY-PUSH message, because distributing the same sender-specific GROUPKEY-PUSH message because distributing the same sender-specific
policy to more than one group member will reduce the security of the policy to more than one group member will reduce the security of the
group. group.
5.7. Sequence Number Payload 5.7. Sequence Number Payload
The Sequence Number Payload (SEQ) provides an anti-replay protection The Sequence Number (SEQ) Payload 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number ! ! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. Sequence Number Payload Figure 14. Sequence Number Payload
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
the message, then this field will be zero. in 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. MUST be a value of 8. 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
the GCKS, and incremented in each subsequently-transmitted message. by the GCKS and incremented in each subsequently transmitted
Thus the first packet sent for a given Rekey SA will have a Sequence message. Thus, the first packet sent for a given Rekey SA will
Number of 1. The GDOI implementation keeps a sequence counter as an have a Sequence Number of 1. The GDOI implementation keeps a
attribute for the Rekey SA and increments the counter upon receipt of sequence counter as an attribute for the Rekey SA and increments
a GROUPKEY-PUSH message. The current value of the sequence number the counter upon receipt of a GROUPKEY-PUSH message. The current
MUST be transmitted to group members as a part of the Registration SA value of the sequence number MUST be transmitted to group members
payload. as a part of the Registration SA payload.
5.8. Nonce 5.8. Nonce
The data portion of the Nonce payload (i.e., Ni_b and Nr_b included The data portion of the Nonce payload (i.e., Ni_b and Nr_b included
in the HASHs) MUST be a value between 8 and 128 octets. in the HASHs) MUST be a value between 8 and 128 octets.
5.9. Delete 5.9. Delete
There are times the GCKS may want to signal to receivers to delete There are times the GCKS may want to signal to receivers to delete
SAs, for example at the end of a broadcast. Deletion of keys may be SAs, for example, at the end of a broadcast. Deletion of keys may be
accomplished by sending an ISAKMP Delete payload (Section 3.15 of accomplished by sending an ISAKMP Delete payload (Section 3.15 of
[RFC2408]) as part of a GDOI GROUPKEY-PUSH message. [RFC2408]) as part of a GDOI GROUPKEY-PUSH message.
One or more Delete payloads MAY be placed following the SEQ payload One or more Delete payloads MAY be placed following the SEQ payload
in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to
group members, the SA and KD payloads MUST be omitted from the group members, the SA and KD payloads MUST be omitted from the
message. message.
The following fields of the Delete Payload are further defined as The following fields of the Delete payload are further defined as
follows: follows:
o The Domain of Interpretation field contains the GDOI DOI. o The Domain of Interpretation field contains the GDOI DOI.
o The Protocol-Id field contains TEK protocol id values defined in o The Protocol-ID field contains TEK protocol ID values defined in
Section 5.5 of this document. To delete a KEK SA, the value of zero Section 5.5 of this document. To delete a KEK SA, the value of
MUST be used as the protocol id. Note that only one protocol id zero MUST be used as the protocol ID. Note that only one protocol
value can be defined in a Delete payload. Thus, if a TEK SA and a ID value can be defined in a Delete payload. Thus, if a TEK SA
KEK SA are to be deleted, their SPI values MUST be sent in different and a KEK SA are to be deleted, their SPI values MUST be sent in
Delete payloads. different Delete payloads.
There may be circumstances where the GCKS may want to start over with There may be circumstances where the GCKS may want to start over with
a clean slate. If the administrator is no longer confident in the a clean slate. If the administrator is no longer confident in the
integrity of the group, the GCKS can signal deletion of all policy of integrity of the group, the GCKS can signal deletion of all policy of
a particular TEK protocol by sending a TEK with a SPI value equal to a particular TEK protocol by sending a TEK with an SPI value equal to
zero in the delete payload. For example, if the GCKS wishes to zero in the delete payload. For example, if the GCKS wishes to
remove all the KEKs and all the TEKs in the group, the GCKS SHOULD remove all the KEKs and all the TEKs in the group, the GCKS SHOULD
send a delete payload with a spi of zero and a protocol_id of a TEK send a delete payload with an SPI of zero and a Protocol-ID of a TEK
protocol_id value, followed by another delete payload with a SPI Protocol-ID value, followed by another delete payload with an SPI
value of zero and protocol_id of zero, indicating that the KEK SA value of zero and Protocol-ID of zero, indicating that the KEK SA
should be deleted. should be deleted.
6. Algorithm Selection 6. Algorithm Selection
For GDOI implementations to interoperate, they must support one or For GDOI implementations to interoperate, they must support one or
more security algorithms in common. This section specifies the more security algorithms in common. This section specifies the
security algorithm implementation requirements for standards- security algorithm implementation requirements for standards-
conformant GDOI implementations. In all cases the choices are conformant GDOI implementations. In all cases, the choices are
intended to maintain at least 112 bits of security [SP.800-131]. intended to maintain at least 112 bits of security [SP.800-131].
Algorithms not referenced in this section MAY be used. Algorithms not referenced in this section MAY be used.
6.1. KEK 6.1. KEK
These tables list the algorithm selections for values related to the These tables list the algorithm selections for values related to the
KEK. KEK.
Requirement KEK Management Algorithm Requirement KEK Management Algorithm
----------- --------------------- ----------- ---------------------
skipping to change at page 50, line 40 skipping to change at page 46, line 30
MUST SIG_HASH_SHA256 MUST SIG_HASH_SHA256
SHOULD SIG_HASH_SHA1 (2) SHOULD SIG_HASH_SHA1 (2)
SHOULD NOT SIG_HASH_MD5 (3) SHOULD NOT SIG_HASH_MD5 (3)
Requirement KEK Signature Algorithm (notes) Requirement KEK Signature Algorithm (notes)
----------- ------------------------------- ----------- -------------------------------
MUST SIG_ALG_RSA with 2048-bit keys MUST SIG_ALG_RSA with 2048-bit keys
Notes: Notes:
(1) DES, with its small key size and corresponding security strength (1) DES, with its small key size and corresponding security
is of questionable security for general use strength, is of questionable security for general use
(2) The use of SIG_HASH_SHA1 as a signature hash algorithm used with (2) The use of SIG_HASH_SHA1 as a signature hash algorithm used with
GROUPKEY-PUSH messages remains safe at the time of this writing, GROUPKEY-PUSH messages remains safe at the time of this writing,
and is a widely deployed signature hash algorithm. and it is a widely deployed signature hash algorithm.
(3) Although a real weakness with second preimage resistance with (3) Although a real weakness with second preimage resistance with
MD5 has not been found at the time of this writing, the security MD5 has not been found at the time of this writing, the security
strength of MD5 has been shown to be rapidly declining over time strength of MD5 has been shown to be rapidly declining over
and it's use should be understood and carefully weighed. time, and its use should be understood and carefully weighed.
6.2. TEK 6.2. TEK
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. This protocol performs authentication of senders and receivers. This protocol performs authentication of
communicating protocol participants (Group Member, Group Controller/ communicating protocol participants (Group Member, Group Controller/
Key Server). It provides confidentiality of key management messages, Key Server). It provides confidentiality of key management messages,
and it provides source authentication of those messages. GDOI and it provides source authentication of those messages. GDOI
includes defenses against man-in-middle, connection hijacking, includes defenses against man-in-middle, connection hijacking,
replay, reflection, and denial-of-service (DOS) attacks on unsecured replay, reflection, and denial-of-service (DoS) attacks on unsecured
networks. GDOI assumes the network is not secure and may be under networks. GDOI assumes the network is not secure and may be under
the complete control of an attacker. the complete control of an attacker.
GDOI assumes that the group members and GCKS are secure even though GDOI assumes that the group members and GCKS are secure even though
the network is insecure. GDOI ultimately establishes keys among the network is insecure. GDOI ultimately establishes keys among
members of a group, which MUST be trusted to use those keys in an members of a group, which MUST be trusted to use those keys in an
authorized manner according to group policy. An GDOI entity authorized manner according to group policy. A GDOI entity
compromised by an attacker may reveal the secrets necessary to compromised by an attacker may reveal the secrets necessary to
eavesdrop on group traffic and/or take the identity of a group eavesdrop on group traffic and/or take the identity of a group
sender, so host security measures mitigating unauthorized access is sender, so host security measures mitigating unauthorized access are
of the utmost importance. The latter threat could be mitigated by of the utmost importance. The latter threat could be mitigated by
using source origin authentication in the Data-Security SAs (e.g., using source origin authentication in the Data-Security SAs (e.g.,
the use of RSA signatures [RFC4359] or TESLA [RFC4082]). The choice 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 of Data-Security SAs is a matter of group policy and is not within
the scope of this memo. 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, the GROUPKEY-PULL exchange protected by the ISAKMP Phase 1 protocol, the GROUPKEY-PULL exchange protected by the
ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message. Each phase ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message. Each phase
is considered separately below. is considered separately below.
7.1. ISAKMP Phase 1 7.1. ISAKMP Phase 1
GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the
GROUPKEY-PULL exchange. Therefore all security properties and GROUPKEY-PULL exchange. Therefore, all security properties and
considerations of those exchanges (as noted in [RFC2409]) are considerations of those 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, such as
as identity exposure, absence of unidirectional authentication, or identity exposure, absence of unidirectional authentication, or
stateful cookies [PK01]. stateful cookies [PK01].
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
encryption transforms. encryption transforms.
The Phase 1 protocol will be protecting encryption and integrity keys The Phase 1 protocol will be protecting encryption and integrity keys
sent in the GROUPKEY-PULL protocol. The strength of the encryption sent in the GROUPKEY-PULL protocol. The strength of the encryption
used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY- used for Phase 1 SHOULD exceed that of the keys sent in the GROUPKEY-
PULL protocol. PULL protocol.
7.1.3. Man-in-the-Middle Attack Protection 7.1.3. Man-in-the-Middle Attack Protection
A successful man-in-the-middle or connection-hijacking attack foils A successful man-in-the-middle or connection-hijacking attack foils
entity authentication of one or more of the communicating entities entity authentication of one or more of the communicating entities
during key establishment. GDOI relies on Phase 1 authentication to during key establishment. GDOI relies on Phase 1 authentication to
defeat man-in-the-middle attacks. defeat man-in-the-middle attacks.
7.1.4. Replay/Reflection Attack Protection 7.1.4. Replay/Reflection Attack Protection
In a replay/reflection attack, an attacker captures messages between In a replay/reflection attack, an attacker captures messages between
GDOI entities and subsequently forwards them to a GDOI entity. GDOI entities and subsequently forwards them to a GDOI entity.
Replay and reflection attacks seek to gain information from a Replay and reflection attacks seek to gain information from a
subsequent GDOI message response or seek to disrupt the operation of subsequent GDOI message response or seek to disrupt the operation of
a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce
mechanism in combination with a hash-based message authentication mechanism in combination with a hash-based message authentication
code to protect against the replay or reflection of previous key code to protect against the replay or reflection of previous key
management messages. management messages.
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 DoS attacker sends messages to a GDOI entity to cause that entity
that entity to perform unneeded message authentication operations. to perform unneeded message authentication operations. GDOI uses the
GDOI uses the Phase 1 cookie mechanism to identify spurious messages Phase 1 cookie mechanism to identify spurious messages prior to
prior to cryptographic hash processing. This is a "weak" form of cryptographic hash processing. This is a "weak" form of DoS
denial of service protection in that the GDOI entity must check for protection in that the GDOI entity must check for good cookies, which
good cookies, which can be successfully imitated by a sophisticated can be successfully imitated by a sophisticated attacker. The Phase
attacker. The Phase 1 cookie mechanism is stateful, and commits 1 cookie mechanism is stateful and commits memory resources for
memory resources for cookies. cookies.
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
of the Phase 1 security association. 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.
It is running in the context of the Phase 1 protocol, which has It is running in the context of the Phase 1 protocol, which has
previously authenticated the identity of the peer. previously authenticated the identity of the peer.
Message authentication is provided by HASH payloads in each message, Message authentication is provided by HASH payloads in each message,
where the HASH is defined to be over SKEYID_a (derived in the Phase 1 where the HASH is defined to be over SKEYID_a (derived in the Phase 1
exchange), the ISAKMP Message-ID, and all payloads in the message. exchange), the ISAKMP Message-ID, and all payloads in the message.
skipping to change at page 54, line 43 skipping to change at page 49, line 43
with invalid cookies will be discarded. Therefore, GDOI messages with invalid cookies will be discarded. Therefore, GDOI messages
that are not associated with a current GDOI session will be discarded that are not associated with a current GDOI session will be discarded
without further processing. without further processing.
Replayed GDOI messages that are associated with a current GDOI Replayed GDOI messages that are associated with a current GDOI
session will be decrypted and authenticated. The M-ID in the HDR session will be decrypted and authenticated. The M-ID in the HDR
identifies a session. Replayed packets will be processed according identifies a session. Replayed packets will be processed according
to the state machine of that session. Packets not matching that to the state machine of that session. Packets not matching that
state machine will be discarded without processing. state machine will be discarded without processing.
7.2.5. Denial of Service Protection 7.2.5. Denial-of-Service Protection
GCKS implementations SHOULD keep a record of recently received GCKS implementations SHOULD keep a record of recently received
GROUPKEY-PULL messages (e.g., a hash of the packet) and reject GROUPKEY-PULL messages (e.g., a hash of the packet) and reject
messages that have already been processed. This provides Denial of messages that have already been processed. This provides DoS and
Service and Replay Protection of previously sent messages. An replay protection of previously sent messages. An implementation MAY
implementation MAY choose to rate-limit the receipt of GDOI messages choose to rate-limit the receipt of GDOI messages in order to
in order to mitigate overloading its computational resources. mitigate overloading its computational resources.
The GCKS SHOULD NOT perform any computationally expensive tasks The GCKS SHOULD NOT perform any computationally expensive tasks
before receiving a HASH with its own nonce included. The GCKS MUST before receiving a HASH with its own nonce included. The GCKS MUST
NOT update the group management state (e.g., LKH key tree, SID- NOT update the group management state (e.g., LKH key tree, SID-
counter) until it receives the third message in the exchange with a counter) until it receives the third message in the exchange with a
valid HASH payload including its own nonce. 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 MUST specifically list each authorized group members. A group member 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 message provides an members using an IP multicast group. This message provides an
efficient rekey and group membership adjustment capability. efficient rekey and group membership adjustment capability.
skipping to change at page 55, line 36 skipping to change at page 50, line 38
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. This signed using the corresponding private key held by the GCKS. This
digital signature provides source authentication for the message. digital signature provides source authentication for the message.
Thus, GDOI protects the GCKS from impersonation in group Thus, GDOI protects the GCKS from impersonation in 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 distributed in the GROUPKEY-PULL exchange or a previous that was distributed in the GROUPKEY-PULL exchange or a previous
GROUPKEY-PUSH exchange. The encryption key may be a simple KEK, or GROUPKEY-PUSH exchange. The encryption key may be a simple KEK or
the result of a group management method (e.g., LKH) calculation. 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
skipping to change at page 56, line 10 skipping to change at page 51, line 12
sequence number to protect against replay and reflection attacks. A sequence number to protect against replay and reflection attacks. A
group member will discard sequence numbers associated with the group member will discard sequence numbers associated with the
current KEK SPI that have the same or lower value as the most current KEK SPI that have the same or lower value as the most
recently received replay number. recently received replay number.
Implementations SHOULD keep a record (e.g., a hash value) of recently Implementations SHOULD keep a record (e.g., a hash value) of recently
received GROUPKEY-PUSH messages and reject duplicate messages prior received GROUPKEY-PUSH messages and reject duplicate messages prior
to performing cryptographic operations. This enables an early 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 DoS
service protection for the GROUPKEY-PUSH message. 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
could amplify the effects of a denial of service attack on GDOI could amplify the effects of a DoS attack on GDOI members who process
members who process GROUPKEY-PUSH messages. The added cost of GROUPKEY-PUSH messages. The added cost of digital signatures is
digital signatures is justified by the need to prevent GCKS justified by the need to prevent GCKS impersonation: If a shared
impersonation: If a shared symmetric key were used for GROUPKEY-PUSH symmetric key were used for GROUPKEY-PUSH message authentication,
message authentication, then GCKS source authentication would be then GCKS source authentication would be impossible, and any member
impossible and any member would be capable of GCKS impersonation. would be capable of GCKS impersonation.
The potential of the digital signature amplifying a denial of service The potential of the digital signature amplifying a DoS attack is
attack is mitigated by the order of operations a group member takes, mitigated by the order of operations a group member takes, where the
where the least expensive cryptographic operation is performed first. least expensive cryptographic operation is performed first. The
The group member first decrypts the message using a symmetric cipher. group member first decrypts the message using a symmetric cipher. If
If it is a validly formed message then the sequence number is checked it is a validly formed message, then the sequence number is checked
against the most recently received sequence number. Only when the against the most recently received sequence number. Only when the
sequence number is valid (i.e., it is a larger value than previously sequence number is valid (i.e., it is a larger value than previously
received) is the digital signature verified and the message further received) is the digital signature verified and the message further
processed. Thus in order for a denial of service attack to be processed. Thus, in order for a DoS attack to be mounted, an
mounted, an attacker would need to know both the symmetric encryption attacker would need to know both the symmetric encryption key used
key used for confidentiality, and a valid sequence number. Generally for confidentiality and a valid sequence number. Generally speaking,
speaking this means only current group members can effectively deploy this means only current group members can effectively deploy a DoS
a denial of service attack. attack.
7.4. Forward and Backward Access Control 7.4. Forward and Backward Access Control
Through GROUPKEY-PUSH, the GDOI supports group management methods Through GROUPKEY-PUSH, the GDOI supports group management methods
such as LKH (section 5.4 of [RFC2627]) that have the property of 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 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 (forward access control) and to an old group key by a member added to
the group (backward access control). The concepts "forward access the group (backward access control). The concepts "forward access
control" and "backward access control" have also been described as control" and "backward access control" have also been described as
"perfect forward security" and "perfect backward security" "perfect forward security" and "perfect backward security",
respectively in the literature [RFC2627]. respectively, in the literature [RFC2627].
Group management algorithms providing forward and backward access Group management algorithms providing forward and backward access
control other than LKH have been proposed in the literature, control other than LKH have been proposed in the literature,
including OFT [OFT] and Subset Difference [NNL]. These algorithms including one-way function trees [OFT] and Subset Difference [NNL].
could be used with GDOI, but are not specified as a part of this These algorithms could be used with GDOI, but are not specified as a
document. part of this document.
7.4.1. Forward Access Control Requirements 7.4.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm When group membership is altered using a group management algorithm,
new Data-security SAs are usually also needed. New SAs ensure that new Data-Security SAs are usually also needed. New SAs ensure that
members who were denied access can no longer participate in the members who were denied access can no longer participate in the
group. group.
If forward access control is a desired property of the group, new If forward access control is a desired property of the group, new
Data-security SAs MUST NOT be included in a GROUPKEY-PUSH message Data-Security SAs MUST NOT be included in a GROUPKEY-PUSH message
which changes group membership. This is required because the new that changes group membership. This is required because the new
Data-security SAs are not protected with the new KEK. Instead, two Data-Security SAs are not protected with the new KEK. Instead, two
sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first
changing the KEK, and the second (protected with the new KEK) changing the KEK, and the second (protected with the new KEK)
distributing the new Data-security SAs. distributing the new Data-Security SAs.
Note that in the above sequence, although the new KEK can effectively 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 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 view the new KEK policy. If forward access control policy for the
group includes keeping the KEK policy secret as well as the KEK group includes keeping the KEK policy secret as well as the KEK
itself secret, then two GROUPKEY-PUSH messages changing the KEK must itself secret, then two GROUPKEY-PUSH messages changing the KEK must
occur before the new Data-security SAs are transmitted. occur before the new Data-Security SAs are transmitted.
If other methods of using LKH or other group management algorithms If other methods of using LKH or other group management algorithms
are added to GDOI, those methods MAY remove the above restrictions are added to GDOI, those methods MAY remove the above restrictions
requiring multiple GROUPKEY-PUSH messages, providing those methods requiring multiple GROUPKEY-PUSH messages, providing those methods
specify how forward access control policy is maintained within a specify how forward access control policy is maintained within a
single GROUPKEY-PUSH message. single GROUPKEY-PUSH message.
7.4.2. Backward Access Control Requirements 7.4.2. Backward Access Control Requirements
If backward access control is a desired property of the group, a new 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 member MUST NOT be given Data-Security SAs that were used prior to
joining the group. This can be accomplished if the GCKS provides its joining the group. This can be accomplished if the GCKS provides
only the Rekey SA to the new member in a GROUPKEY-PULL exchange, only the Rekey SA to the new member in a GROUPKEY-PULL exchange,
followed by a GROUPKEY-PUSH message that both deletes current Data- followed by a GROUPKEY-PUSH message that both deletes current Data-
security SAs, and provides new replacement Data-security SAs. The Security SAs and provides new replacement Data-Security SAs. The new
new group member will effectively join the group at such time as the group member will effectively join the group at such time as the
existing members begin sending on the Data-security SAs. existing members begin sending on the Data-Security SAs.
If there is a possibility that the new group member has stored If there is a possibility that the new group member has stored
GROUPKEY-PUSH messages delivered prior to joining the group, then the GROUPKEY-PUSH messages delivered prior to joining the group, then the
above procedure is not sufficient. In this case, to achieve backward 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 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 member in a GROUPKEY-PULL exchange rather than the existing one. The
GCKS would subsequently deliver two GROUPKEY-PUSH messages. The GCKS would subsequently deliver two GROUPKEY-PUSH messages. The
first, intended for existing group members, distributes the new first, intended for existing group members, distributes the new Rekey
Rekey-SA to existing members. The GCKS would then deliver the second SA to existing members. The GCKS would then deliver the second
GROUPKEY-PUSH message using the new Rekey-SA that both deletes GROUPKEY-PUSH message using the new Rekey SA that both deletes
current Data-security SAs, and provides new replacement Data-security current Data-Security SAs and provides new replacement Data-Security
SAs. Both preexisting and new members would process the second SAs. Both preexisting and new members would process the second
GROUPKEY-PUSH message, and all would be able to communicate using the GROUPKEY-PUSH message, and all would be able to communicate using the
new Data-security SAs. new Data-Security SAs.
7.5. Derivation of keying material 7.5. Derivation of Keying Material
A GCKS distributes keying material associated with Data-Security SAs A GCKS distributes keying material associated with Data-Security SAs
and the Rekey SA. Because these security associations are used by a 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 set of group members, this keying material is not related to any
wise connection, and there is no requirement in The Multicast Group pair-wise connection, and there is no requirement in "The Multicast
Security Architecture [RFC3740] for group members to permute group Group Security Architecture" [RFC3740] for group members to permute
keying material. Because the GCKS is solely responsible for the group keying material. Because the GCKS is solely responsible for
generation of the keying material, the GCKS MUST derive the keying the generation of the keying material, the GCKS MUST derive the
material using a strong random number generator. Because there are keying material using a strong random number generator. Because
no interoperability concerns with key generation, no method is there are no interoperability concerns with key generation, no method
prescribed in GDOI. is prescribed in GDOI.
8. IANA Considerations 8. IANA Considerations
8.1. Additions to current registries 8.1. Additions to Current Registries
The GDOI KEK Attribute named SIG_HASH_ALGORITHM [GDOI-REG] should be The GDOI KEK Attribute named SIG_HASH_ALGORITHM [GDOI-REG] has been
assigned several new Algorithm Type values from the RESERVED space to assigned several new Algorithm Type values from the RESERVED space to
represent the SHA-256, SHA-384, and SHA-512 hash algorithms as represent the SHA-256, SHA-384, and SHA-512 hash algorithms as
defined in [FIPS180-3.2008]. The new algorithm names should be defined in [FIPS180-3.2008]. The new algorithm names are
SIG_HASH_SHA256, SIG_HASH_SHA384, and SIG_HASH_SHA512 respectively SIG_HASH_SHA256, SIG_HASH_SHA384, and SIG_HASH_SHA512, respectively,
and have the values of TBD-2, TBD-3, and TBD-4 respectively. and have the values of 3, 4, and 5, respectively.
The GDOI KEK Attributed named SIG_ALGORITHM [GDOI-REG] should be The GDOI KEK Attribute named SIG_ALGORITHM [GDOI-REG] has been
assigned several new Algorithm Type values from the RESERVED space to assigned several new Algorithm Type values from the RESERVED space to
represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and
SIG_ALG_ECDSA-521 signature algorithms. The Algorithm Types values SIG_ALG_ECDSA-521 signature algorithms. The Algorithm Types values
should be TBD-7, TBD-8, and TBD-9 respectively. are 4, 5, and 6, respectively.
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] has been assigned
from the RESERVED space. The new algorithm id should be called from the RESERVED space. The new algorithm ID is 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 2.
A new Next Payload Type [ISAKMP-REG] should be assigned. The new A new Next Payload Type [ISAKMP-REG] has been assigned. The new type
type is called "SA Group Associated Policy (GAP)", and has a value of is called "SA Group Associated Policy (GAP)" and has a value of 22.
TBD-1.
A new Key Download Type Section 5.6 should be assigned. The new type A new Key Download Type Section 5.6 has been assigned. The new type
is called "SID", and has a value of TBD-6. is called "SID" and has a value of 4.
8.2. New registries 8.2. New Registries
A new registry identifying the possible values of GAP Payload Policy A new registry identifying the possible values of GAP Payload Policy
Attributes (of the form described in Section 3.3 of [RFC2408]) should Attributes (of the form described in Section 3.3 of [RFC2408]) has
be created in the GDOI Payloads [GDOI-REG]. This memo defines the been created in the GDOI Payloads registry [GDOI-REG]. This memo
following values for this registry: defines the following values for this registry:
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_REQUEST 3 B SENDER_ID_REQUEST 3 B
Standards Action 4-127 Unassigned 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
The terms Standards Action and Private Use are to be applied as The registration procedure is Standards Action. The terms Standards
defined in [RFC5226]. Action and Private Use are to be applied as defined in [RFC5226].
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 has been registered. The attribute
called "Address Preservation", and it is a Basic type. The following class is called "Address Preservation", and it is a Basic type. The
rules apply to define the values of the attribute: following rules apply to define the values of the attribute:
Name Value Name Value
---- ----- ---- -----
Reserved 0 Reserved 0
None 1 None 1
Source-Only 2 Source-Only 2
Destination-Only 3 Destination-Only 3
Source-And-Destination 4 Source-and-Destination 4
Standards Action 5-61439 Unassigned 5-61439
Private Use 61440-65535 Private Use 61440-65535
The terms Standards Action and Private Use are to be applied as The registration procedure is Standards Action. The terms Standards
defined in [RFC5226]. Action and Private Use are to be applied as defined in [RFC5226].
A new IPsec Security Association Attribute [ISAKMP-REG] defining the A new IPsec Security Association Attribute [ISAKMP-REG] defining the
SA direction is needed. The attribute class is called "SA SA direction has been created. The attribute class is called "SA
Direction", and it is a Basic type. The following rules apply to Direction", and it is a Basic type. The following rules apply to
define the values of the attribute: define the values of the attribute:
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 Unassigned 4-61439
Private Use 61440-65535 Private Use 61440-65535
The terms Standards Action and Private Use are to be applied as The registration procedure is Standards Action. terms Standards
defined in [RFC5226]. Action and Private Use are to be applied as defined in [RFC5226].
When the SID "Key Download Type" (described in the previous section) When the SID "Key Download Type" (described in the previous section)
has a set of attributes. The attributes must follow the format has a set of attributes, the attributes must follow the format
defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, defined in ISAKMP (Section 3.3 of [RFC2408]). In the table,
attributes defined as TV are marked as Basic (B); attributes defined attributes defined as TV are marked as Basic (B); attributes defined
as TLV are marked as Variable (V). as TLV are marked as Variable (V).
SID Class Value Type SID Class Value Type
--------- ----- ---- --------- ----- ----
RESERVED 0 RESERVED 0
NUMBER_OF_SID_BITS 1 B NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V SID_VALUE 2 V
Standards Action 3-128 Unassigned 3-128
Private Use 129-255 Private Use 129-255
Unassigned 256-32767 Unassigned 256-32767
The terms Standards Action and Private Use are to be applied as The registration procedure is Standards Action. terms Standards
defined in [RFC5226]. Action and Private Use are to be applied as defined in [RFC5226].
8.3. Cleanup of existing registries 8.3. Cleanup of Existing Registries
Several existing GDOI Payloads registries do not use the terms in RFC 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 5226 and/or do not describe the entire range of possible values. The
following sections correct these registries. The terms Standards following sections correct these registries. The terms Standards
Action, Unassigned, and Private Use are to be applied as defined in Action, Unassigned, and Private Use are to be applied as defined in
[RFC5226]. [RFC5226].
8.3.1. Pop Algorithm 8.3.1. Pop Algorithm
Values 4-127 are to be designated Standards Action. Values 256-32767 The registration procedure is Standards Action. Values 4-27 are
are to be added and designated Unassigned. designated Unassigned. Values 256-32767 have been added and are
designated Unassigned.
8.3.2. KEK Attributes 8.3.2. KEK Attributes
Values 9-127 are to added and designated Standards Action. Values The registration procedure is Standards Action. Values 9-127 have
128-255 are to be added and designated Private Use. Values 256-32767 been added and are designated Unassigned. Values 128-255 have been
are to be added and designated Unassigned. added and are designated Private Use. Values 256-32767 have been
added and are designated Unassigned.
8.3.3. KEK_MANAGEMENT_ALGORITHM 8.3.3. KEK_MANAGEMENT_ALGORITHM
Values 2-127 are to be designated Standards Action. Values 256-65535 The registration procedure is Standards Action. Values 2-127 are
are to be added and designated Unassigned. designated Unassigned. Values 128-255 have been added and designated
Private Use. Values 256-65535 have been added and are designated
Unassigned.
8.3.4. KEK_ALGORITHM 8.3.4. KEK_ALGORITHM
Values 4-127 are to be designated Standards Action. Values 256-65535 The registration procedure is Standards Action. Values 4-127 are
are to be added and designated Unassigned. designated Unassigned. Values 256-65535 have been added and are
designated Unassigned.
8.3.5. SIG_HASH_ALGORITHM 8.3.5. SIG_HASH_ALGORITHM
Values 3-127 are to be designated Standards Action. Values 256-65535 The registration procedure is Standards Action. Values 6-127 are
are to be added and designated Unassigned. designated Unassigned. Values 256-65535 have been added and are
designated Unassigned.
8.3.6. SIG_ALGORITHM 8.3.6. SIG_ALGORITHM
Values 4-127 are to be designated Standards Action. Values 256-65535 The registration procedure is Standards Action. Values 7-127 are
are to be added and designated Unassigned. designated Unassigned. Values 256-65535 have been added and are
designated Unassigned.
8.3.7. SA TEK Payload Values 8.3.7. SA TEK Payload Values
Values 2-127 are to be designated Standards Action. The registration procedure is Standards Action. Values 3-127 are
designated Unassigned.
8.3.8. Key Download Types 8.3.8. Key Download Types
Values 4-127 are to be designated Standards Action. The registration procedure is Standards Action. Values 5-127 are
designated Unassigned.
8.3.9. TEK Download Type 8.3.9. TEK Download Type
Values 4-127 are to be added and designated Standards Action. Values The registration procedure is Standards Action. Values 4-127 have
128-255 are to be added and designated Private Use. Values 256-32767 been added and are designated Unassigned. Values 128-255 have been
are to be added and designated Unassigned. added and are designated Private Use. Values 256-32767 have been
added and are designated Unassigned.
8.3.10. KEK Download Type 8.3.10. KEK Download Type
Values 3-127 are to be designated Standards Action. Values 128-255 The registration procedure is Standards Action. Values 3-127 are
are to be added and designated Private Use. Values 256-32767 are to designated Unassigned. Values 128-255 have been added and are
be added and designated Unassigned. designated Private Use. Values 256-32767 have been added and are
designated Unassigned.
8.3.11. LKH Download Type 8.3.11. LKH Download Type
Values 4-127 are to be designated Standards Action. Values 256-32767 The registration procedure is Standards Action. Values 4-127 are
are to be added and designated Unassigned. designated Unassigned. Values 256-32767 have been added and are
designated Unassigned.
9. Acknowledgements 9. Acknowledgements
This memo replaces RFC 3547, and the authors wish to thank Mark This memo replaces RFC 3547, and the authors wish to thank Mark
Baugher and Hugh Harney for their extensive contributions that led to Baugher and Hugh Harney for their extensive contributions that led to
this newer specification of GDOI. this newer specification 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, Vincent Roca, Sean Turner, and previously identified. Yoav Nir, Vincent Roca, Sean Turner, and
Elwyn Davies provided many useful technical and editorial comments Elwyn Davies provided many useful technical and editorial comments
and suggestions for improvement. and suggestions for improvement.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998. ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
ESP and AH", RFC 2404, November 1998. within ESP and AH", RFC 2404, November 1998.
[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.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management
Multicast: Issues and Architectures", RFC 2627, June 1999. for 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.
[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.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
the Elliptic Curve Digital Signature Algorithm (ECDSA)", Using the Elliptic Curve Digital Signature Algorithm
RFC 4754, January 2007. (ECDSA)", RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[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.
[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.
[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic", RFC 6054, Header (AH) to Protect Group Traffic", RFC 6054,
November 2010. November 2010.
10.2. Informative References 10.2. Informative References
[FIPS180-3.2008] [FIPS180-3.2008]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-3, October 2008, <http:// Hash Standard", FIPS PUB 180-3, October 2008, <http://
csrc.nist.gov/publications/fips/fips180-3/ csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>. fips180-3_final.pdf>.
[FIPS186-3]
"Digital Signature Standard (DSS)", United States of
America, National Institute of Science and
Technology Federal Information Processing Standard (FIPS)
186-2, June 2009.
[FIPS197] "Advanced Encryption Standard (AES)", United States of [FIPS186-3] "Digital Signature Standard (DSS)", United States of
America, National Institute of Science and America, National Institute of Science and
Technology Federal Information Processing Standard (FIPS) Technology, Federal Information Processing Standard
197, November 2001. (FIPS) 186-2, June 2009.
[FIPS46-3] [FIPS197] "Advanced Encryption Standard (AES)", United States of
"Data Encryption Standard (DES)", United States of America, National Institute of Science and
America, National Institute of Science and Technology, Federal Information Processing Standard
Technology Federal Information Processing Standard (FIPS) (FIPS) 197, November 2001.
46-3, October 1999.
[FIPS81] "DES Modes of Operation", United States of America, [FIPS46-3] "Data Encryption Standard (DES)", United States of
National Institute of Science and Technology Federal America, National Institute of Science and
Information Processing Standard (FIPS) 81, December 1980. Technology, Federal Information Processing Standard
(FIPS) 46-3, October 1999.
[FS00] Ferguson, N. and B. Schneier, Counterpane, "A [FIPS81] "DES Modes of Operation", United States of America,
Cryptographic Evaluation of IPsec", National Institute of Science and Technology, Federal
<http://www.counterpane.com/ipsec.html>. Information Processing Standard (FIPS) 81,
December 1980.
[GDOI-REG] [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of
Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values",
Interpretation (GDOI) Payload Type Values", IANA Registry, 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.
[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", European Symposium on
September 2004. Research in Computer Security (ESORICS) 2004, pp. 53-72,
September 2004.
[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receivers", Advances in Tracing Schemes for Stateless Receivers", Advances in
Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,
pp. 41-62, 2001, pp. 41-62, 2001,
<http://www.wisdom.weizmann.ac.il/~naor/>. <http://www.iacr.org/archive/crypto2001/21390040.pdf>.
[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large [OFT] Sherman, A. and D. McGrew, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript, Dynamic Groups Using One-Way Function Trees", IEEE
submitted to IEEE Transactions on Software Engineering, Transactions on Software Engineering, Vol. 29, Issue 5,
1998, <http://download.nai.com/products/media/nai/misc/ pp. 444-458, May 2003,
oft052098.ps>. <http://ieeexplore.ieee.org/search/
freesrchabstract.jsp?tp=&arnumber=1199073>.
[PK01] Perlman, R. and C. Kaufman, "Analysis of the IPsec Key [PK01] Perlman, R. and C. Kaufman, "Analysis of the IPsec Key
Exchange Standard", WET-ICE conference , 2001, Exchange Standard", Enabling Technologies:
<http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>. Infrastructure for Collaborative Enterprises, WET ICE
2001, Proceedings. Tenth IEEE International Workshops on
IEEE Transactions on Software Engineering, pp. 150-156,
June 2001, <http://ieeexplore.ieee.org/search/
freesrchabstract.jsp?tp=&arnumber=953405>.
[PROTOCOL-REG] [PROT-REG] "Assigned Internet Protocol Numbers",
"Assigned Internet Protocol Numbers", <http:// <http://www.iana.org/assignments/protocol-numbers/>.
www.iana.org/assignments/protocol-numbers/
protocol-numbers.txt>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004. (ESP)", RFC 3686, January 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
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. [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.
Briscoe, "Timed Efficient Stream Loss-Tolerant [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
Authentication (TESLA): Multicast Source Authentication (GCM) in IPsec Encapsulating Security Payload (ESP)",
Transform Introduction", RFC 4082, June 2005. RFC 4106, June 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
(GCM) in IPsec Encapsulating Security Payload (ESP)", Internet Protocol", RFC 4301, December 2005.
RFC 4106, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet Protocol", RFC 4301, December 2005. RFC 4306, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES)
Mode with IPsec Encapsulating Security Payload (ESP)", CCM Mode with IPsec Encapsulating Security Payload
RFC 4309, December 2005. (ESP)", RFC 4309, December 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006. Header (AH)", RFC 4359, January 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",
May 2006. RFC 4543, May 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and
Specification", RFC 5905, June 2010. Algorithms Specification", RFC 5905, 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.
[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
Lengths", United States of America, National Institute of of Science and Technology, DRAFT NIST Special
Science and Technology DRAFT NIST Special Publication 800- 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
of Science and Technology NIST Special Publication 800-38A 800-38A 2001 Edition, December 2001.
2001 Edition, December 2001.
Appendix A. GDOI Applications Appendix A. GDOI Applications
GDOI can be used to distribute keys for several secure multicast GDOI can be used to distribute keys for several secure multicast
applications, where different applications have different key applications, where different applications have different key
management requirements. This section outlines two example ways that management requirements. This section outlines two examples of ways
GDOI can be used. Other examples can be found in Section 10 of that GDOI can be used. Other examples can be found in Section 10 of
[HD03]. [HD03].
A simple application is secure delivery of periodic multicast content A simple application is secure delivery of periodic multicast content
over an organization's IP network, perhaps a multicast video over an organization's IP network, perhaps a multicast video
broadcast. Assuming the content delivery time frame is bounded and broadcast. Assuming the content delivery time frame is bounded and
the group membership is not expected to change over time, there is no the group membership is not expected to change over time, there is no
need for group policy to include a GROUPKEY-PUSH exchange, and need for group policy to include a GROUPKEY-PUSH exchange, and there
there's no need for the GCKS to distribute a Re-key SA. Thus, the is no need for the GCKS to distribute a Rekey SA. Thus, the GDOI
GDOI GCKS may only need to distribute a single set of Data-Security GCKS may only need to distribute a single set of Data-Security SAs to
SAs to protect the time-bounded broadcast. protect the time-bounded broadcast.
In contrast, a persistent IP multicast application (e.g., stock- In contrast, a persistent IP multicast application (e.g., stock-
ticker delivery service) may have many group members, where the group ticker delivery service) may have many group members, where the group
membership changes over time. A periodic change of Data-security SAs membership changes over time. A periodic change of Data-Security SAs
may be desirable, and the potential for change in group membership may be desirable, and the potential for change in group membership
requires the use of a group management method enabling de- requires the use of a group management method enabling de-
authorization of group members. The GDOI GCKS will distribute the authorization of group members. The GDOI GCKS will distribute the
current set of Data-Security SAs and a Re-key SA to registering group current set of Data-Security SAs and a Rekey SA to registering group
members. It will then deliver regularly-scheduled GROUPKEY-PUSH members. It will then use regularly scheduled GROUPKEY-PUSH
protocol delivering the new SAs for the group. Additionally, the exchanges to deliver the new SAs for the group. Additionally, the
group membership on the GCKS may be frequently adjusted, which will group membership on the GCKS may be frequently adjusted, which will
result in GROUPKEY-PUSH exchange delivering a new Rekey SAs protected result in a GROUPKEY-PUSH exchange that delivers new Rekey SAs
by a group management method. Each GROUPKEY-PUSH may include Data- protected by a group management method. Each GROUPKEY-PUSH may
security SAs and/or a Rekey SA. include Data-Security SAs and/or a Rekey SA.
In each example the relevant policy is defined on the GCKS and In each example, the relevant policy is defined on the GCKS and
relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH
protocols. Specific policy choices configured by the GCKS protocols. Specific policy choices configured by the GCKS
administrator depends on each application. administrator depend on each application.
Appendix B. Significant Changes from RFC 3547 Appendix B. 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
obviated the need for the CERT payload in that exchange and it was obviated the need for the CERT payload in that exchange, and it
removed as well. was removed as well.
o The Key Exchange Payloads (KE_I, KE_R) payloads were removed from o The Key Exchange payloads (KE_I, KE_R) were removed from the
the GROUPKEY-PULL exchange. However, the specification for GROUPKEY-PULL exchange. However, the specification for computing
computing keying material for the additional encryption function keying material for the additional encryption function in RFC 3547
in RFC 3547 is faulty. Furthermore, it has been observed that is faulty. Furthermore, it has been observed that because the
because the GDOI registration message uses strong ciphers and GDOI registration message uses strong ciphers and provides
provides authenticated encryption, additional encryption of the authenticated encryption, additional encryption of the keying
keying material in a GDOI registration message provides negligible material in a GDOI registration message provides negligible value.
value. Therefore, the use of KE payloads is deprecated in this Therefore, the use of KE payloads is deprecated in this memo.
memo.
o The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH o The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH
exchange. The use of this payload was underspecified. In all exchange. The use of this payload was underspecified. In all
known use cases, the public key of used to verify the GROUPKEY- known use cases, the public key used to verify the GROUPKEY-PUSH
PUSH payload is distributed directly from the key server as part payload is distributed directly from the key server as part of the
of the GROUPKEY-PULL exchange. GROUPKEY-PULL exchange.
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
bit keys to encrypt the rekey message, and SHA-256 for 128-bit keys to encrypt the rekey message and support 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
Multicast Extensions to the Security Architecture for the Internet the "Multicast Extensions to the Security Architecture for the
Protocol[RFC5374]. This includes addition of the GAP payload. Internet Protocol" [RFC5374]. This includes addition of the GAP
payload.
o New protocol definitions and semantics were added to support Using o New protocol definitions and semantics were added to support
Counter Modes with ESP and AH to Protect Group Traffic[RFC6054]. "Using Counter Modes with Encapsulating Security Payload (ESP) and
Authentication Header (AH) to Protect Group Traffic" [RFC6054].
o Specification to IANA to better clarify the use of the GDOI o Specification to IANA was added to better clarify the use of the
Payloads registry. 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
Email: bew@cisco.com EMail: bew@cisco.com
Sheela Rowles Sheela Rowles
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-527-7677 Phone: +1-408-527-7677
Email: sheela@cisco.com EMail: sheela@cisco.com
Thomas Hardjono Thomas Hardjono
MIT MIT
77 Massachusetts Ave. 77 Massachusetts Ave.
Cambridge, Massachusets 02139 Cambridge, Massachusetts 02139
USA USA
Phone: +1-781-729-9559 Phone: +1-781-729-9559
Email: hardjono@mit.edu EMail: hardjono@mit.edu
 End of changes. 383 change blocks. 
971 lines changed or deleted 976 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/