draft-ietf-msec-gdoi-update-08.txt   draft-ietf-msec-gdoi-update-09.txt 
MSEC Working Group B. Weis Updates: 3547 (once approved) B. Weis
Internet-Draft S. Rowles Internet-Draft S. Rowles
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: September 15, 2011 T. Hardjono Expires: January 2, 2012 T. Hardjono
MIT MIT
March 14, 2011 July 1, 2011
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-08 draft-ietf-msec-gdoi-update-09
Abstract Abstract
This document describes an updated version of the Group Domain of This document describes an updated version of the Group Domain of
Interpretation (GDOI) protocol specified in RFC 3547. The GDOI Interpretation (GDOI) protocol specified in RFC 3547. The GDOI
provides group key management to support secure group communications provides group key management to support secure group communications
according to the architecture specified in RFC 4046. The GDOI according to the architecture specified in RFC 4046. The GDOI
manages group security associations, which are used by IPsec and manages group security associations, which are used by IPsec and
potentially other data security protocols. potentially other data security protocols.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on January 2, 2012.
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 28 skipping to change at page 2, line 28
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 6 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 6
2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 8 2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 8
2.1. ISAKMP Phase 1 protocol . . . . . . . . . . . . . . . . . 8 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Group Member Operations . . . . . . . . . . . . . . . . . 11 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 11
3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13
3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 13 3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 13
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16
4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 17 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 7 skipping to change at page 3, line 8
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
5.2. Security Association Payload . . . . . . . . . . . . . . . 20 5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 22 5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 22
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 28 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 28
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 43 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 43
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 46 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 48 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 49 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 51 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
7.4. Forward and Backward Access Control . . . . . . . . . . . 52 7.4. Forward and Backward Access Control . . . . . . . . . . . 51
7.5. Derivation of keying material . . . . . . . . . . . . . . 54 7.5. Derivation of keying material . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8.1. Additions to current registries . . . . . . . . . . . . . 55 8.1. Additions to current registries . . . . . . . . . . . . . 54
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 55 8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 54
8.3. Cleanup of existing registries . . . . . . . . . . . . . . 57 8.3. Cleanup of existing registries . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . . 60 10.1. Normative References . . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . . 60 10.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Extending GDOI . . . . . . . . . . . . . . . . . . . 65 Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 63
A.1. Alternate GDOI Phase 1 protocols . . . . . . . . . . . . . 65
A.2. Supporting new SA TEK types . . . . . . . . . . . . . . . 66
Appendix B. GDOI Applications . . . . . . . . . . . . . . . . . . 67
Appendix C. Significant Changes from RFC 3547 . . . . . . . . . . 68 Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
Secure group and multicast applications require a method by which Secure group and multicast applications require a method by which
each group member shares common security policy and keying material. each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI), This document describes the Group Domain of Interpretation (GDOI),
which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group
key management system. The GDOI distributes security associations key management system. The GDOI distributes security associations
(SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and (SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and
potentially other data security protocols used in group applications. potentially other data security protocols used in group applications.
skipping to change at page 4, line 33 skipping to change at page 4, line 33
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 (p.16 of [RFC2408]). A
Phase 1 security association provides mutual authentication and Phase 1 security association provides mutual authentication and
authorization, and a security association that is used by the authorization, and a security association that is used by the
protocol participants to execute a phase 2 exchange. This document protocol participants to execute a phase 2 exchange. This document
incorporates (i.e., uses but does not re-define) the Phase 1 security incorporates (i.e., uses but does not re-define) the Phase 1 security
association definition from the Internet DOI [RFC2407], [RFC2409]. association definition from the Internet DOI [RFC2407], [RFC2409].
Phase 1 security association types other than ISAKMP are possible, The GDOI includes two new phase 2 ISAKMP exchanges (protocols), as
and are noted in Appendix A. Requirements of those phase 1 security well as necessary new payload definitions to the ISAKMP standard (p.
associations are specified in Section 2. The GDOI includes two new 14 of [RFC2408]). These two new protocols are:
phase 2 ISAKMP exchanges (protocols), as well as necessary new
payload definitions to the ISAKMP standard (p. 14 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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
ESP IP Encapsulating Security Payload ESP IP Encapsulating Security Payload
GCKS Group Controller/Key Server GCKS Group Controller/Key Server
GDOI Group Domain of Interpretation GDOI Group Domain of Interpretation
GAP Group Associated Policy Payload GAP Group Associated Policy Payload
GM Group Member GM Group Member
GSPD Group Security Policy Database
IV Initialization Vector IV Initialization Vector
KD Key Download Payload KD Key Download Payload
KEK Key Encryption Key KEK Key Encryption Key
LKH Lock Key Hierarchy LKH Lock Key Hierarchy
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
SSIV Sender-Specific ID
TEK Traffic Encryption Key TEK Traffic Encryption Key
2. GDOI Phase 1 protocol 2. GDOI Phase 1 protocol
The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be
protected by a "phase 1" protocol. The "phase 1" protocol can be any protected by a "phase 1" protocol. The "phase 1" protocol can be any
protocol which provides for the following protections: protocol which provides for the following protections:
o Peer Authentication o Peer Authentication
o Confidentiality o Confidentiality
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.
2.1. ISAKMP Phase 1 protocol
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.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.1.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, which allows for an
implementation to use separate ISAKMP implementations to service GDOI implementation to use separate ISAKMP implementations to service GDOI
and IKEv1 [RFC2409]. A GCKS SHOULD listen on this port for GROUPKEY- and IKEv1 [RFC2409]. A GCKS SHOULD listen on this port for GROUPKEY-
PULL exchanges, and the GCKS MAY use this port to distribute PULL exchanges, and the GCKS MAY use this port to distribute
GROUPKEY-PUSH messages. An ISAKMP phase 1 exchange implementation GROUPKEY-PUSH messages. An ISAKMP phase 1 exchange implementation
supporting NAT Traversal [RFC3947] may move to port 4500 to process supporting NAT Traversal [RFC3947] may move to port 4500 to process
the GROUPKEY-PULL exchange. the GROUPKEY-PULL exchange.
3. GROUPKEY-PULL Exchange 3. GROUPKEY-PULL Exchange
skipping to change at page 10, line 17 skipping to change at page 10, line 17
HDR*, HASH(1), Ni, ID --> HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA <-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,GAP] --> HDR*, HASH(3) [,GAP] -->
<-- HDR*, HASH(4), [SEQ,] KD <-- 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
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
message identifier (M-ID) as in IKEv1. message identifier (M-ID) as in IKEv1.
Hashes are computed in the manner described within RFC 2409. Each Hashes are computed in the manner described within [RFC2409]. Each
HASH computation (shown below) is a prf over the message id (M-ID) HASH computation (shown below) is a psuedo-random function ("prf")
from the ISAKMP header concatenated with the entire message that over the message id (M-ID) from the ISAKMP header concatenated with
follows the hash including all payload headers, but excluding any the entire message that follows the hash including all payload
padding added for encryption. The GM expects to find its nonce, Ni, headers, but excluding any padding added for encryption. The GM
in the HASH of a returned message. And the GCKS expects to see its expects to find its nonce, Ni, in the HASH of a returned message.
nonce, Nr, in the HASH of a returned message. HASH(2), HASH(3), and And the GCKS expects to see its nonce, Nr, in the HASH of a returned
HASH(4) also include nonce values previously passed in the protocol message. HASH(2), HASH(3), and HASH(4) also include nonce values
(i.e., Ni or Nr minus the payload header). The nonce passed in Ni is previously passed in the protocol (i.e., Ni or Nr minus the payload
represented as Ni_b, and the nonce passed in Nr is represented as header). The nonce passed in Ni is represented as Ni_b, and the
Nr_b. The HASH payloads prove that the peer has the Phase 1 secret nonce passed in Nr is represented as Nr_b. The HASH payloads prove
(SKEYID_a) and the nonce for the exchange identified by message id, that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the
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
skipping to change at page 11, line 9 skipping to change at page 11, line 9
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 ensure that the GM will not associated with a KEK, and its knowledge ensure that the GM will not
accept GROUPKEY-PULL messages sent prior to the GM joining the group. accept GROUPKEY-PULL messages sent prior to the GM joining the group.
The SEQ payload has no other use, and is omitted from the The SEQ payload has no other use, and is omitted from the GROUPKEY-
GROUPKEY_PULL exchange when a KEK attribute is not included in the SA PULL exchange when a KEK attribute is not included in the SA payload.
payload. When a SEQ payload is included in the GROUPKEY-PULL When a SEQ payload is included in the GROUPKEY-PULL exchange, it
exchange, it includes the most recently used sequence number for the includes the most recently used sequence number for the group. At
group. At the conclusion of a GROUPKEY-PULL exchange, the initiating the conclusion of a GROUPKEY-PULL exchange, the initiating group
group member MUST NOT accept any rekey message with both the KEK member MUST NOT accept any rekey message with both the KEK attribute
attribute SPI value and a sequence number less than or equal to the SPI value and a sequence number less than or equal to the one
one received during the GROUPKEY-PULL. When the first group member received during the GROUPKEY-PULL. When the first group member
initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence
Number of zero, since no GROUPKEY-PUSH messages have yet been sent. Number of zero, since no GROUPKEY-PUSH messages have yet been sent.
Note the sequence number increments only with GROUPKEY-PUSH messages. Note the sequence number increments only with GROUPKEY-PUSH messages.
The GROUPKEY-PULL exchange distributes the current sequence number to The GROUPKEY-PULL exchange distributes the current sequence number to
the group member. The sequence number resets to a value of one with the group member. The sequence number resets to a value of one with
the usage of a new KEK attribute. Thus the first packet sent for a the usage of a new KEK attribute. Thus the first packet sent for a
given Rekey SA will have a Sequence Number of 1. The sequence number given Rekey SA will have a Sequence Number of 1. The sequence number
increments with each successive rekey. 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
skipping to change at page 11, line 49 skipping to change at page 11, line 49
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange. The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of
[RFC2408]). [RFC2408]).
3.3. Group Member Operations 3.3. Group Member Operations
Before a GM contacts the GCKS, it must determine the group identifier Before a GM contacts the GCKS, it needs to determine the group
and acceptable Phase 1 policy via an out-of-band method. Phase 1 is identifier and acceptable Phase 1 policy via an out-of-band method.
initiated using the GDOI DOI in the SA payload. Once Phase 1 is Phase 1 is initiated using the GDOI DOI in the SA payload. Once
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 and 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. The SA payload extracts the nonce Nr, and interprets the SA payload. The SA payload
contains policy describing the security protocol and cryptographic contains policy describing the security protocol and cryptographic
protocols used by the group. This policy describes the Re-key SA (if protocols used by the group. This policy describes the Re-key SA (if
present), Data-security SAs, and other group policy. If the policy present), Data-security SAs, and other group policy. If the policy
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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 include a cipher counter mode, it security SA given to it. If any include a cipher counter mode, it
needs to request for one or more Sender-IDs for its exclusive use needs to request for one or more Sender-IDs for its exclusive use
within the counter mode nonce. Do to this, the GM will include a GAP within the counter mode nonce. Do to this, the GM will include a GAP
payload with its request, as described in the Section 5.4 section of payload with its request, as described in the Section 5.4 section of
this document. The GM the completes construction of the third GDOI this document. The GM the completes construction of the third GDOI
message by creating HASH(3). 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 in the SEQ payload If the SEQ payload is present, the sequence number included in the
must be checked against any previously received sequence number for SEQ payload MUST be greater than any previously received sequence
this group. If it is less than the previously received number, it number. If it is less than the previously received number, it MUST
should be considered stale and ignored. be considered stale 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 SPIs in the key packets to SPIs material is matched by comparing the SPIs in the key packets to SPIs
previously sent in the SA payloads. Once TEK keys and policy are previously sent in the SA payloads. Once TEK keys and policy are
matched, the GM provides them to the data security subsystem, and it matched, the GM provides them to the data security subsystem, and it
is ready to send or receive packets matching the TEK policy. If this is ready to send or receive packets matching the TEK policy. If this
group has a KEK, the KEK policy and keys are marked as ready for use, group has a KEK, the KEK policy and keys are marked as ready for use,
and the GM knows to expect the sequence number reset to 1 with the and the GM knows to expect the sequence number reset to 1 with the
next Rekey SA, which will be encrypted with the new KEK attribute. next Rekey SA, which will be encrypted with the new KEK attribute.
skipping to change at page 17, line 33 skipping to change at page 17, line 33
Re-key SA to differentiate the secure groups managed by a GCKS. Re-key SA to differentiate the secure groups managed by a GCKS.
Thus, GDOI uses the cookie fields as an SPI. Thus, GDOI uses the cookie fields as an SPI.
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Flags MUST have the Encryption bit set according to [RFC2008, Section Flags MUST have the Encryption bit set according to Section 3.1 of
3.1]. 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.
skipping to change at page 18, line 35 skipping to change at page 18, line 35
4.4. Group Member Operations 4.4. Group Member Operations
A group member receiving the GROUPKEY-PUSH datagram matches the A group member receiving the GROUPKEY-PUSH datagram matches the
cookie pair in the ISAKMP HDR to an existing SA. The message is cookie pair in the ISAKMP HDR to an existing SA. The message is
decrypted, and the form of the datagram is validated. This weeds out decrypted, and the form of the datagram is validated. This weeds out
obvious ill-formed messages (which may be sent as part of a Denial of obvious ill-formed messages (which may be sent as part of a Denial of
Service attack on the group). Service attack on the group).
The sequence number in the SEQ payload is validated to ensure that it The sequence number in the SEQ payload is validated to ensure that it
is greater than the previously received sequence number, and that it is greater than the previously received sequence number. The SIG
fits within a window of acceptable values. The SIG payload is then payload is then validated. If the signature fails, the message is
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.
skipping to change at page 20, line 8 skipping to change at page 20, line 8
of operation and the receiving group member is a sender for that SA, of operation and the receiving group member is a sender for that SA,
the group member uses its current SID value with the Data-Security the group member uses its current SID value with the Data-Security
SAs to create counter-mode nonces. If it is a sender and does not SAs to create counter-mode nonces. If it is a sender and does not
hold a current SID value, it MUST NOT install the Data-Security SAs. hold a current SID value, it MUST NOT install the Data-Security SAs.
It MAY initiate a GROUPKEY-PULL exchange to the GCKS in order to It MAY initiate a GROUPKEY-PULL exchange to the GCKS in order to
obtain an SID value (along with current group policy). obtain an SID value (along with current group policy).
5. Payloads and Defined Values 5. Payloads and Defined Values
This document specifies use of several ISAKMP payloads, which are This document specifies use of several ISAKMP payloads, which are
defined in accordance with RFC 2408. The following payloads are defined in accordance with [RFC2408]. The following payloads are
extended or further specified. extended or further specified.
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
Security Association (SA) 1 Security Association (SA) 1
Identification (ID) 5 Identification (ID) 5
Nonce (N) 10 Nonce (N) 10
Several payload formats specific to the group security exchanges are Several payload formats specific to the group security exchanges are
required. required.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
SA KEK Payload (SAK) 15 SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16 SA TEK Payload (SAT) 16
Key Download (KD) 17 Key Download (KD) 17
Sequence Number (SEQ) 18 Sequence Number (SEQ) 18
Group Associated Policy (GAP) TBD-1 Group Associated Policy (GAP) TBD-1
5.1. Identification Payload 5.1. Identification Payload
The Identification Payload is defined in RFC 2408. For the GDOI, it The Identification Payload is defined in [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 IP multicast group, or may specify a more general to a specific IP multicast group, or may specify a more general
identifier, such as one that represents a set of related multicast identifier, such as one that represents a set of related multicast
streams. streams.
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 four (4)-octet group
identifier as its value. Implementations MAY also support other ID identifier 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 RFC 2408. 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. Re-key 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 SAK Payload or SAT Payload type, but the next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST
next non-Security Association type payload. be the next non-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 (1 octet) -- Must be either a SAK Payload o SA Attribute Next Payload (1 octet) -- MUST be either a SAK Payload
or a SAT Payload. See section 5.2.1 for a description of which or a SAT Payload. See section 5.2.1 for a description of which
circumstances are required for each payload type to be present. circumstances are required for each payload type to be present.
o RESERVED (2 octets) -- Must be zero. o RESERVED (2 octets) -- MUST be zero.
5.2.1. Payloads following the SA payload 5.2.1. Payloads following the SA payload
Payloads that define specific security association attributes for the Payloads that define specific security association attributes for the
KEK and/or TEKs used by the group MUST follow the SA payload. How KEK and/or TEKs used by the group MUST follow the SA payload. How
many of each payload is dependent upon the group policy. There may many of each payload is dependent upon the group policy. There may
be zero or one SAK 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: KEK, When present, the order of the SA Attributes payloads MUST be: KEK,
GAP, and TEKs. GAP, and TEKs.
This latitude regarding SA Attributes payloads allows various group This latitude regarding SA Attributes 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 Re-key SA, the GCKS would not need to send
an SA KEK attribute to the group member since all SA updates would be an 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 Re-key SA but choose to download a KEK to the group
member only as part of the Registration SA. Therefore, the KEK member only as part of the Registration SA. Therefore, the KEK
policy (in the SA KEK attribute) would not be necessary as part of policy (in the SA KEK attribute) would not be necessary as part of
skipping to change at page 23, line 7 skipping to change at page 23, line 7
~ KEK Attributes ~ ~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 zero
to indicate that no SA Attribute payloads follow. 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) for the rekey datagram. UDP/TCP) for the rekey 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]. isakmpd-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 the source Id. A value of zero means that the SRC ID Port field MUST
should be ignored. be ignored.
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC
Identification Data field. Identification Data field.
o SRC Identification Data (variable length) -- Value, as indicated by o SRC Identification Data (variable length) -- Value, as indicated by
the SRC ID Type. 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
skipping to change at page 23, line 48 skipping to change at page 23, line 48
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 of the DST o DST ID Data Len (1 octet) -- Value specifying the length of the DST
Identification Data field. Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated by
the DST ID Type. the DST ID Type.
o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become is the ISAKMP Header cookie pair where the first 8 octets become the
the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and
and the second 8 octets become the "Responder Cookie" in the same the second 8 octets become the "Responder Cookie" in the same HDR.
HDR. As described above, these cookies are assigned by the GCKS. As described above, these cookies are assigned by the GCKS.
o RESERVED2 (4 octets) -- Must be zero. This bytes represent fields o RESERVED2 (4 octets) -- MUST be zero. These bytes represent fields
previously defined but no longer used by GDOI. previously defined but no longer used by GDOI.
o KEK Attributes -- Contains KEK policy attributes associated with o KEK Attributes -- Contains KEK policy attributes associated with
the group. The following sections describe the possible attributes. the group. The following attributes may be present in a SAK Payload.
Any or all attributes may be optional, depending on the group policy. The attributes must follow the format defined in ISAKMP (Section 3.3
of [RFC2408]). In the table, attributes that are defined as TV are
5.3.1. KEK Attributes
The following attributes may be present in a SAK Payload. The
attributes must follow the format defined in ISAKMP (Section 3.3 of
[RFC2408]). In the table, attributes that are defined as TV are
marked as Basic (B); attributes that are defined as TLV are marked as marked as Basic (B); attributes that are defined as TLV are marked as
Variable (V). 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
KE_OAKLEY_GROUP 8 B RESERVED 8 B
Standards Action 9-127 Standards Action 9-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others
GROUPKEY-PULL message. are OPTIONAL, and included depending on group policy. The
KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a
GROUPKEY-PULL message, and MUST be ignored if present.
5.3.2. 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 Standards Action 2-127
Private Use 128-255 Private Use 128-255
5.3.2.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.3. 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
skipping to change at page 25, line 42 skipping to change at page 25, line 35
Standards Action 4-127 Standards Action 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 which defines multiple keys
(e.g., LKH), and if the management algorithm does not specify the (e.g., LKH), and if the management algorithm does not specify the
algorithm for those keys, then the algorithm defined by the algorithm for those keys, then the algorithm defined by the
KEK_ALGORITHM attribute MUST be used for all keys which are included KEK_ALGORITHM attribute MUST be used for all keys which are included
as part of the management. as part of the management.
5.3.3.1. KEK_ALG_DES 5.3.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.3.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.3.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 recommended in operation for AES is Cipher Block Chaining (CBC) as defined in
[SP.800-38A]. [SP.800-38A].
5.3.4. 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.5. 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 four (4) octet number
defining a valid time period in seconds. defining a valid time period in seconds.
5.3.6. SIG_HASH_ALGORITHM 5.3.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 TBD-2
SIG_HASH_SHA384 TBD-3 SIG_HASH_SHA384 TBD-3
SIG_HASH_SHA512 TBD-4 SIG_HASH_SHA512 TBD-4
Standards Action 3-127 Standards Action 3-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
The SHA hash algorithms are defined in the Secure Hash The SHA hash algorithms are defined in the Secure Hash
Standard[FIPS.180-2.2002]. Standard[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 not required to be present in a SAK and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload.
Payload.
5.3.7. 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_RSA_PSS TBD-6
SIG_ALG_ECDSA-256 TBD-7 SIG_ALG_ECDSA-256 TBD-7
SIG_ALG_ECDSA-384 TBD-8 SIG_ALG_ECDSA-384 TBD-8
SIG_ALG_ECDSA-521 TBD-9 SIG_ALG_ECDSA-521 TBD-9
Standards Action 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
Unassigned 256-32767 Unassigned 256-32767
5.3.7.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.7.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.7.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.7.4. SIG_ALG_RSA_PSS 5.3.6.4. SIG_ALG_ECDSA-256
This algorithm specifies the RSA digital signature algorithm using
the EMSA-PSS encoding method, as described in [RFC3447].
5.3.7.5. 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.7.6. SIG_ALG_ECDSA-384 5.3.6.5. SIG_ALG_ECDSA-384
This algorithm specifies the 384-bit Random ECP Group, as described This algorithm specifies the 384-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.7.7. SIG_ALG_ECDSA-521 5.3.6.6. SIG_ALG_ECDSA-521
This algorithm specifies the 521-bit Random ECP Group, as described This algorithm specifies the 521-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.8. SIG_KEY_LENGTH 5.3.7. SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key The SIG_KEY_LENGTH class specifies the length of the SIG payload key
in bits. in bits.
5.4. Group Associated Policy 5.4. Group Associated Policy
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
skipping to change at page 29, line 7 skipping to change at page 28, line 33
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 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 SA 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 SA GAP payload is defined as follows: The GAP payload is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Group Associated Policy Attributes ~ ! Group Associated Policy Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SA GAP payload fields are defined as follows: The GAP payload fields are defined as follows:
o Next Payload (1 octet) -- Identifies the next payload present in o Next Payload (1 octet) -- Identifies the next payload present in
the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid
next payload type for this message is an SA TEK or zero to next payload type for this message is an SA TEK 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
SA GAP header and Attributes. GAP header and Attributes.
o Group Associated Policy Attributes (variable) -- Contains o Group Associated Policy Attributes (variable) -- Contains
attributes following the format defined in Section 3.3 of RFC attributes following the format defined in Section 3.3 of
2408. [RFC2408].
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 An 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 RFC 5374 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 re-key event. The value is in seconds.
The values of ATD and DTD are independent. However, the DTD value The values of ATD and DTD are independent. However, the most
should be larger, which allows new SAs to be activated before older effective policy will have the DTD value to be the larger value as
SAs are deactivated. Such a policy ensures that protected group this allows new SAs to be activated before older SAs are deactivated.
traffic will always flow without interruption. Such a policy ensures that protected group traffic will always flow
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
skipping to change at page 30, line 44 skipping to change at page 30, line 27
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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. o Protocol-ID (1 octet) -- Value specifying the Security Protocol.
The following table defines values for the Security Protocol The following table defines values for the Security Protocol
Protocol ID Value Protocol ID Value
----------- ----- ----------- -----
RESERVED 0 RESERVED 0
GDOI_PROTO_IPSEC_ESP 1 GDOI_PROTO_IPSEC_ESP 1
GDOI_PROTO_IPSEC_AH TBD-5 GDOI_PROTO_IPSEC_AH TBD-5
Standards Action 3-127 Standards Action 3-127
Private Use 128-255 Private Use 128-255
o TEK Protocol-Specific Payload (variable) -- Payload which describes o TEK Protocol-Specific Payload (variable) -- Payload which describes
the attributes specific for the Protocol-ID. the attributes specific for the Protocol-ID.
skipping to change at page 31, line 38 skipping to change at page 31, line 24
! DST Identification Data ~ ! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI ! ! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~ ! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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). A value of zero means that the Protocol field should be UDP/TCP). A value of zero means that the Protocol field MUST be
ignored. 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]. isakmpd-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 the source Id. A value of zero means that the SRC ID Port field MUST
should be ignored. be ignored.
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC
Identification Data field. Identification Data field.
o SRC Identification Data (variable length) -- Value, as indicated by o SRC Identification Data (variable length) -- Value, as indicated by
the SRC ID Type. Set to three bytes of zero for multiple-source the SRC ID Type. Set to three bytes of 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]. isakmpd-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). A value of zero means that the DST Id Prot field should be UDP/TCP). A value of zero means that the DST Id Prot field MUST be
ignored. 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 the source Id. A value of zero means that the DST ID Port field MUST
should be ignored. be ignored.
o DST ID Data Len (1 octet) -- Value specifying the length of the DST o DST ID Data Len (1 octet) -- Value specifying the length of the DST
Identification Data field. Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated by
the DST ID Type. the DST ID Type.
o 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 the
IPsec ESP or IPsec AH Transform Identifiers section of the IANA IPsec ESP or IPsec AH Transform Identifiers section of the IANA
isakmpd-registry [ISAKMP-REG]. isakmpd-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 RFC 2407 Section o RFC 2407 Attributes -- ESP and AH Attributes from Section 4.5 of
4.5. 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 a
GDOI implementation and is ignored by a GDOI implementation if GDOI implementation and is ignored by a GDOI implementation if
received. The following attributes MUST be supported by an received. The following attributes MUST be supported by an
implementation supporting ESP and AH: SA Life Type, SA Life Duration, implementation supporting ESP and AH: SA Life Type, SA Life Duration,
Encapsulation Mode. An implementation supporting ESP must also Encapsulation Mode. An implementation supporting ESP MUST also
support the Authentication Algorithm attribute if the ESP transform support the Authentication Algorithm attribute if the ESP transform
includes authentication/ The Authentication Algorithm attribute of includes authentication. The Authentication Algorithm attribute of
the IPsec DOI is group authentication in GDOI. the IPsec DOI is group authentication in GDOI.
5.5.1.1. New IPsec Security Association Attributes 5.5.1.1. New IPsec Security Association Attributes
The Multicast Extensions to the Security Architecture for the The Multicast Extensions to the Security Architecture for the
Internet Protocol (RFC 5374) introduces new requirements for a group Internet Protocol (RFC 5374) introduces new requirements for a group
key management system distributing IPsec policy. It also defines new key 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
Applications use the extensions in RFC 5374 to copy the IP addresses Applications use the extensions in [RFC5374] to copy the IP addresses
into the outer IP header when encapsulating an IP packet as an IPsec into the outer IP header when encapsulating an IP packet as an IPsec
tunnel mode packet. This allows an IP multicast packet to continue tunnel mode packet. This allows an IP multicast packet to continue
to be routed as a IP multicast packet. In order for the GDOI group to be routed as a IP multicast packet. This attribute also provides
member to appropriately set up the GSPD, the GCKS must provide that the necessary policy so that the GDOI group member can appropriately
policy to the group member. set up the GSPD.
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"). The IANA Considerations section of this memo adds And-Destination"). The IANA Considerations section of this memo adds
the "Address Preservation" security association attribute. If this the "Address Preservation" security association attribute. If this
attribute is not included in a GDOI SA TEK payload provided by a attribute is not included in a GDOI SA TEK payload provided by a
GCKS, then Source-And-Destination address preservation has been GCKS, then Source-And-Destination address preservation has been
defined for the SA TEK. 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
may be required in one or both directions. SA TEK policy used by is defined to be in the sending and/or receiving direction. SA TEK
multiple senders is required to be installed in both the sending and policy used by multiple senders MUST be installed in both the sending
receiving direction ("Symmetric"), whereas SA TEK for a single sender and receiving direction ("Symmetric"), whereas SA TEK for a single
should only be installed in the receiving direction by receivers sender SHOULD be installed in the receiving direction by receivers
("Receiver-Only") and in the sending direction by the sender ("Receiver-Only") and in the sending direction by the sender
("Sender-Only"). The IANA Considerations section of this memo adds ("Sender-Only"). The IANA Considerations section of this memo adds
the "SA Direction" security association attribute. the "SA Direction" security association attribute.
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 unless Symmetric may be treated as a Symmetric IPsec SA. Note that unless Symmetric may be
the only value that can be meaningfully described for an SA TEK the only value that can be meaningfully described for an SA TEK
distributed in an GROUPKEY-PUSH message. Alternatively, Receiver- distributed in an GROUPKEY-PUSH message. Alternatively, Receiver-
Only could be distributed, but group senders would need to be Only could be distributed, but group senders would need to be
configured to not receive GROUPKEY-PUSH messages in order to retain configured to not receive GROUPKEY-PUSH messages in order to retain
skipping to change at page 34, line 21 skipping to change at page 34, line 4
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 which MAY be shared by more than two entities.
5.6. Key Download Payload 5.6. Key Download Payload
skipping to change at page 36, line 11 skipping to change at page 35, line 24
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-7 SID TBD-6
Standards Action 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
"KEK" is a single key whereas LKH is an array of key-encrypting keys. "KEK" is a single key whereas LKH is an array of key-encrypting keys.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Key Download Length (2 octets) -- Length in octets of the Key o Key Download Length (2 octets) -- Length in octets of the Key
Packet data, including the Key Packet header. Packet data, including the Key Packet header.
skipping to change at page 37, line 48 skipping to change at page 36, line 50
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 member. HMAC-SHA1 keys will consist of 160 keys are pushed to the GM. HMAC-SHA1 keys will consist of 160 bits
bits[RFC2404], HMAC-MD5 keys will consist of 128 bits[RFC2403].
HMAC-SHA2 and AES-GMAC keys will have a key length equal to the [RFC2404], HMAC-MD5 keys will consist of 128 bits [RFC2403]. HMAC-
output length of the hash functions [RFC4868][RFC4543]. SHA2 and AES-GMAC keys will have a key length equal to the 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
The following attributes may be present in a KEK Download Type. The following attributes may be present in a KEK Download Type.
Exactly one attribute matching each type sent in the SAK payload MUST Exactly one attribute matching each type sent in the SAK 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).
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 Standards Action 3-127
skipping to change at page 39, line 11 skipping to change at page 38, line 12
is contained in the Key Packet Attribute, which may be useful when no is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload. will use this key was specified in the SAK payload.
5.6.3. LKH Download Type 5.6.3. LKH Download Type
The LKH key packet is comprised of attributes representing different The LKH key packet is comprised of attributes representing different
nodes in the LKH key tree. nodes in the LKH key tree.
The following attributes are used to pass an LKH KEK array in the KD The following attributes are used to pass an LKH KEK array in the KD
payload. The attributes must follow the format defined in ISAKMP payload. 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
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 Standards Action 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
GROUPKEY-PUSH is sent to more than the group member. If an GROUPKEY-PUSH is sent to more than the group member. If an
LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there MUST
be only one present. be only one present.
This attribute consists of a header block, followed by one or more This attribute consists of a header block, followed by one or more
LKH keys. LKH keys.
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 Version ! # of LKH Keys ! RESERVED ! ! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 40 skipping to change at page 42, line 15
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 Standards Action 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
skipping to change at page 43, line 29 skipping to change at page 42, line 48
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.
A group member MUST NOT process an SID Download Type KD payload GROUPKEY-PUSH message may include Data-Security SAs that are
present in a GROUPKEY-PUSH message. distributed to the group member for the first time. An SID
previously issued to the receiving group member is used with counter-
based mode of operation Data-Security SAs on which the group member
acts as a sender. Because this Data-Security SA has not previously
been used for transmittion, the SSIV field should be set to its
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, an 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
skipping to change at page 44, line 22 skipping to change at page 43, line 41
The Sequence Number Payload fields are defined as follows: The Sequence Number Payload fields are defined as follows:
o Next Payload (1 octet) -- Identifier for the payload type of the o Next Payload (1 octet) -- Identifier for the payload type of the
next payload in the message. If the current payload is the last in next payload in the message. If the current payload is the last in
the message, then this field will be zero. the message, then this field will be zero.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Payload Length (2 octets) -- Length in octets of the current o Payload Length (2 octets) -- Length in octets of the current
payload, including the generic payload header. 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 by
the GCKS, and incremented in each subsequently-transmitted message. the GCKS, and incremented in each subsequently-transmitted message.
Thus the first packet sent for a given Rekey SA will have a Sequence Thus the first packet sent for a given Rekey SA will have a Sequence
Number of 1. The GDOI implementation keeps a sequence counter as an Number of 1. The GDOI implementation keeps a sequence counter as an
attribute for the Rekey SA and increments the counter upon receipt of attribute for the Rekey SA and increments the counter upon receipt of
a GROUPKEY-PUSH message. The current value of the sequence number a GROUPKEY-PUSH message. The current value of the sequence number
must be transmitted to group members as a part of the Registration SA MUST be transmitted to group members as a part of the Registration SA
payload. A group member must keep a sliding receive window. The payload.
window must be treated as in the ESP protocol [RFC4303] Section
3.4.3.
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 bytes. in the HASHs) MUST be a value between 8 and 128 bytes.
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
skipping to change at page 45, line 13 skipping to change at page 44, line 31
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 zero
MUST be used as the protocol id. Note that only one protocol id MUST be used as the protocol id. Note that only one protocol id
value can be defined in a Delete payload. If a TEK SA and a KEK SA value can be defined in a Delete payload. Thus, if a TEK SA and a
must be deleted, they must be sent in different Delete payloads. KEK SA are to be deleted, their SPI values MUST be sent in 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 a 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 a spi of zero and a protocol_id of a TEK
protocol_id value, followed by another delete payload with a spi of protocol_id value, followed by another delete payload with a spi of
zero and protocol_id of zero, indicating that the KEK SA should be zero and protocol_id of zero, indicating that the KEK SA should be
skipping to change at page 52, line 30 skipping to change at page 51, line 30
digital signatures is justified by the need to prevent GCKS digital signatures is justified by the need to prevent GCKS
impersonation: If a shared symmetric key were used for GROUPKEY-PUSH impersonation: If a shared symmetric key were used for GROUPKEY-PUSH
message authentication, then GCKS source authentication would be message authentication, then GCKS source authentication would be
impossible and any member would be capable of GCKS impersonation. impossible and any member 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 denial of service
attack is mitigated by the order of operations a group member takes, attack is mitigated by the order of operations a group member takes,
where the least expensive cryptographic operation is performed first. where the least expensive cryptographic operation is performed first.
The group member first decrypts the message using a symmetric cipher. The group member first decrypts the message using a symmetric cipher.
If it is a validly formed message then the sequence number is checked If it is a validly formed message then the sequence number is checked
against the replay window. Only if the sequence number is valid is against the most recently recieved sequence number. Only when the
the digital signature verified. Thus in order for a denial of sequence number is valid (i.e., it is a larger value than previously
service attack to be mounted, an attacker would need to know both the received) is the digital signature verified and the message further
symmetric encryption key used for confidentiality, and a valid processed. Thus in order for a denial of service attack to be
sequence number. Generally speaking this means only current group mounted, an attacker would need to know both the symmetric encryption
members can effectively deploy a denial of service attack. key used for confidentiality, and a valid sequence number. Generally
speaking this means only current group members can effectively deploy
a denial of service 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"
skipping to change at page 55, line 7 skipping to change at page 54, line 7
wise connection, and there is no requirement in The Multicast Group wise connection, and there is no requirement in The Multicast Group
Security Architecture [RFC3740] for group members to permute group Security Architecture [RFC3740] for group members to permute group
keying material. Because the GCKS is solely responsible for the keying material. Because the GCKS is solely responsible for the
generation of the keying material, the GCKS MUST derive the keying generation of the keying material, the GCKS MUST derive the keying
material using a strong random number generator. Because there are material using a strong random number generator. Because there are
no interoperability concerns with key generation, no method is no interoperability concerns with key generation, no method is
prescribed in GDOI. prescribed in GDOI.
8. IANA Considerations 8. IANA Considerations
This memo requests IANA to make several additions to existing
registries, and to add sever new GDOI registries. When the new
registries are added, the following terms are to be applied as
described in the Guidelines for Writing an IANA Considerations
Section in RFCs [RFC5226]: Standards Action, and Private Use.
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] should be
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 [FIPS.180-2.2002]. The new algorithm names should be defined in [FIPS180-3.2008]. The new algorithm names should be
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 TBD-2, TBD-3, and TBD-4 respectively.
The GDOI KEK Attributed named SIG_ALGORITHM [GDOI-REG] should be The GDOI KEK Attributed named SIG_ALGORITHM [GDOI-REG] should be
assigned a new Algorithm Type value from the RESERVED space to assigned several new Algorithm Type values from the RESERVED space to
represent the RSA PSS encoding type. The new algorithm name should represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and
be SIG_ALG_RSA_PSS, and has the value of TBD-6. SIG_ALG_ECDSA-521 signature algorithms. The Algorithm Types values
should be TBD-7, TBD-8, and TBD-9 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] should be assigned
from the RESERVED space. The new algorithm id should be called from the RESERVED space. The new algorithm id should be called
GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a
value of TBD-5. value of TBD-5.
A new Next Payload Type [ISAKMP-REG] should be assigned. The new A new Next Payload Type [ISAKMP-REG] should be assigned. The new
type is called "SA Group Associated Policy (GAP)", and has a value of type is called "SA Group Associated Policy (GAP)", and has a value of
TBD-1. TBD-1.
A new Key Download Type Section 5.6 should be assigned. The new type A new Key Download Type Section 5.6 should be assigned. The new type
is called "SID", and has a value of TBD-7. is called "SID", and has a value of TBD-6.
8.2. New registries 8.2. New registries
A new namespace should be created in the GDOI Payloads registry A new registry identifying the possible values of GAP Payload Policy
[GDOI-REG] to describe SA GAP Payload Values. The following rules Attributes (of the form described in Section 3.3 of [RFC2408]) should
apply to define the attributes in SA SSA Payload Values: be created in the GDOI Payloads [GDOI-REG]. This memo 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 Standards Action 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
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 is needed. The attribute class is
called "Address Preservation", and it is a Basic type. The following called "Address Preservation", and it is a Basic type. The following
rules apply to define the values of the attribute: rules apply to define the values of the attribute:
Name Value Name Value
---- ----- ---- -----
Reserved 0 Reserved 0
None 1 None 1
Source-Only 2 Source-Only 2
Destination-Only 3 Destination-Only 3
Source-And-Destination 4 Source-And-Destination 4
Standards Action 5-61439 Standards Action 5-61439
Private Use 61440-65535 Private Use 61440-65535
The terms Standards 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 is needed. 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 Standards Action 4-61439
Private Use 61440-65535 Private Use 61440-65535
The terms Standards 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 Standards Action 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
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. following sections correct these registries. The terms Standards
Action, Unassigned, and Private Use are to be applied as defined in
[RFC5226].
8.3.1. Pop Algorithm 8.3.1. Pop Algorithm
Values 4-127 are to be designated Standards Action. Values 256-32767 Values 4-127 are to be designated Standards Action. Values 256-32767
are to be added and designated Unassigned. are to be added and designated Unassigned.
8.3.2. KEK Attributes 8.3.2. KEK Attributes
Values 9-127 are to added and designated Standards Action. Values Values 9-127 are to added and designated Standards Action. Values
128-255 are to be added and designated Private Use. Values 256-32767 128-255 are to be added and designated Private Use. Values 256-32767
skipping to change at page 59, line 13 skipping to change at page 58, line 13
are to be added and designated Unassigned. are to be added and designated Unassigned.
9. Acknowledgements 9. Acknowledgements
This text updates RFC 3547, and the authors wish to thank Mark This text updates 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 updated version of GDOI. this updated version of GDOI.
The authors are grateful to Catherine Meadows for her careful review The authors are grateful to Catherine Meadows for her careful review
and suggestions for mitigating the man-in-the-middle attack she had and suggestions for mitigating the man-in-the-middle attack she had
previously identified. Yoav Nir and Vincent Roca provided many previously identified. Yoav Nir, Vincent Roca, and Sean Turner
useful technical and editorial comments and suggestions for provided many useful technical and editorial comments and suggestions
improvement. 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
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
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
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
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
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
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
[FIPS.180-2.2002] [FIPS180-3.2008]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-3, October 2008, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>.
[FIPS186-3] [FIPS186-3]
"Digital Signature Standard (DSS)", United States of "Digital Signature Standard (DSS)", United States of
America, National Institute of Science and America, National Institute of Science and
Technology Federal Information Processing Standard (FIPS) Technology Federal Information Processing Standard (FIPS)
186-2, June 2009. 186-2, June 2009.
[FIPS197] "Advanced Encryption Standard (AES)", United States of [FIPS197] "Advanced Encryption Standard (AES)", 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 (FIPS)
skipping to change at page 61, line 20 skipping to change at page 61, line 7
[GDOI-REG] [GDOI-REG]
Internet Assigned Numbers Authority, "Group Domain of Internet Assigned Numbers Authority, "Group Domain of
Interpretation (GDOI) Payload Type Values", IANA Registry, Interpretation (GDOI) Payload Type Values", IANA Registry,
December 2004, December 2004,
<http://www.iana.org/assignments/gdoi-payloads>. <http://www.iana.org/assignments/gdoi-payloads>.
[HD03] Hardjono, T. and L. Dondeti, "Multicast and Group [HD03] Hardjono, T. and L. Dondeti, "Multicast and Group
Security", Artech House Computer Security Series, ISBN Security", Artech House Computer Security Series, ISBN
1-58053-342-6, 2003. 1-58053-342-6, 2003.
[I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-02
(work in progress), March 2011.
[ISAKMP-REG] [ISAKMP-REG]
"'Magic Numbers' for ISAKMP Protocol", "'Magic Numbers' for ISAKMP Protocol",
<http://www.iana.org/assignments/isakmp-registry>. <http://www.iana.org/assignments/isakmp-registry>.
[MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and [MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and
Defending the GDOI Protocol", ESORICS 2004 pp. 53-72, Defending the GDOI Protocol", ESORICS 2004 pp. 53-72,
September 2004. September 2004.
[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receivers", Advances in Tracing Schemes for Stateless Receivers", Advances in
skipping to change at page 61, line 49 skipping to change at page 61, line 31
[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript, Dynamic Groups Using One-Way Function Trees", Manuscript,
submitted to IEEE Transactions on Software Engineering, submitted to IEEE Transactions on Software Engineering,
1998, <http://download.nai.com/products/media/nai/misc/ 1998, <http://download.nai.com/products/media/nai/misc/
oft052098.ps>. oft052098.ps>.
[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", WET-ICE conference , 2001,
<http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>. <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[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.
skipping to change at page 63, line 16 skipping to change at page 62, line 18
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005. RFC 4309, December 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within [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.
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)",
RFC 4430, March 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006. May 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [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.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
June 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
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 of Lengths", United States of America, National Institute of
Science and Technology DRAFT NIST Special Publication 800- Science and Technology DRAFT NIST Special Publication 800-
131, June 2010. 131, June 2010.
[SP.800-38A] [SP.800-38A]
Dworkin, M., "Recommendation for Block Cipher Modes of Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", United States of America, National Institute Operation", United States of America, National Institute
of Science and Technology NIST Special Publication 800-38A of Science and Technology NIST Special Publication 800-38A
2001 Edition, December 2001. 2001 Edition, December 2001.
Appendix A. Extending GDOI Appendix A. GDOI Applications
A.1. Alternate GDOI Phase 1 protocols
This section describes a manner in which other protocols could be
used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1
protocol. However, they are not specified as a part of this
document. A separate document MUST be written in order for another
protocol to be used as a GDOI Phase 1 protocol.
Other possible phase 1 protocols are also described in [RFC4046].
Any GDOI phase 1 protocol MUST satisfy the requirements specified in
Section 2 of this document.
A.1.1. IKEv2 Exchange
Version 2 of the IKE protocol (IKEv2) [RFC5996] has been published.
That protocol simplifies IKE processing, and combines the two phases
of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during phase 1,
which was not possible in IKE. However, IKEv2 also defines a phase 2
protocol. The phase 2 protocol is protected by the Phase 1, similar
in concept to how IKE Quick Mode is protected by the IKE Phase 1
protocols in [RFC2409].
It would be possible to define GDOI as a phase 2 protocol protected
by an IKEv2 initial exchange. Alternatively, it would be possible to
define a new protocol re-using some of the IKEv2 initial exchange
(e.g., IKE_SA_INIT).
A.1.2. KINK Protocol
The Kerberized Internet Negotiation of Keys (KINK) [RFC4430] has
defined a method of encapsulating an IKEv1 Quick Mode [RFC2409]
encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK
provides a low-latency, computationally inexpensive, easily managed,
and cryptographically sound method of setting up IPsec security
associations.
The KINK message format includes a DOI field in the KINK header. The
[RFC4430] document defines the DOI for the IPsec DOI.
A new DOI for KINK could be defined which would encapsulate a
GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP
payloads. As such, GDOI would benefit from the computational
efficiencies of KINK.
A.2. Supporting new SA TEK types
Not all secure multicast or multimedia applications can use IPsec ESP
or AH. Many Real Time Transport Protocol applications, for example,
require security above the IP layer to preserve RTP header
compression efficiencies and transport-independence [RFC3550].
Alternatively, GDOI can distribute message authentication code (MAC)
policy and keys for legacy applications that have defined their own
security associations [I-D.weis-gdoi-mac-tek].
In order to add a new data security protocol, a new RFC MUST specify
the data-security SA parameters conveyed by GDOI for that security
protocol; these parameters are listed in Section 5.5.2 of this
document.
Data security protocol SAs MUST protect group traffic. GDOI provides
no restriction on whether that group traffic is transmitted as
unicast or multicast packets.
Appendix B. GDOI Applications
GDOI can be used to distribute keys for several secure multicast 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 example ways that
GDOI can be used. Other examples can be found in Section 10 of 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
skipping to change at page 68, line 5 skipping to change at page 64, line 5
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 GROUPKEY-PUSH exchange delivering a new Rekey SAs protected
by a group management method. Each GROUPKEY-PUSH may include Data- by a group management method. Each GROUPKEY-PUSH may include Data-
security SAs and/or a Rekey SA. 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 depends on each application.
Appendix C. 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
 End of changes. 122 change blocks. 
329 lines changed or deleted 251 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/