draft-ietf-msec-gdoi-update-06.txt   draft-ietf-msec-gdoi-update-07.txt 
MSEC Working Group B. Weis MSEC Working Group B. Weis
Internet-Draft S. Rowles Internet-Draft S. Rowles
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 13, 2011 T. Hardjono Expires: April 28, 2011 T. Hardjono
MIT MIT
July 12, 2010 October 25, 2010
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-06 draft-ietf-msec-gdoi-update-07
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 January 13, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 26 skipping to change at page 2, line 26
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. GDOI Applications . . . . . . . . . . . . . . . . . . . . 6 1.3. GDOI Applications . . . . . . . . . . . . . . . . . . . . 6
1.4. Extending GDOI . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Extending GDOI . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Forward and Backward Access Control . . . . . . . . . . . 7 1.5. Forward and Backward Access Control . . . . . . . . . . . 7
2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 9 2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 9
2.1. ISAKMP Phase 1 protocol . . . . . . . . . . . . . . . . . 9 2.1. ISAKMP Phase 1 protocol . . . . . . . . . . . . . . . . . 9
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 10 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 10
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . . 12 3.3. Initiator Operations . . . . . . . . . . . . . . . . . . . 12
3.4. Receiver Operations . . . . . . . . . . . . . . . . . . . 13 3.4. Receiver Operations . . . . . . . . . . . . . . . . . . . 13
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 15 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 15
4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 16 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 16
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 16 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 16
4.3. Deletion of SAs . . . . . . . . . . . . . . . . . . . . . 16 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 16
4.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 17
4.5. Group Member Operations . . . . . . . . . . . . . . . . . 18
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 18
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 19 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 18
5.2. Security Association Payload . . . . . . . . . . . . . . . 19 5.2. Security Association Payload . . . . . . . . . . . . . . . 18
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 21 5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 26
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 29
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 33
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 42 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 41
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 44 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 43
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 46 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 45
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 47 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 46
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 49 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 48
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. Additions to current registries . . . . . . . . . . . . . 51 8.1. Additions to current registries . . . . . . . . . . . . . 50
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 51 8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 50
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . . 54 10.1. Normative References . . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . . 54 10.2. Informative References . . . . . . . . . . . . . . . . . . 53
Appendix A. Alternate GDOI Phase 1 protocols . . . . . . . . . . 58 Appendix A. Alternate GDOI Phase 1 protocols . . . . . . . . . . 58
A.1. IKEv2 Exchange . . . . . . . . . . . . . . . . . . . . . . 58 A.1. IKEv2 Exchange . . . . . . . . . . . . . . . . . . . . . . 58
A.2. KINK Protocol . . . . . . . . . . . . . . . . . . . . . . 58 A.2. KINK Protocol . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 59 Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
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 and ESP protocols and potentially other data (SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and
security protocols used in group applications. The GDOI uses the potentially other data security protocols used in group applications.
group key management model defined in [RFC4046], and described more The GDOI uses the group key management model defined in [RFC4046],
generally by the The Multicast Group Security Architecture [RFC3740]. and described more generally by the The Multicast Group Security
Architecture [RFC3740].
In this group key management model, the GDOI protocol participants In this group key management model, the GDOI protocol participants
are a "group controller/key server" (GCKS) and a group member (GM). are a "group controller/key server" (GCKS) and a group member (GM).
A group member contacts ("registers with") a GCKS to join the group. A group member contacts ("registers with") a GCKS to join the group.
During the registration mutual authentication and authorization are During the registration mutual authentication and authorization are
achieved, after which the GCKS distributes current group policy and achieved, after which the GCKS distributes current group policy and
keying material to the group member over an authenticated and keying material to the group member over an authenticated and
encrypted session. The GCKS may also initiate contact ("rekeys") encrypted session. The GCKS may also initiate contact ("rekeys")
group members to provide updates to group policy. group members to provide updates to group policy.
skipping to change at page 4, line 49 skipping to change at page 4, line 50
1. The GROUPKEY-PULL registration protocol exchange. This exchange 1. The GROUPKEY-PULL registration protocol exchange. This exchange
uses "pull" behavior since the member initiates the retrieval of uses "pull" behavior since the member initiates the retrieval of
these SAs from a GCKS. It is protected by an ISAKMP phase 1 these SAs from a GCKS. It is protected by an ISAKMP phase 1
protocol, as described above. At the culmination of a GROUPKEY- protocol, as described above. At the culmination of a GROUPKEY-
PULL exchange, an authorized group member has received and PULL exchange, an authorized group member has received and
installed a set of SAs that represent group policy, and it is installed a set of SAs that represent group policy, and it is
ready to participate in secure group communications. ready to participate in secure group communications.
2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is 2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is
a datagram initiated ("pushed") by the GCKS, usually delivered to a datagram initiated ("pushed") by the GCKS, usually delivered to
group members using a IP multicast address. It is treated as a group members using a IP multicast address. The rekey protool is
ISAKMP phase 2 protocol, where the "phase 1" cryptographic policy an ISAKMP protocol, where cryptographic policy and keying
and keying material is included in the group policy distributed material ("Re-key SA") is included in the group policy
by the GCKS in the GROUPKEY-PULL exchange. At the culmination of distributed by the GCKS in the GROUPKEY-PULL exchange. At the
a GROUPKEY-PUSH exchange, all authorized group members have culmination of a GROUPKEY-PUSH exchange the key server has sent
received and installed updates to group policy, and can continue group policy to all authorized group members, allowing receiving
to participate in secure group communications. If a group group members to participate in secure group communications. If
management method is included in group policy (as described in a group management method is included in group policy (as
Section 1.5.1), at the conclusion of the GROUPKEY-PUSH exchange described in Section 1.5.1), at the conclusion of the GROUPKEY-
some members of the group may have been de-authorized and no PUSH exchange some members of the group may have been de-
longer able to participate in the secure group communications. authorized and no longer able to participate in the secure group
communications.
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| | | |
| +--------------------+ | | +--------------------+ |
| +------>| GDOI GCKS |<------+ | | +------>| GDOI GCKS |<------+ |
| | +--------------------+ | | | | +--------------------+ | |
| | | | | | | | | |
| GROUPKEY-PULL | GROUPKEY-PULL | | GROUPKEY-PULL | GROUPKEY-PULL |
| PROTOCOL | PROTOCOL | | PROTOCOL | PROTOCOL |
| | | | | | | | | |
skipping to change at page 5, line 33 skipping to change at page 5, line 35
| | | | | | | | | | | | | |
| | GDOI GM(s) |<-------+-------->| GDOI GM(S) | | | | GDOI GM(s) |<-------+-------->| GDOI GM(S) | |
| | | | | | | | | | | |
| +-----------------+ +-----------------+ | | +-----------------+ +-----------------+ |
| | ^ | | | ^ |
| v | | | v | |
| +-Data Security Protocol (e.g., ESP)-+ | | +-Data Security Protocol (e.g., ESP)-+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Although the GROUPKEY-PUSH specified by this document can be used to Although the GROUPKEY-PUSH protocol specified by this document can be
refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to used to refresh the Re-key SA protecting the GROUPKEY-PUSH protocol,
establish a Data-security SA for a data security protocol. In the most common use of GROUPKEY-PUSH is to establish keying material
summary, GDOI is a group security association management protocol: and policy for a data security protocol.
In summary, GDOI is a group security association management protocol:
All GDOI messages are used to create, maintain, or delete security All GDOI messages are used to create, maintain, or delete security
associations for a group. As described above, these security associations for a group. As described above, these security
associations protect one or more key-encrypting keys, traffic- associations protect one or more data security protocal SAs, a Re-key
encrypting keys, or data shared by group members for multicast and SA, and/or other data shared by group members for multicast and
groups security applications. groups security applications.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The following key terms are used throughout this document. The following key terms are used throughout this document.
Data-Security SA. The security policy distributed by a GDOI GCKS
describing traffic that is expected to be protected by group
members. This document described the distribution of IPsec AH and
ESP Data-Security SAs.
GCKS. A Group Controller/Key Server [RFC3740] that defines group
policy and distributes keys for that policy.
Group Member. An authorized member of a secure group, sending and/or
receiving IP packets related to the group.
GROUPKEY-PULL. A protocol used by a GDOI Group Member to requst
group policy and keying material.
GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates
of group policy and keying material to authorized group members.
Key Encrypting Key (KEK). The symmetric cipher key used to protect Key Encrypting Key (KEK). The symmetric cipher key used to protect
the GROUPKEY-PUSH message. the GROUPKEY-PUSH message.
Logical Key Hierarchy (LKH). A group management method defined in Logical Key Hierarchy (LKH). A group management method defined in
Section 5.4 of [RFC2627]. Section 5.4 of [RFC2627].
Re-key SA. The security policy protecting a GROUPKEY-PUSH protocol.
Traffic Encryption Key (TEK). The symmetric cipher key used to Traffic Encryption Key (TEK). The symmetric cipher key used to
protect a data security protocol (e.g., IPsec ESP). protect a data security protocol (e.g., IPsec ESP).
1.3. GDOI Applications 1.3. GDOI Applications
Secure multicast applications include video broadcast and multicast GDOI can be used to distribute keys for several secure multicast
file transfer. GDOI can also secure group applications that do not applications, where different appliacations have different key
use multicast transport such as video-on-demand where the same management requirements. This section outlines two example ways that
encrypted content is delivered to each group member. GDOI can be used. Other examples can be found in Section 10 of
[HD03].
A GDOI application may require Data-security SAs (such as IPsec ESP A simple application is secure delivery of periodic multicast content
SAs), and/or a Rekey-SA (the SA used to protect GROUPKEY-PUSH over an organization's IP network, perhaps a multicast video
messages). For example, a secure multicast video broadcast may only broadcast. Assuming the content delivery timeframe is bounded and
need to distribute a single set of Data-Security SAs to protect the the group membership is not expected to change over time, there is no
time-bounded broadcast. In this case, no Rekey-SA may be necessary need for group policy to include a GROUPKEY-PUSH exchange, and
because the initial Data-security SAs will not be cryptographically there's no need for the GCKS to distribute a Re-key SA. Thus, the
overused, and there is no desire to de-authorize group members. GDOI GCKS may only need to distribute a single set of Data-Security
SAs to protect the time-bounded broadcast.
In contrast, an always-on IP multicast application (e.g., stock- In contrast, a persistent IP multicast application (e.g., stock-
ticker delivery service) with many group members may require a policy ticker delivery service) may have many group members, where the group
of frequent change of Data-security SAs and regular de-authorization membership changes over time. A periodic change of Data-security SAs
of group members. In this case, the GCKS policy will regularly may be desirable, and the potential for change in group membership
replace Data-security SAs with new SAs defining the same traffic requires the use of a group management method enabling de-
selectors but new keying material. This will result in a regularly- authorization of group members. The GDOI GCKS will distribute the
scheduled GROUPKEY-PUSH delivering the new SAs. Additionally, the current set of Data-Security SAs and a Re-key SA to registering group
members. It will then deliver regularly-scheduled GROUPKEY-PUSH
protocol delivering the new SAs for the group. Additionally, the
group membership on the GCKS may be frequently adjusted, which will 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. In all cases, the relevant policy is security SAs and/or a Rekey SA.
defined on the GCKS and relayed to group members. Specific policy
choices possible by the GCKS depends on each application and further In each example the relevant policy is defined on the GCKS and
discussion of policy is beyond the scope of this memo. relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH
protocols. Specific policy choices configured by the GCKS
administrator depends on each application.
1.4. Extending GDOI 1.4. Extending GDOI
Not all secure multicast or multimedia applications can use IPsec ESP Not all secure multicast or multimedia applications can use IPsec ESP
or AH. Many Real Time Transport Protocol applications, for example, or AH. Many Real Time Transport Protocol applications, for example,
require security above the IP layer to preserve RTP header require security above the IP layer to preserve RTP header
compression efficiencies and transport-independence [RFC3550]. A compression efficiencies and transport-independence [RFC3550].
future RTP security protocol may benefit from using GDOI to establish Alternatively, GDOI can distribute message authentication code (MAC)
group SAs. Alternatively, GDOI can distribute message authentication policy and keys for legacy applications that have defined their own
code (MAC) policy and keys for legacy applications that have defined security associations [I-D.weis-gdoi-mac-tek].
their own security associations [I-D.weis-gdoi-mac-tek].
In order to add a new data security protocol, a new RFC MUST specify 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 the data-security SA parameters conveyed by GDOI for that security
protocol; these parameters are listed in Section 5.5.2 of this protocol; these parameters are listed in Section 5.5.2 of this
document. document.
Data security protocol SAs MUST protect group traffic. GDOI provides Data security protocol SAs MUST protect group traffic. GDOI provides
no restriction on whether that group traffic is transmitted as no restriction on whether that group traffic is transmitted as
unicast or multicast packets. unicast or multicast packets.
skipping to change at page 10, line 18 skipping to change at page 10, line 18
and/or Data-security SAs at the member for a particular group. A and/or Data-security SAs at the member for a particular group. A
Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple
GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL
exchange downloads the data security keys (TEKs) and/or group key exchange downloads the data security keys (TEKs) and/or group key
encrypting key (KEK) or KEK array under the protection of the Phase 1 encrypting key (KEK) or KEK array under the protection of the Phase 1
SA. SA.
3.1. Authorization 3.1. Authorization
The Phase 1 identity SHOULD be used by a GCKS to authorize the Phase The Phase 1 identity SHOULD be used by a GCKS to authorize the Phase
2 (GROUPKEY-PULL) request for a group key. Similarly, a group member 2 (GROUPKEY-PULL) request for a group key. A group member MUST
SHOULD ensure that the Phase 1 identity of the GCKS is an authorized ensure that the Phase 1 identity of the GCKS is an authorized GCKS.
GCKS. When no authorization is performed, it is possible for a rogue When no authorization is performed, it is possible for a rogue GDOI
GDOI participant to perpetrate a man-in-the-middle attack between a participant to perpetrate a man-in-the-middle attack between a group
group member and a GCKS [MP04]. member and a GCKS [MP04].
3.2. Messages 3.2. Messages
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a
which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH
payloads. When using the Phase 1 defined in this document, SKEYID_a payloads. When using the Phase 1 defined in this document, SKEYID_a
is derived according to [RFC2409]. As with the IKEv1 HASH payload is derived according to [RFC2409]. As with the IKEv1 HASH payload
generation (Section 5.5 of [RFC2409], each GROUPKEY-PULL message generation (Section 5.5 of [RFC2409], each GROUPKEY-PULL message
hashes a uniquely defined set of values. Nonces permute the HASH and hashes a uniquely defined set of values. Nonces permute the HASH and
provide some protection against replay attacks. Replay protection is provide some protection against replay attacks. Replay protection is
skipping to change at page 15, line 20 skipping to change at page 15, line 20
multicast is not possible. The GROUPKEY-PUSH message replaces a Re- multicast is not possible. The GROUPKEY-PUSH message replaces a Re-
key SA KEK or KEK array, and/or creates a new Data-security SA. key SA KEK or KEK array, and/or creates a new Data-security SA.
Member GCKS or Delegate Member GCKS or Delegate
------ ---------------- ------ ----------------
<---- HDR*, SEQ, [D,] SA, KD, SIG <---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Re-key SA KEK; encryption occurs after HDR * Protected by the Re-key SA KEK; encryption occurs after HDR
HDR is defined below. The SEQ payload is defined in the Payloads HDR is defined below. The SEQ payload is defined in the Payloads
section. One or more D (Delete) payloads optionally specify the section. One or more D (Delete) payloads (further described in
deletion of existing group policy. The SA defines the policy (e.g., Section 5.9) optionally specify the deletion of existing group
protection suite) and attributes (e.g., SPI) for a replacement Re-key policy. The SA defines the policy (e.g., protection suite) and
SA and/or Data-security SAs. KD is the key download payload as attributes (e.g., SPI) for a replacement Re-key SA and/or Data-
described in the Payloads section. security SAs. KD is the key download payload as described in the
Payloads section.
The SIG payload includes a signature of a hash of the entire The SIG payload includes a signature of a hash of the entire
GROUPKEY-PUSH message (excepting the SIG payload bytes) before it has GROUPKEY-PUSH message (excepting the SIG payload bytes) before it has
been encrypted. The HASH is taken over the string 'rekey', the been encrypted. The HASH is taken over the string 'rekey', the
GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG
payload. The prefixed string ensures that the signature of the Rekey payload. The prefixed string ensures that the signature of the Rekey
datagram cannot be used for any other purpose in the GDOI protocol. datagram cannot be used for any other purpose in the GDOI protocol.
After the SIG payload is created using the signature of the above After the SIG payload is created using the signature of the above
hash, with the receiver verifying the signature using a public key hash, with the receiver verifying the signature using a public key
retrieved in policy received by a GROUPKEY-PULL exchange, or retrieved in policy received by a GROUPKEY-PULL exchange, or
distributed in an earlier GROUPKEY-PUSH message. The current KEK distributed in an earlier GROUPKEY-PUSH message. The current KEK
encryption key (previously distributed in a GROUPKEY-PULL exchange or encryption key (previously distributed in a GROUPKEY-PULL exchange or
GROUPKEY-PUSH message) encrypts all the payloads following the GROUPKEY-PUSH message) encrypts all the payloads following the
GROUPKEY-PUSH HDR. Note: The rationale for this order of operations GROUPKEY-PUSH HDR. Note: The rationale for this order of operations
is given in Section 7.3.5. is given in Section 7.3.5.
If the SA defines an LKH KEK array or single KEK, KD contains a KEK If the SA defines the use of a single KEK or an LKH KEK array, KD
or KEK array for a new Re-key SA, which has a new cookie pair. When MUST contain a corresponding KEK or KEK array for a new Re-key SA,
the KD payload carries a new SA KEK attribute (section 5.3), a Re-key which has a new cookie pair. When the KD payload carries a new SA
SA is replaced with a new SA having the same group identifier (ID KEK attribute (section 5.3), a Re-key SA is replaced with a new SA
specified in message 1 of section 3.2) and incrementing the same having the same group identifier (ID specified in message 1 of
sequence counter, which is initialized in message 4 of section 3.2. section 3.2) and incrementing the same sequence counter, which is
Note the first packet for the given Rekey SA encrypted with the new initialized in message 4 of section 3.2. Note the first packet for
KEK attribute will have a Sequence number of 1. If the SA defines an the given Rekey SA encrypted with the new KEK attribute will have a
SA TEK payload, this informs the member that a new Data-security SA Sequence number of 1. If the SA defines an SA TEK payload, this
has been created, with keying material carried in KD (Section 5.6). informs the member that a new Data-security SA has been created, with
keying material carried in KD (Section 5.6).
If the SA defines a large LKH KEK array (e.g., during group If the SA defines a large LKH KEK array (e.g., during group
initialization and batched rekeying), parts of the array MAY be sent initialization and batched rekeying), parts of the array MAY be sent
in different unique GROUPKEY-PUSH datagrams. However, each of the in different unique GROUPKEY-PUSH datagrams. However, each of the
GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH
datagram. This results in each datagram containing a sequence number datagram. This results in each datagram containing a sequence number
and the policy in the SA payload, which corresponds to the KEK array and the policy in the SA payload, which corresponds to the KEK array
portion sent in the KD payload. portion sent in the KD payload.
4.1. Use of signature keys 4.1. Use of signature keys
In order to avoid overusing its authentication signature key, the A signing key should not be used in more than one context (e.g., used
GCKS SHOULD NOT use the same key to sign the SIG payload in the for host authentication and also for message authentication). Thus,
the GCKS SHOULD NOT use the same key to sign the SIG payload in the
GROUPKEY-PUSH message as was used for authentication in the GROUPKEY- GROUPKEY-PUSH message as was used for authentication in the GROUPKEY-
PULL exchange. PULL exchange.
4.2. ISAKMP Header Initialization 4.2. ISAKMP Header Initialization
Unlike ISAKMP or IKEv1, the cookie pair is completely determined by Unlike ISAKMP or IKEv1, the cookie pair is completely determined by
the GCKS. The cookie pair in the GDOI ISAKMP header identifies the the GCKS. The cookie pair in the GDOI ISAKMP header identifies the
Re- key SA to differentiate the secure groups managed by a GCKS. Re- key SA to differentiate the secure groups managed by a GCKS.
Thus, GDOI uses the cookie fields as an SPI. Thus, GDOI uses the cookie fields as an SPI.
skipping to change at page 16, line 39 skipping to change at page 16, line 42
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Flags MUST have the Encryption bit set according to [RFC2008, Section Flags MUST have the Encryption bit set according to [RFC2008, Section
3.1]. All other bits MUST be set to zero. 3.1]. All other bits MUST be set to zero.
Message ID MUST be set to zero. Message ID MUST be set to zero.
Length is according to ISAKMP (Section 3.1 of [RFC2408]). Length is according to ISAKMP (Section 3.1 of [RFC2408]).
4.3. Deletion of SAs 4.3. GCKS Operations
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
accomplished by sending an ISAKMP Delete payload (Section 3.15 of
[RFC2408]) as part of a GDOI GROUPKEY-PUSH message.
One or more Delete payloads MAY be placed following the SEQ payload
in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to
group members, the SA and KD payloads MUST be omitted from the
message.
The following fields of the Delete Payload are further defined as
follows:
o The Domain of Interpretation field contains the GDOI DOI.
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
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
must be deleted, they must be sent in different Delete payloads.
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
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
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
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
zero and protocol_id of zero, indicating that the KEK SA should be
deleted.
4.4. GCKS Operations
GCKS or its delegate may initiate a Rekey message for one of several GCKS or its delegate may initiate a Rekey message for one of several
reasons, e.g., the group membership has changed or keys are due to reasons, e.g., the group membership has changed or keys are due to
expire. expire.
To begin the rekey datagram the GCKS builds an ISAKMP HDR with the To begin the rekey datagram the GCKS builds an ISAKMP HDR with the
correct cookie pair, and a SEQ payload that includes a sequence correct cookie pair, and a SEQ payload that includes a sequence
number which is one greater than the previous rekey datagram. If the number which is one greater than the previous rekey datagram. If the
message is using the new KEK attribute for the first time, the SEQ is message is using the new KEK attribute for the first time, the SEQ is
reset to 1 in this message. reset to 1 in this message.
skipping to change at page 18, line 13 skipping to change at page 17, line 29
(see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent (see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent
for each SA_TEK attribute included in the SA payload. for each SA_TEK attribute included in the SA payload.
In the penultimate step, the initiator hashes the string "rekey" In the penultimate step, the initiator hashes the string "rekey"
followed by the key management message already formed. The hash is followed by the key management message already formed. The hash is
signed, placed in a SIG payload and added to the datagram. signed, placed in a SIG payload and added to the datagram.
Lastly, the payloads following the HDR are encrypted using the Lastly, the payloads following the HDR are encrypted using the
current KEK encryption key. The datagram can now be sent. current KEK encryption key. The datagram can now be sent.
4.5. Group Member Operations 4.4. Group Member Operations
A group member receiving the GROUPKEY-PUSH datagram matches the A group member receiving the GROUPKEY-PUSH datagram matches the
cookie pair in the ISAKMP HDR to an existing SA. The message is cookie pair in the ISAKMP HDR to an existing SA. The message is
decrypted, and the form of the datagram is validated. This weeds out decrypted, and the form of the datagram is validated. This weeds out
obvious ill-formed messages (which may be sent as part of a Denial of obvious ill-formed messages (which may be sent as part of a Denial of
Service attack on the group). Service attack on the group).
The sequence number in the SEQ payload is validated to ensure that it The sequence number in the SEQ payload is validated to ensure that it
is greater than the previously received sequence number, and that it is greater than the previously received sequence number, and that it
fits within a window of acceptable values. The SIG payload is then fits within a window of acceptable values. The SIG payload is then
skipping to change at page 24, line 8 skipping to change at page 23, line 8
KEK Management Type Value KEK Management Type Value
------------------- ----- ------------------- -----
RESERVED 0 RESERVED 0
LKH 1 LKH 1
RESERVED 2-127 RESERVED 2-127
Private Use 128-255 Private Use 128-255
5.3.2.1. LKH 5.3.2.1. LKH
This type indicates the group management method described in Section This type indicates the group management method described in Section
5.4 of [RFC2627]. 5.4 of [RFC2627]. A general discussion of LKH operations can also be
found in Section 6.3 of Multicast and Group Security [HD03]
5.3.3. KEK_ALGORITHM 5.3.3. KEK_ALGORITHM
The KEK_ALGORITHM class specifies the encryption algorithm using with The KEK_ALGORITHM class specifies the encryption algorithm using with
the KEK. Defined values are specified in the following table. An the KEK. Defined values are specified in the following table. An
GDOI implementation MUST abort if it encounters and attribute or GDOI implementation MUST abort if it encounters an attribute or
capability that it does not understand. capability that it does not understand.
Algorithm Type Value Algorithm Type Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
KEK_ALG_DES 1 KEK_ALG_DES 1
KEK_ALG_3DES 2 KEK_ALG_3DES 2
KEK_ALG_AES 3 KEK_ALG_AES 3
RESERVED 4-127 RESERVED 4-127
Private Use 128-255 Private Use 128-255
skipping to change at page 25, line 8 skipping to change at page 24, line 13
[SP.800-38A]. [SP.800-38A].
5.3.4. KEK_KEY_LENGTH 5.3.4. KEK_KEY_LENGTH
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in
bits). The Group Controller/Key Server (GCKS) adds the KEK_KEY_LEN bits). The Group Controller/Key Server (GCKS) adds the KEK_KEY_LEN
attribute to the SA payload when distributing KEK policy to group attribute to the SA payload when distributing KEK policy to group
members. The group member verifies whether or not it has the members. The group member verifies whether or not it has the
capability of using a cipher key of that size. If the cipher 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 KEK_ALGORITHM group member can make its decision solely using the KEK_ALGORITHM
attribute and does not need the KEK_KEY_LEN attribute. Sending the attribute and does not need the KEK_KEY_LEN attribute. Sending the
KEK_KEY_LEN attribute in the SA payload is OPTIONAL if the KEK cipher KEK_KEY_LEN attribute in the SA payload is OPTIONAL if the KEK cipher
has a fixed key length. Also, note that the KEK_KEY_LEN includes 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 not only the actual length of the cipher key (the IV length is not
included in this attribute). included in this attribute).
5.3.5. KEK_KEY_LIFETIME 5.3.5. KEK_KEY_LIFETIME
The KEK_KEY_LIFETIME class specifies the maximum time for which the The KEK_KEY_LIFETIME class specifies the maximum time for which the
KEK is valid. The GCKS may refresh the KEK at any time before the KEK is valid. The GCKS may refresh the KEK at any time before the
skipping to change at page 28, line 16 skipping to change at page 27, line 21
attributes following the format defined in Section 3.3 of RFC attributes following the format defined in Section 3.3 of RFC
2408. 2408.
Several group associated policy attributes are defined in this memo. Several group associated policy attributes are defined in this memo.
An GDOI implementation MUST abort if it encounters and attribute or An GDOI implementation MUST abort if it encounters and attribute or
capability that it does not understand. capability that it does not understand.
5.4.1. ACTIVATION_TIME_DELAY 5.4.1. ACTIVATION_TIME_DELAY
This attribute allows a GCKS to set the Activation Time Delay for SAs This attribute allows a GCKS to set the Activation Time Delay for SAs
generated from TEKs. The value is in seconds. If a group member generated from TEKs. The value is in seconds.
receives a TEK with an ATD value, but discovers that it has no
current SAs matching the policy in the TEK, then it SHOULD create and
install SAs from the TEK immediately.
5.4.2. DEACTIVATION_TIME_DELAY 5.4.2. DEACTIVATION_TIME_DELAY
This attribute allows a GCKS to set the Deactivation Time Delay for This attribute allows a GCKS to set the Deactivation Time Delay for
SAs generated from TEKs. The value is in seconds. SAs generated from TEKs. The value is in seconds. The values of
Activation Time Delay and Deactivation Time Delay are independant.
However, the Deactivation Time Delay vaue should be larger, which
allows new SAs to be activated before older SAs are deactivated.
Such a policy ensures that protected group traffic will always flow
without interruption.
5.4.3. SENDER_ID 5.4.3. SENDER_ID
Several new AES counter-based modes of operation have been specified Several new AES counter-based modes of operation have been specified
for ESP [RFC3686],[RFC4106],[RFC4309],[RFC4543] and AH [RFC4543]. for ESP [RFC3686],[RFC4106],[RFC4309],[RFC4543] and AH [RFC4543].
These AES counter-based modes require that no two senders in the These AES counter-based modes require that no two senders in the
group ever send a packet with the same IV. This requirement can be group ever send a packet with the same IV. This requirement is met
met using the method described in using the method described in
[I-D.ietf-msec-ipsec-group-counter-modes], which requires each sender [I-D.ietf-msec-ipsec-group-counter-modes], which requires each sender
to be allocated a unique Sender ID (SID). The SENDER_ID attribute is to be allocated a unique Sender ID (SID). The SENDER_ID attribute is
used to distribute a SID to a group member during the GROUPKEY-PULL used to distribute an SID to a group member during the GROUPKEY-PULL
message. Other algorithms with the same need may be defined in the message. Other algorithms with the same need may be defined in the
future; the sender MUST use the IV construction method described future; the sender MUST use the IV construction method described
above with those algorithms as well. above with those algorithms as well.
The SENDER_ID attribute value contains the following fields. The SENDER_ID attribute value contains the following fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SID Length ! SID Value ~ ! SID Length ! SID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o SID Length (1 octet) -- A natural number defining the number of o SID Length (1 octet) -- A natural number defining the number of
bits to be used in the SID field of the counter mode transform bits to be used in the SID field of the counter mode transform
nonce. nonce. The length of the SID is chosen by the GCKS administrator
based on the counter-based mode specification and the number of
expected group members. In accordance with
[I-D.ietf-msec-ipsec-group-counter-modes] an implementation MUST
support values of 8, 12, and 16.
o SID Value (variable) -- The Sender ID value allocated to the group o SID Value (variable) -- The Sender ID value allocated to the group
member. member.
5.4.3.1. GCKS Semantics 5.4.3.1. GCKS Semantics
The GCKS maintains a SID counter (SIDC). It is incremented each time The GCKS maintains a SID counter (SIDC). It is incremented each time
a SENDER_ID attribute is distributed to a group member. The first a SENDER_ID attribute is distributed to a group member. The first
group member to register is given the SID of 1. group member to register is given the SID of 1.
skipping to change at page 29, line 25 skipping to change at page 28, line 39
allows group members to act as a group sender when an older SID value allows group members to act as a group sender when an older SID value
becomes unusable (as described in the next section). becomes unusable (as described in the next section).
A GCKS MAY allocate multiple SID values in one SA GAP payload. A GCKS MAY allocate multiple SID values in one SA GAP payload.
Allocating several SID values at the same time to a group member Allocating several SID values at the same time to a group member
expected to send at a high rate would obviate the need for the group expected to send at a high rate would obviate the need for the group
member to re-register as frequently. member to re-register as frequently.
If a GCKS allocates all SID values, it can no longer respond to GDOI If a GCKS allocates all SID values, it can no longer respond to GDOI
registrations and must re-initialize the entire group. This is done registrations and must re-initialize the entire group. This is done
by issuing DELETE notifications for all ESP and AH SAs in a GDOI by including Delete Payload for all ESP and AH SAs in a GDOI rekey
rekey message, resetting the SIDC to zero, and creating new ESP and message, resetting the SIDC to zero, and creating new ESP and AH SAs
AH SAs that match the group policy. When group members re-register, that match the group policy. When group members re-register, the
the SIDs are allocated again beginning with the value 1 as described SIDs are allocated again beginning with the value 1 as described
above. Each re-registering group member will be given a new SID and above. Each re-registering group member will be given a new SID and
the new group policy. the new group policy.
The SENDER_ID attribute MUST NOT be sent as part of a GROUPKEY-PUSH The SENDER_ID attribute MUST NOT be sent as part of a GROUPKEY-PUSH
message, because distributing the same sender-specific policy to more message, because distributing the same sender-specific policy to more
than one group member may reduce the security of the group. than one group member may reduce the security of the group.
5.4.3.2. Group Member Semantics 5.4.3.2. Group Member Semantics
The SENDER_ID attribute value distributed to the group member MUST be The SENDER_ID attribute value distributed to the group member MUST be
used by that group member as the Sender Identifier (SID) field used by that group member as the Sender Identifier (SID) field
portion of the IV. The SID is used for all counter mode SAs portion of the IV. The SID is used for all counter mode SAs
distributed by the GCKS to be used for communications sent as a part distributed by the GCKS to be used for communications sent as a part
of this group. of this group.
When the Sender-Specific IV (SSIV) field for any IPsec SA is When the Sender-Specific IV (SSIV) field for any IPsec SA is
exhausted, the group member MUST no longer act as a sender using its exhausted, the group member MUST no longer act as a sender using its
active SID. The group member SHOULD re-register, during which time active SID. The group member SHOULD re-register, during which time
the GCKS will issue a new SID to the group member. The new SID the GCKS will issue a new SID to the group member. The new SID
replaces the existing SID used by this group member, and also resets replaces the existing SID used by this group member, and also resets
the SSIV value to it's starting value. A group member MAY re- the SSIV value to its starting value. A group member MAY re-register
register prior to the actual exhaustion of the SSIV field to avoid prior to the actual exhaustion of the SSIV field to avoid dropping
dropping data packets due to the exhaustion of available SSIV values data packets due to the exhaustion of available SSIV values combined
combined with a particular SID value. with a particular SID value.
A group member MUST NOT process SENDER_ID attribute present in a A group member MUST NOT process a SENDER_ID attribute present in a
GROUPKEY-PUSH message. GROUPKEY-PUSH message.
5.5. SA TEK Payload 5.5. SA TEK Payload
The SA TEK (SAT) payload contains security attributes for a single The SA TEK (SAT) payload contains security attributes for a single
TEK associated with a group. TEK associated with a group.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
skipping to change at page 33, line 4 skipping to change at page 32, line 20
sections describe new GDOI requirements that result from harmonizing sections describe new GDOI requirements that result from harmonizing
with that document. with that document.
5.5.1.1.1. Group Security Policy Database Attributes 5.5.1.1.1. Group Security Policy Database Attributes
RFC 5374 describes new attributes as part of the Group Security RFC 5374 describes new attributes as part of the Group Security
Policy Database (GSPD). These attributes describe policy that a Policy Database (GSPD). These attributes describe policy that a
group key management system must convey to a group member in order to group key management system must convey to a group member in order to
support those extensions. The GDOI SA TEK payload distributes IPsec support those extensions. The GDOI SA TEK payload distributes IPsec
policy using IPsec security association attributes defined in policy using IPsec security association attributes defined in
[ISAKMP-REG]. This section defines how GDOI can convey the new [ISAKMP-REG]. This section defines how GDOI can convey the new
attributes as IPsec Security Association Attributes. attributes as IPsec Security Association Attributes.
5.5.1.1.2. Address Preservation 5.5.1.1.2. Address Preservation
Applications use the extensions in RFC 5374 create encapsulate IPsec Applications use the extensions in RFC 5374 to copy the IP addresses
multicast packets that are IP multicast packets. In order for the into the outer IP header when encapsulating an IP packet as an IPsec
GDOI group member to appropriately setup the GSPD, the GCKS must tunnel mode packet. This allows an IP multicast packet to continue
provide that policy to the group member. to be routed as a IP multiast packet. In order for the GDOI group
member to appropriately set up the GSPD, the GCKS must provide that
policy to the group member.
Depending on group policy, several address preservation methods are Depending on group policy, several address preservation methods are
possible: no address preservation ("None"), preservation of the possible: no address preservation ("None"), preservation of the
original source address ("Source-Only"), preservation of the original original source address ("Source-Only"), preservation of the original
destination address ("Destination-Only"), or both addresses ("Source- destination address ("Destination-Only"), or both addresses ("Source-
And-Destination"). This memo adds the "Address Preservation" And-Destination"). This memo adds the "Address Preservation"
security association attribute. If this attribute is not included in security association attribute. If this attribute is not included in
a GDOI SA TEK payload provided by a GCKS, then Source-And-Destination a GDOI SA TEK payload provided by a GCKS, then Source-And-Destination
address preservation has been defined for the SA TEK. address preservation has been defined for the SA TEK.
skipping to change at page 37, line 6 skipping to change at page 36, line 6
TEK_ALGORITHM_KEY 1 V TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V TEK_SOURCE_AUTH_KEY 3 V
If no TEK key packets are included in a Registration KD payload, the If no TEK key packets are included in a Registration KD payload, the
group member can expect to receive the TEK as part of a Re-key SA. group member can expect to receive the TEK as part of a Re-key SA.
At least one TEK must be included in each Re-key KD payload. At least one TEK must be included in each Re-key KD payload.
Multiple TEKs may be included if multiple streams associated with the Multiple TEKs may be included if multiple streams associated with the
SA are to be rekeyed. SA are to be rekeyed.
When an algorithm specification specifies the format of the keying
material, the value transported in the KD payload for that key is
passed according to that specification. The keying material may
contain information besides a key. For example, The Use of Galois/
Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
[RFC4106] defines a salt value as part of KEYMAT.
5.6.1.1. TEK_ALGORITHM_KEY 5.6.1.1. TEK_ALGORITHM_KEY
The TEK_ALGORITHM_KEY class declares that the encryption key for this The TEK_ALGORITHM_KEY class declares that the encryption key for this
SPI is contained as the Key Packet Attribute. The encryption SPI is contained as the Key Packet Attribute. The encryption
algorithm that will use this key was specified in the SAT payload. algorithm that will use this key was specified in the SAT payload.
In the case that the algorithm requires multiple keys (e.g., 3DES), In the case that the algorithm requires multiple keys (e.g., 3DES),
all keys will be included in one attribute. all keys will be included in one attribute.
DES keys will consist of 64 bits (the 56 key bits with parity bit). DES keys will consist of 64 bits (the 56 key bits with parity bit).
skipping to change at page 44, line 5 skipping to change at page 42, line 10
must be transmitted to group members as a part of the Registration SA must be transmitted to group members as a part of the Registration SA
payload. A group member must keep a sliding receive window. The payload. A group member must keep a sliding receive window. The
window must be treated as in the ESP protocol [RFC4303] Section window must be treated as in the ESP protocol [RFC4303] Section
3.4.3. 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
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
accomplished by sending an ISAKMP Delete payload (Section 3.15 of
[RFC2408]) as part of a GDOI GROUPKEY-PUSH message.
One or more Delete payloads MAY be placed following the SEQ payload
in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to
group members, the SA and KD payloads MUST be omitted from the
message.
The following fields of the Delete Payload are further defined as
follows:
o The Domain of Interpretation field contains the GDOI DOI.
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
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
must be deleted, they must be sent in different Delete payloads.
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
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
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
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
zero and protocol_id of zero, indicating that the KEK SA should be
deleted.
6. Algorithm Selection 6. Algorithm Selection
For GDOI implementations to interoperate, they must support one or For GDOI implementations to interoperate, they must support one or
more security algorithms in common. This section specifies the more security algorithms in common. This section specifies the
security algorithm implementation requirements for standards- security algorithm implementation requirements for standards-
conformant GDOI implementations. In call cases the choices are conformant GDOI implementations. In all cases the choices are
intended to maintain at least 112 bits of security [SP.800-131]. intended to maintain at least 112 bits of security [SP.800-131].
Algorithms not referenced in this section can also be used.
Algorithms not referenced in this section MAY be used.
6.1. KEK 6.1. KEK
These tables list the algorithm selections for values related to the These tables list the algorithm selections for values related to the
KEK. KEK.
Requirement KEK Management Algorithm Requirement KEK Management Algorithm
----------- --------------------- ----------- ---------------------
SHOULD LKH SHOULD LKH
Requirement KEK Algorithm (notes) Requirement KEK Algorithm (notes)
skipping to change at page 54, line 13 skipping to change at page 53, line 13
editorial comments and suggestions for improvement. editorial comments and suggestions for improvement.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-msec-ipsec-group-counter-modes] [I-D.ietf-msec-ipsec-group-counter-modes]
McGrew, D. and B. Weis, "Using Counter Modes with 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", Header (AH) to Protect Group Traffic",
draft-ietf-msec-ipsec-group-counter-modes-05 (work in draft-ietf-msec-ipsec-group-counter-modes-06 (work in
progress), March 2010. progress), September 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
10.2. Informative References 10.2. Informative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
skipping to change at page 55, line 19 skipping to change at page 54, line 19
[FS00] Ferguson, N. and B. Schneier, Counterpane, "A [FS00] Ferguson, N. and B. Schneier, Counterpane, "A
Cryptographic Evaluation of IPsec", Cryptographic Evaluation of IPsec",
<http://www.counterpane.com/ipsec.html>. <http://www.counterpane.com/ipsec.html>.
[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
Security", Artech House Computer Security Series, ISBN
1-58053-342-6, 2003.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-01 Authentication Code Policy", draft-weis-gdoi-mac-tek-01
(work in progress), June 2010. (work in progress), June 2010.
[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
skipping to change at page 57, line 29 skipping to change at page 56, line 35
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 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 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
June 2010. June 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium San Diego, 1996. Distributed Systems Symposium San Diego, 1996.
[SP.800-131] [SP.800-131]
Barker, E. and A. Roginsky, "Recommendation for the Barker, E. and A. Roginsky, "Recommendation for the
Transitioning of Cryptographic Algorithms and Key Transitioning of Cryptographic Algorithms and Key
Lengths", United States of America, National Institute of Lengths", United States of America, National Institute of
Science and Technology DRAFT NIST Special Publication 800- Science and Technology DRAFT NIST Special Publication 800-
131, June 2010. 131, June 2010.
skipping to change at page 58, line 20 skipping to change at page 58, line 20
document. A separate document MUST be written in order for another document. A separate document MUST be written in order for another
protocol to be used as a GDOI Phase 1 protocol. protocol to be used as a GDOI Phase 1 protocol.
Other possible phase 1 protocols are also described in [RFC4046]. Other possible phase 1 protocols are also described in [RFC4046].
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Any GDOI phase 1 protocol MUST satisfy the requirements specified in
Section 2 of this document. Section 2 of this document.
A.1. IKEv2 Exchange A.1. IKEv2 Exchange
Version 2 of the IKE protocol (IKEv2) [RFC4306] has been Version 2 of the IKE protocol (IKEv2) [RFC5996] has been published.
published.That protocol simplifies IKE processing, and combines the That protocol simplifies IKE processing, and combines the two phases
two phases of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during phase 1,
phase 1, which was not possible in IKE. However, IKEv2 also defines which was not possible in IKE. However, IKEv2 also defines a phase 2
a phase 2 protocol. The phase 2 protocol is protected by the Phase protocol. The phase 2 protocol is protected by the Phase 1, similar
1, similar in concept to how IKE Quick Mode is protected by the IKE in concept to how IKE Quick Mode is protected by the IKE Phase 1
Phase 1 protocols in [RFC2409]. protocols in [RFC2409].
It would be possible to define GDOI as a phase 2 protocol protected It would be possible to define GDOI as a phase 2 protocol protected
by an IKEv2 initial exchange. Alternatively, it would be possible to by an IKEv2 initial exchange. Alternatively, it would be possible to
define a new protocol re-using some of the IKEv2 initial exchange define a new protocol re-using some of the IKEv2 initial exchange
(e.g., IKE_SA_INIT). (e.g., IKE_SA_INIT).
A.2. KINK Protocol A.2. KINK Protocol
The Kerberized Internet Negotiation of Keys (KINK) [RFC4430] has The Kerberized Internet Negotiation of Keys (KINK) [RFC4430] has
defined a method of encapsulating an IKEv1 Quick Mode [RFC2409] defined a method of encapsulating an IKEv1 Quick Mode [RFC2409]
skipping to change at page 59, line 45 skipping to change at page 59, line 45
o Supported cryptographic algorithms were changed to meet current o Supported cryptographic algorithms were changed to meet current
guidance. Implementations are required to support AES with 128- guidance. Implementations are required to support AES with 128-
bit keys to encrypt the rekey message, and SHA-256 for bit keys to encrypt the rekey message, and SHA-256 for
cryptographic signatures. The use of DES is deprecated. cryptographic signatures. The use of DES is deprecated.
o New protocol support for AH. o New protocol support for AH.
o New protocol definitions were added to conform to the most recent o New protocol definitions were added to conform to the most recent
Security Architecture for the Internet Protocol [RFC4301] and the Security Architecture for the Internet Protocol [RFC4301] and the
Multicast Extensions to the Security Architecture for the Internet Multicast Extensions to the Security Architecture for the Internet
Protocol[RFC5374]. Protocol[RFC5374]. This includes addition of the GAP payload
o New protocol definitions were added to support Using Counter Modes o New protocol definitions were added to support Using Counter Modes
with ESP and AH to Protect Group with ESP and AH to Protect Group
Traffic[I-D.ietf-msec-ipsec-group-counter-modes]. Traffic[I-D.ietf-msec-ipsec-group-counter-modes].
Authors' Addresses Authors' Addresses
Brian Weis Brian Weis
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
 End of changes. 53 change blocks. 
178 lines changed or deleted 233 lines changed or added

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