draft-ietf-msec-gdoi-update-05.txt   draft-ietf-msec-gdoi-update-06.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: September 9, 2010 March 8, 2010 Expires: January 13, 2011 T. Hardjono
MIT
July 12, 2010
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-05 draft-ietf-msec-gdoi-update-06
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) protocols. GDOI is an ISAMKP Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI
Interpretation (DOI) for group key management to support secure group provides group key management to support secure group communications
communications. The GDOI manages group security associations, which according to the architecture specified in RFC 4046. The GDOI
are used by IPSEC and potentially other data security protocols manages group security associations, which are used by IPsec and
running at the IP or application layers. These security associations potentially other data security protocols.
protect one or more key-encrypting keys, traffic-encrypting keys, or
data shared by group members.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 7 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.2. GDOI Applications . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Extending GDOI . . . . . . . . . . . . . . . . . . . . . . 8 1.3. GDOI Applications . . . . . . . . . . . . . . . . . . . . 6
1.4. Extending GDOI . . . . . . . . . . . . . . . . . . . . . . 6
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
2.1.1. DOI value . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . 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.2.1. ISAKMP Header Initialization . . . . . . . . . . . . . 12
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. Forward and Backward Access Control . . . . . . . . . . . 16 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 16
4.1.1. Forward Access Control Requirements . . . . . . . . . 16 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 16
4.2. Delegation of Key Management . . . . . . . . . . . . . . . 17 4.3. Deletion of SAs . . . . . . . . . . . . . . . . . . . . . 16
4.3. Use of signature keys . . . . . . . . . . . . . . . . . . 17 4.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17
4.4. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17 4.5. Group Member Operations . . . . . . . . . . . . . . . . . 18
4.5. Deletion of SAs . . . . . . . . . . . . . . . . . . . . . 18
4.6. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 18
4.7. Group Member Operations . . . . . . . . . . . . . . . . . 19
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 20
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.2.1. Payloads following the SA payload . . . . . . . . . . 21
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. KEK Attributes . . . . . . . . . . . . . . . . . . . . 24
5.3.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . . . . 24
5.3.3. KEK_ALGORITHM . . . . . . . . . . . . . . . . . . . . 24
5.3.3.1. KEK_ALG_DES . . . . . . . . . . . . . . . . . . . 25
5.3.3.2. KEK_ALG_3DES . . . . . . . . . . . . . . . . . . . 25
5.3.3.3. KEK_ALG_AES . . . . . . . . . . . . . . . . . . . 25
5.3.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . . . . 25
5.3.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . . . . 26
5.3.6. SIG_HASH_ALGORITHM . . . . . . . . . . . . . . . . . . 26
5.3.7. SIG_ALGORITHM . . . . . . . . . . . . . . . . . . . . 26
5.3.7.1. SIG_ALG_RSA . . . . . . . . . . . . . . . . . . . 27
5.3.7.2. SIG_ALG_DSS . . . . . . . . . . . . . . . . . . . 27
5.3.7.3. SIG_ALG_ECDSS . . . . . . . . . . . . . . . . . . 27
5.3.7.4. SIG_ALG_RSA_PSS . . . . . . . . . . . . . . . . . 27
5.3.8. SIG_KEY_LENGTH . . . . . . . . . . . . . . . . . . . . 27 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 19
5.2. Security Association Payload . . . . . . . . . . . . . . . 19
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27
5.4.1. ACTIVATION_TIME_DELAY . . . . . . . . . . . . . . . . 28
5.4.2. DEACTIVATION_TIME_DELAY . . . . . . . . . . . . . . . 28
5.4.3. SENDER_ID . . . . . . . . . . . . . . . . . . . . . . 29
5.4.3.1. GCKS Semantics . . . . . . . . . . . . . . . . . . 29
5.4.3.2. Group Member Semantics . . . . . . . . . . . . . . 30
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1. GDOI_PROTO_IPSEC_ESP/GDOI_PROTO_IPSEC_AH . . . . . . . 31 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.5.1.1. Harmonization with RFC 5374 . . . . . . . . . . . 33
5.5.1.1.1. Group Security Policy Database Attributes . . 33
5.5.1.1.2. Address Preservation . . . . . . . . . . . . . 33
5.5.1.1.3. SA Direction . . . . . . . . . . . . . . . . . 33
5.5.1.1.4. Re-key rollover . . . . . . . . . . . . . . . 34
5.5.2. Other Security Protocols . . . . . . . . . . . . . . . 34
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 35
5.6.1. TEK Download Type . . . . . . . . . . . . . . . . . . 36
5.6.1.1. TEK_ALGORITHM_KEY . . . . . . . . . . . . . . . . 37
5.6.1.2. TEK_INTEGRITY_KEY . . . . . . . . . . . . . . . . 37
5.6.1.3. TEK_SOURCE_AUTH_KEY . . . . . . . . . . . . . . . 37
5.6.2. KEK Download Type . . . . . . . . . . . . . . . . . . 38
5.6.2.1. KEK_ALGORITHM_KEY . . . . . . . . . . . . . . . . 38
5.6.2.2. SIG_ALGORITHM_KEY . . . . . . . . . . . . . . . . 38
5.6.3. LKH Download Type . . . . . . . . . . . . . . . . . . 38
5.6.3.1. LKH_DOWNLOAD_ARRAY . . . . . . . . . . . . . . . . 39
5.6.3.2. LKH_UPDATE_ARRAY . . . . . . . . . . . . . . . . . 41
5.6.3.3. SIG_ALGORITHM_KEY . . . . . . . . . . . . . . . . 42
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 42 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 42
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 44
6.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 44 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.1. Authentication . . . . . . . . . . . . . . . . . . . . 44 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.2. Confidentiality . . . . . . . . . . . . . . . . . . . 45
6.1.3. Man-in-the-Middle Attack Protection . . . . . . . . . 45
6.1.4. Replay/Reflection Attack Protection . . . . . . . . . 45
6.1.5. Denial of Service Protection . . . . . . . . . . . . . 45
6.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 45
6.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 46
6.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 46
6.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 46
6.2.4. Replay/Reflection Attack Protection . . . . . . . . . 46
6.2.5. Denial of Service Protection . . . . . . . . . . . . . 46
6.2.6. Authorization . . . . . . . . . . . . . . . . . . . . 47
6.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 47
6.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 47
6.3.2. Confidentiality . . . . . . . . . . . . . . . . . . . 47
6.3.3. Man-in-the-Middle Attack Protection . . . . . . . . . 47
6.3.4. Replay/Reflection Attack Protection . . . . . . . . . 47
6.3.5. Denial of Service Protection . . . . . . . . . . . . . 48
6.3.6. Forward Access Control . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
7.1. Additions to current registries . . . . . . . . . . . . . 49
7.2. New registries . . . . . . . . . . . . . . . . . . . . . . 49
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.1. Normative References . . . . . . . . . . . . . . . . . . . 52
9.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Alternate GDOI Phase 1 protocols . . . . . . . . . . 56
A.1. IKEv2 Phase 1 protocol . . . . . . . . . . . . . . . . . . 56
A.2. KINK Protocol . . . . . . . . . . . . . . . . . . . . . . 56
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 46
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 47
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 49
1. Introduction 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8.1. Additions to current registries . . . . . . . . . . . . . 51
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 51
This document presents an ISAMKP Domain of Interpretation (DOI) for 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
group key management called the "Group Domain of Interpretation"
(GDOI). In this group key management model, the GDOI protocol is run
between a group member and a "group controller/key server" (GCKS),
which establishes security associations among authorized group
members. ISAKMP defines two "phases" of negotiation (p.16 of
[RFC2408]). The GDOI MUST be protected by a Phase 1 security
association. This document incorporates the Phase 1 security
association (SA) definition from the Internet DOI [RFC2407],
[RFC2409]. Other possible Phase 1 security association types are
noted in Appendix A. The Phase 2 exchange is defined in this
document, and proposes new payloads and exchanges according to the
ISAKMP standard (p. 14 of [RFC2408]).
There are five payloads specific to GDOI: 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . . 54
1) GDOI SA Appendix A. Alternate GDOI Phase 1 protocols . . . . . . . . . . 58
A.1. IKEv2 Exchange . . . . . . . . . . . . . . . . . . . . . . 58
A.2. KINK Protocol . . . . . . . . . . . . . . . . . . . . . . 58
2) SA KEK (SAK) which follows the SA payload Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 59
3) SA TEK (SAT) which follows the SA payload Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
4) Key Download Array (KD) 1. Introduction
5) Sequence number (SEQ) Secure group and multicast applications require a method by which
each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI),
which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group
key management system. The GDOI distributes security associations
(SAs) for IPsec AH and ESP protocols and potentially other data
security protocols used in group applications. The GDOI uses the
group key management model defined in [RFC4046], and described more
generally by the The Multicast Group Security Architecture [RFC3740].
There are two GDOI exchanges. In this group key management model, the GDOI protocol participants
are a "group controller/key server" (GCKS) and a group member (GM).
A group member contacts ("registers with") a GCKS to join the group.
During the registration mutual authentication and authorization are
achieved, after which the GCKS distributes current group policy and
keying material to the group member over an authenticated and
encrypted session. The GCKS may also initiate contact ("rekeys")
group members to provide updates to group policy.
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs. ISAKMP defines two "phases" of negotiation (p.16 of [RFC2408]). A
Phase 1 security association provides mutual authentication and
authorization, and a security association that is used by the
protocol participants to execute a phase 2 exchange. This document
incorporates (i.e., uses but does not re-define) the Phase 1 security
association definition from the Internet DOI [RFC2407], [RFC2409].
Phase 1 security association types other than ISAKMP are possible,
and are noted in Appendix A. Requirements of those phase 1 security
associations are specified in Section 2. The GDOI includes two new
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:
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for 1. The GROUPKEY-PULL registration protocol exchange. This exchange
a group's "Re-key" SA and/or "Data-security" SA. The Re-key SA uses "pull" behavior since the member initiates the retrieval of
includes a key encrypting key, or KEK, common to the group; a Data- these SAs from a GCKS. It is protected by an ISAKMP phase 1
security SA includes a data encryption key, or TEK, used by a data- protocol, as described above. At the culmination of a GROUPKEY-
security protocol to encrypt or decrypt data traffic Section 2.1 of PULL exchange, an authorized group member has received and
[RFC2407]. The SA for the KEK or TEK includes authentication keys, installed a set of SAs that represent group policy, and it is
encryption keys, cryptographic policy, and attributes. The GROUPKEY- ready to participate in secure group communications.
PULL exchange uses "pull" behavior since the member initiates the
retrieval of these SAs from a GCKS.
2) A datagram subsequently establishes additional Rekey and/or Data- 2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is
Security Protocol SAs. a datagram initiated ("pushed") by the GCKS, usually delivered to
group members using a IP multicast address. It is treated as a
ISAKMP phase 2 protocol, where the "phase 1" cryptographic policy
and keying material is included in the group policy distributed
by the GCKS in the GROUPKEY-PULL exchange. At the culmination of
a GROUPKEY-PUSH exchange, all authorized group members have
received and installed updates to group policy, and can continue
to participate in secure group communications. If a group
management method is included in group policy (as described in
Section 1.5.1), at the conclusion of the GROUPKEY-PUSH exchange
some members of the group may have been de-authorized and no
longer able to participate in the secure group communications.
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the members +--------------------------------------------------------------+
to create or update a Re-key or Data-security SA. A Re-key SA | |
protects GROUPKEY-PUSH messages. Thus, a GROUPKEY-PULL is necessary | +--------------------+ |
to establish at least one Re-key SA in order to protect subsequent | +------>| GDOI GCKS |<------+ |
GROUPKEY-PUSH messages. The GCKS encrypts the GROUPKEY-PUSH message | | +--------------------+ | |
using the KEK Re-key SA. GDOI accommodates the use of arrays of KEKs | | | | |
for group key management algorithms using the Logical Key Hierarchy | GROUPKEY-PULL | GROUPKEY-PULL |
(LKH) algorithm to efficiently add and remove group members | PROTOCOL | PROTOCOL |
[RFC2627]. Implementation of the LKH algorithm is OPTIONAL. | | | | |
| v GROUPKEY-PUSH v |
| +-----------------+ PROTOCOL +-----------------+ |
| | | | | | |
| | GDOI GM(s) |<-------+-------->| GDOI GM(S) | |
| | | | | |
| +-----------------+ +-----------------+ |
| | ^ |
| v | |
| +-Data Security Protocol (e.g., ESP)-+ |
| |
+--------------------------------------------------------------+
Although the GROUPKEY-PUSH specified by this document can be used to Although the GROUPKEY-PUSH specified by this document can be used to
refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to
establish a Data-security SA for a data security protocol. GDOI can establish a Data-security SA for a data security protocol. In
accommodate future extensions to support a variety of data security summary, GDOI is a group security association management protocol:
protocols. This document only specifies data-security SAs for All GDOI messages are used to create, maintain, or delete security
security protocols, IPsec ESP and IPsec AH. A security protocol uses
the TEK and "owns" the data-security SA in the same way that IPsec
ESP uses the IKE Phase 2 keys and owns the Phase 2 SA; for GDOI,
IPsec ESP or IPsec AH use the TEK.
Thus, GDOI is a group security association management protocol: 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 key-encrypting keys, traffic-
encrypting keys, or data shared by group members for multicast and encrypting keys, or 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. GDOI Applications 1.2. Terminology
The following key terms are used throughout this document.
Key Encrypting Key (KEK). The symmetric cipher key used to protect
the GROUPKEY-PUSH message.
Logical Key Hierarchy (LKH). A group management method defined in
Section 5.4 of [RFC2627].
Traffic Encryption Key (TEK). The symmetric cipher key used to
protect a data security protocol (e.g., IPsec ESP).
1.3. GDOI Applications
Secure multicast applications include video broadcast and multicast Secure multicast applications include video broadcast and multicast
file transfer. Many of these applications require network security file transfer. GDOI can also secure group applications that do not
and may use IPsec ESP or AH to secure their data traffic. use multicast transport such as video-on-demand where the same
Section 5.5.1 specifies how GDOI carries the needed SA parameters for encrypted content is delivered to each group member.
ESP or AH. In this way, GDOI supports multicast ESP or AH with group
authentication of ESP or AH packets using the shared, group key.
GDOI can also secure group applications that do not use multicast A GDOI application may require Data-security SAs (such as IPsec ESP
transport such as video-on-demand. For example, the GROUPKEY-PUSH SAs), and/or a Rekey-SA (the SA used to protect GROUPKEY-PUSH
message may establish a pair-wise IPsec ESP or AH SA for a member of messages). For example, a secure multicast video broadcast may only
a subscription group without the need for key management exchanges need to distribute a single set of Data-Security SAs to protect the
and costly asymmetric cryptography. time-bounded broadcast. In this case, no Rekey-SA may be necessary
because the initial Data-security SAs will not be cryptographically
overused, and there is no desire to de-authorize group members.
1.3. Extending GDOI In contrast, an always-on IP multicast application (e.g., stock-
ticker delivery service) with many group members may require a policy
of frequent change of Data-security SAs and regular de-authorization
of group members. In this case, the GCKS policy will regularly
replace Data-security SAs with new SAs defining the same traffic
selectors but new keying material. This will result in a regularly-
scheduled GROUPKEY-PUSH delivering the new SAs. Additionally, the
group membership on the GCKS may be frequently adjusted, which will
result in GROUPKEY-PUSH exchange delivering a new Rekey SAs protected
by a group management method. Each GROUPKEY-PUSH may include Data-
security SAs and/or a Rekey SA. In all cases, the relevant policy is
defined on the GCKS and relayed to group members. Specific policy
choices possible by the GCKS depends on each application and further
discussion of policy is beyond the scope of this memo.
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]. A
future RTP security protocol may benefit from using GDOI to establish future RTP security protocol may benefit from using GDOI to establish
group SAs. group SAs. 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 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.
1.5. Forward and Backward Access Control
Through GROUPKEY-PUSH, the GDOI supports group management methods
such as LKH (section 5.4 of [RFC2627]) that have the property of
denying access to a new group key by a member removed from the group
(forward access control) and to an old group key by a member added to
the group (backward access control). An unrelated notion to PFS,
"forward access control" and "backward access control" have been
called "perfect forward security" and "perfect backward security" in
the literature [RFC2627].
Group management algorithms providing forward and backward access
control other than LKH have been proposed in the literature,
including OFT [OFT] and Subset Difference [NNL]. These algorithms
could be used with GDOI, but are not specified as a part of this
document.
1.5.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm
new Data-security SAs are usually also needed. New SAs ensure that
members who were denied access can no longer participate in the
group.
If forward access control is a desired property of the group, new
Data-security SAs MUST NOT be included in a GROUPKEY-PUSH message
which changes group membership. This is required because the new
Data-security SAs are not protected with the new KEK. Instead, two
sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first
changing the KEK, and the second (protected with the new KEK)
distributing the new Data-security SAs.
Note that in the above sequence, although the new KEK can effectively
deny access to the group to some group members they will be able to
view the new KEK policy. If forward access control policy for the
group includes keeping the KEK policy secret as well as the KEK
itself secret, then two GROUPKEY-PUSH messages changing the KEK must
occur before the new Data-security SAs are transmitted.
If other methods of using LKH or other group management algorithms
are added to GDOI, those methods MAY remove the above restrictions
requiring multiple GROUPKEY-PUSH messages, providing those methods
specify how forward access control policy is maintained within a
single GROUPKEY-PUSH message.
2. GDOI Phase 1 protocol 2. GDOI Phase 1 protocol
GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be
protocol. The "phase 1" protocol can be any protocol which provides protected by a "phase 1" protocol. The "phase 1" protocol can be any
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 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 6.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.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.1.2. UDP port
IANA has assigned port 848 for the use of GDOI. IANA has assigned port 848 for the use of GDOI, which allows for an
implementation to use separate ISAKMP implementations to service GDOI
and IKEv1 [RFC2409]. A GCKS SHOULD listen on this port for GROUPKEY-
PULL exchanges, and the GCKS MAY use this port to distribute
GROUPKEY-PUSH messages. An ISAKMP phase 1 exchange implementation
supporting NAT Traversal [RFC3947] may move to port 4500 to process
the GROUPKEY-PULL exchange.
3. GROUPKEY-PULL Exchange 3. GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Re-key The goal of the GROUPKEY-PULL exchange is to establish a Re-key
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.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
SHOULD ensure that the Phase 1 identity of the GCKS is an authorized SHOULD ensure that the Phase 1 identity of the GCKS is an authorized
GCKS. When no authorization is performed, it is possible for a rogue GCKS. When no authorization is performed, it is possible for a rogue
GDOI participant to perpetrate a man-in-the-middle attack between a GDOI participant to perpetrate a man-in-the-middle attack between a
group member and a GCKS [MP04]. group 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 IKE 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
important to protect the GCKS from attacks that a key management important to protect the GCKS from attacks that a key management
server will attract. server will attract.
The GROUPKEY-PULL uses nonces to guarantee "liveness", or against The GROUPKEY-PULL uses nonces to guarantee "liveness", or against
replay of a recent GROUPKEY-PULL message. The replay attack is only replay of a recent GROUPKEY-PULL message. The replay attack is only
useful in the context of the current Phase 1. If a GROUPKEY-PULL useful in the context of the current Phase 1. If a GROUPKEY-PULL
message is replayed based on a previous Phase 1, the HASH calculation message is replayed based on a previous Phase 1, the HASH calculation
skipping to change at page 11, line 25 skipping to change at page 11, line 25
Hashes are computed as follows: Hashes are computed as follows:
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ | ] KD) HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ | ] KD)
* Protected by the Phase 1 SA, encryption occurs after HDR * 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 IKE [RFC2409]. Note that nonces are message identifier (M-ID) as in IKEv1. Note that nonces are included
included in the first two exchanges, with the GCKS returning only the in the first two messages, with the GCKS returning only the SA policy
SA policy payload before liveliness is proven. The HASH payloads payload before liveliness is proven. The HASH payloads [RFC2409]
[RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce
the nonce for the exchange identified by message id, M-ID. Once for the exchange identified by message id, M-ID. Once liveliness is
liveliness is established, the last message completes the real established, the last message completes the real processing of
processing of downloading the KD payload. downloading the KD payload.
In addition to the Nonce and HASH payloads, the member-initiator In addition to the Nonce and HASH payloads, the member-initiator
identifies the group it wishes to join through the ISAKMP ID payload. identifies the group it wishes to join through the ISAKMP ID payload.
The GCKS responder informs the member of the current value of the The GCKS responder informs the member of the current value of the
sequence number in the SEQ payload; the sequence number provides sequence number in the SEQ payload; the sequence number provides
anti-replay state associated with a KEK. The SEQ payload has no anti-replay state associated with a KEK. The SEQ payload has no
other use, and is omitted from the GROUPKEY_PULL exchange when a KEK other use, and is omitted from the GROUPKEY_PULL exchange when a KEK
attribute is not included in the SA payload. attribute is not included in the SA payload.
When a SEQ payload is included in the GROUPKEY-PULL exchange, it When a SEQ payload is included in the GROUPKEY-PULL exchange, it
skipping to change at page 12, line 29 skipping to change at page 12, line 29
SA TEK attribute contains a SPI as defined in Section 5.5 of this SA TEK attribute contains a SPI as defined in Section 5.5 of this
document. The second message downloads this SA payload. If a Re-key document. The second message downloads this SA payload. If a Re-key
SA is defined in the SA payload, then KD will contain the KEK; if one SA is defined in the SA payload, then KD will contain the KEK; if one
or more Data-security SAs are defined in the SA payload, KD will or more Data-security SAs are defined in the SA payload, KD will
contain the TEKs. This is useful if there is an initial set of TEKs contain the TEKs. This is useful if there is an initial set of TEKs
for the particular group and can obviate the need for future TEK for the particular group and can obviate the need for future TEK
GROUPKEY-PUSH messages (described in section 4). GROUPKEY-PUSH messages (described in section 4).
3.2.1. ISAKMP Header Initialization 3.2.1. ISAKMP Header Initialization
Cookies are used in the ISAKMP header as a weak form of denial of Cookies are used in the ISAKMP header to identify a particular GDOI
service protection. The GDOI GROUPKEY-PULL exchange uses cookies session. The GDOI GROUPKEY-PULL exchange uses cookies according to
according to ISAKMP [RFC2408]. ISAKMP [RFC2408].
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange. The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of
[RFC2408]). [RFC2408]).
skipping to change at page 13, line 7 skipping to change at page 13, line 7
determine the group identifier and acceptable Phase 1 policy via an determine the group identifier and acceptable Phase 1 policy via an
out-of-band method. Phase 1 is initiated using the GDOI DOI in the out-of-band method. Phase 1 is initiated using the GDOI DOI in the
SA payload. Once Phase 1 is complete, the initiator state machine SA payload. Once Phase 1 is complete, the initiator state machine
moves to the GDOI protocol. moves to the GDOI protocol.
To construct the first GDOI message the initiator chooses Ni and To construct the first GDOI message the initiator chooses Ni and
creates a nonce payload, builds an identity payload including the creates a nonce payload, builds an identity payload including the
group identifier, and generates HASH(1). group identifier, and generates HASH(1).
Upon receipt of the second GDOI message, the initiator validates Upon receipt of the second GDOI message, the initiator validates
HASH(2), extracts the nonce Nr, and interprets the SA payload. If HASH(2), extracts the nonce Nr, and interprets the SA payload. The
the policy in the SA payload is acceptable (e.g., the security SA payload contains policy describing the security protocol and
protocol and cryptographic protocols can be supported by the cryptographic protocols used by the group. This policy describes the
initiator), the initiator continues the protocol. Re-key SA (if present), Data-security SAs, and other group policy.
If the policy in the SA payload is acceptable to the initiator, it
continues the protocol.
The initiator constructs the third GDOI message by creating HASH(3). The initiator constructs the third GDOI message by creating HASH(3).
Upon receipt of the fourth GDOI message, the initiator validates Upon receipt of the fourth GDOI message, the initiator validates
HASH(4). HASH(4).
If SEQ payload is present, the sequence number in the SEQ payload If SEQ payload is present, the sequence number in the SEQ payload
must be checked against any previously received sequence number for must be checked against any previously received sequence number for
this group. If it is less than the previously received number, it this group. If it is less than the previously received number, it
should be considered stale and ignored. This could happen if two should be considered stale and ignored. This could happen if two
GROUPKEY-PULL messages happened in parallel, and the sequence number GROUPKEY-PULL messages happened in parallel, and the sequence number
changed between the times the results of two GROUPKEY-PULL messages changed between the times the results of two GROUPKEY-PULL messages
were returned from the GCKS. were returned from the GCKS.
The initiator interprets the KD key packets, matching the SPIs in the The initiator interprets the KD key packets, where each key packet
key packets to SPIs previously sent in the SA payloads identifying includes the keying material for SAs distributed in the SA payload.
particular policy. For TEKs, once the keys and policy are matched, Keying material is matched by comparing the SPIs in the key packets
the initiator is ready to send or receive packets matching the TEK to SPIs previously sent in the SA payloads. Once TEK keys and policy
policy. (If policy and keys had been previously received for this are matched, the initiator provides them to the data security
TEK policy, the initiator may decide instead to ignore this TEK subsystem, and it is ready to send or receive packets matching the
policy in case it is stale.) If this group has a KEK, the KEK policy TEK policy. If this group has a KEK, the KEK policy and keys are
and keys are marked as ready for use, and the group member knows to marked as ready for use, and the initiator knows to expect the
expect the sequence number reset to 1 with the next Rekey SA, which sequence number reset to 1 with the next Rekey SA, which will be
will be encrypted with the new KEK attribute. encrypted with the new KEK attribute. The initiator is now ready to
receive GROUPKEY-PUSH messages.
If the KD payload included an LKH array of keys, the initiator takes
the last key in the array as the group KEK. The array is then stored
without further processing.
3.4. Receiver Operations 3.4. Receiver Operations
The GCKS (responder) passively listens for incoming requests from The GCKS (responder) passively listens for incoming requests from
group members. The Phase 1 authenticates the group member and sets group members. The Phase 1 authenticates the group member and sets
up the secure session with them. up the secure session with them.
Upon receipt of the first GDOI message the GCKS validates HASH(1), Upon receipt of the first GDOI message the GCKS validates HASH(1),
extracts the Ni and group identifier in the ID payload. It verifies extracts the Ni and group identifier in the ID payload. It verifies
that its database contains the group information for the group that its database contains the group information for the group
identifier. identifier.
The GCKS constructs the second GDOI message, including a nonce Nr, The GCKS constructs the second GDOI message, including a nonce Nr,
and the policy for the group in an SA payload, followed by SA TEK and the policy for the group in an SA payload, followed by SA GAP, SA
payloads for traffic SAs, and SA KEK policy (if the group controller KEK, and/or SA TEK payloads according to the GCKS policy. (See
will be sending Re-key messages to the group). Section 5.2.1 for details on how the GCKS chooses which payloads to
send.)
Upon receipt of the third GDOI message the GCKS validates HASH(3). Upon receipt of the third GDOI message the GCKS validates HASH(3).
The GCKS constructs the fourth GDOI message, including the SEQ The GCKS constructs the fourth GDOI message, including the SEQ
payload (if the GCKS sends rekey messages), and the KD payload payload (if the GCKS sends rekey messages), and the KD payload
containing keys corresponding to policy previously sent in the SA TEK containing keys corresponding to policy previously sent in the SA TEK
and SA KEK payloads. and SA KEK payloads. If a group management algorithm is defined as
part of group policy, the GCKS will first insert the group member
into the group management structure (e.g., a leaf in the LKH tree),
and then create an LKH array of keys and include it in the KD
payload. The first key in the array is associated with the group
member leaf node, followed by each LKH node above it in the tree,
culminating with the root node (which is also the KEK).
4. GROUPKEY-PUSH Message 4. GROUPKEY-PUSH Message
GDOI sends control information securely using group communications. GDOI sends control information securely using group communications.
Typically this will be using IP multicast distribution of a GROUPKEY- Typically this will be using IP multicast distribution of a GROUPKEY-
PUSH message but it can also be "pushed" using unicast delivery if IP PUSH message but it can also be "pushed" using unicast delivery if IP
multicast is not possible. The GROUPKEY-PUSH message replaces a Re- multicast is not possible. The GROUPKEY-PUSH message replaces a Re-
key SA KEK or KEK array, and/or creates a new Data-security SA. key SA KEK or KEK array, and/or creates a new Data-security SA.
Member GCKS or Delegate Member GCKS or Delegate
------ ---------------- ------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] 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. The SA defines the policy (e.g., protection suite) and section. One or more D (Delete) payloads optionally specify the
attributes (e.g., SPI) for a Re-key and/or Data-security SAs. The deletion of existing group policy. The SA defines the policy (e.g.,
GCKS or delegate optionally provides a CERT payload for verification protection suite) and attributes (e.g., SPI) for a replacement Re-key
of the SIG. KD is the key download payload as described in the SA and/or Data-security SAs. KD is the key download payload as
Payloads section. 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, SEQ, SA, KD, and optionally the CERT payload. The GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG
prefixed string ensures that the signature of the Rekey datagram payload. The prefixed string ensures that the signature of the Rekey
cannot be used for any other purpose in the GDOI protocol. After the datagram cannot be used for any other purpose in the GDOI protocol.
SIG payload is created using the signature of the above hash, the After the SIG payload is created using the signature of the above
current KEK encryption key encrypts all the payloads following the hash, with the receiver verifying the signature using a public key
retrieved in policy received by a GROUPKEY-PULL exchange, or
distributed in an earlier GROUPKEY-PUSH message. The current KEK
encryption key (previously distributed in a GROUPKEY-PULL exchange or
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 6.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 an LKH KEK array or single KEK, KD contains a KEK
or KEK array for a new Re-key SA, which has a new cookie pair. When or KEK array for a new Re-key SA, which has a new cookie pair. When
the KD payload carries a new SA KEK attribute (section 5.3), a Re-key the KD payload carries a new SA KEK attribute (section 5.3), a Re-key
SA is replaced with a new SA having the same group identifier (ID SA is replaced with a new SA having the same group identifier (ID
specified in message 1 of section 3.2) and incrementing the same specified in message 1 of section 3.2) and incrementing the same
sequence counter, which is initialized in message 4 of section 3.2. sequence counter, which is initialized in message 4 of section 3.2.
Note the first packet for the given Rekey SA encrypted with the new Note the first packet for the given Rekey SA encrypted with the new
KEK attribute will have a Sequence number of 1. If the SA defines an KEK attribute will have a Sequence number of 1. If the SA defines an
SA TEK payload, this informs the member that a new Data-security SA SA TEK payload, this informs the member that a new Data-security SA
has been created, with keying material carried in KD (Section 5.6). 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. Forward and Backward Access Control 4.1. Use of signature keys
Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH that
have the property of denying access to a new group key by a member
removed from the group (forward access control) and to an old group
key by a member added to the group (backward access control). An
unrelated notion to PFS, "forward access control" and "backward
access control" have been called "perfect forward security" and
"perfect backward security" in the literature [RFC2627].
Group management algorithms providing forward and backward access
control other than LKH have been proposed in the literature,
including OFT [OFT] and Subset Difference [NNL]. These algorithms
could be used with GDOI, but are not specified as a part of this
document.
Support for group management algorithms is supported via the
KEY_MANAGEMENT_ALGORITHM attribute which is sent in the SA_KEK
payload. GDOI specifies one method by which LKH can be used for
forward and backward access control. Other methods of using LKH, as
well as other group management algorithms such as OFT or Subset
Difference may be added to GDOI as part of a later document. Any
such addition MUST be due to a Standards Action as defined in
[RFC5226].
4.1.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm
new SA_TEKs (and their associated keys) are usually also needed. New
SAs and keys ensure that members who were denied access can no longer
participate in the group.
If forward access control is a desired property of the group, new
SA_TEKs and the associated key packets in the KD payload MUST NOT be
included in a GROUPKEY-PUSH message which changes group membership.
This is required because the SA_TEK policy and the associated key
packets in the KD payload are not protected with the new KEK. A
second GROUPKEY-PUSH message can deliver the new SA_TEKS and their
associated keys because it will be protected with the new KEK, and
thus will not be visible to the members who were denied access.
If forward access control policy for the group includes keeping group
policy changes from members that are denied access to the group, then
two sequential GROUPKEY-PUSH messages changing the group KEK MUST be
sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK
for the group. Group members, which are denied access, will not be
able to access the new KEK, but will see the group policy since the
GROUPKEY-PUSH message is protected under the current KEK. A
subsequent GROUPKEY-PUSH message containing the changed group policy
and again changing the KEK allows complete forward access control. A
GROUPKEY-PUSH message MUST NOT change the policy without creating a
new KEK.
If other methods of using LKH or other group management algorithms
are added to GDOI, those methods MAY remove the above restrictions
requiring multiple GROUPKEY-PUSH messages, providing those methods
specify how forward access control policy is maintained within a
single GROUPKEY-PUSH message.
4.2. Delegation of Key Management
GDOI supports delegation of GROUPKEY-PUSH datagrams through the
delegation capabilities of the PKI. However, GDOI does not
explicitly specify how the GCKS identifies delegates, but leaves this
to the PKI that is used by a particular GDOI implementation.
4.3. Use of signature keys
The GCKS SHOULD NOT use the same key to sign the SIG payload in the In order to avoid overusing its authentication signature key, 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.4. ISAKMP Header Initialization 4.2. ISAKMP Header Initialization
Unlike ISAKMP or IKE, the cookie pair is completely determined by the Unlike ISAKMP or IKEv1, the cookie pair is completely determined by
GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re- the GCKS. The cookie pair in the GDOI ISAKMP header identifies the
key SA to differentiate the secure groups managed by a GCKS. Thus, Re- key SA to differentiate the secure groups managed by a GCKS.
GDOI uses the cookie fields as an SPI. Thus, GDOI uses the cookie fields as an SPI.
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]). (Section 3.1 of [RFC2408]).
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Flags MUST have the Encryption bit set according to [RFC2008, Section Flags MUST have the Encryption bit set according to [RFC2008, Section
3.1]. All other bits MUST be set to zero. 3.1]. All other bits MUST be set to zero.
Message ID MUST be set to zero. Message ID MUST be set to zero.
Length is according to ISAKMP (Section 3.1 of [RFC2408]). Length is according to ISAKMP (Section 3.1 of [RFC2408]).
4.5. Deletion of SAs 4.3. Deletion of SAs
There are times the GCKS may want to signal to receivers to delete There are times the GCKS may want to signal to receivers to delete
SAs, for example at the end of a broadcast. Deletion of keys may be SAs, for example at the end of a broadcast. Deletion of keys may be
accomplished by sending an ISAKMP Delete payload (Section 3.15 of accomplished by sending an ISAKMP Delete payload (Section 3.15 of
[RFC2408]) as part of a GDOI GROUPKEY-PUSH message. [RFC2408]) as part of a GDOI GROUPKEY-PUSH message.
One or more Delete payloads MAY be placed following the SEQ payload One or more Delete payloads MAY be placed following the SEQ payload
in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to
group members, the SA and KD payloads MUST be omitted from the group members, the SA and KD payloads MUST be omitted from the
message. message.
skipping to change at page 18, line 39 skipping to change at page 17, line 25
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
deleted. deleted.
4.6. GCKS Operations 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.
An SA payload is then added. This is identical in structure and An SA payload is then added. This is identical in structure and
meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there
are changes to the KEK (in the case of a static KEK) or in group are changes to the KEK (including due to group members being
membership (in the case of LKH) an SA_KEK attribute is added to the excluded, in the case of LKH), an SA_KEK attribute is added to the
SA. If there are one or more new TEKs then SA_TEK attributes are SA. If there are one or more new TEKs then SA_TEK attributes are
added to describe that policy. added to describe that policy.
A KD payload is then added. This is identical in structure and A KD payload is then added. This is identical in structure and
meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an
SA_KEK attribute was included in the SA payload then corresponding SA_KEK attribute was included in the SA payload then corresponding
KEK keys (or a KEK array) is included. TEK keys are sent for each KEK keys (or a KEK update array) is included. A KEK update array is
SA_TEK attribute included in the SA payload. created by first determining which group members have been excluded,
and then generating new keys as necessary and distribute LKH update
A CERT payload is added if the initiator needs to provide its arrays sufficient to provide the new KEK to remaining group members
certificate. (see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent
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.7. Group Member Operations 4.5. 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 signature of the decrypted message is then validated, possibly
using the CERT payload if it is included.
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. fits within a window of acceptable values. The SIG payload is then
validated. If the signature fails, the message is discarded.
The SA and KD payloads are processed which results in a new GDOI The SA and KD payloads are processed which results in a new GDOI
Rekey SA (if the SA payload included an SA_KEK attribute) and/or new Rekey SA (if the SA payload included an SA_KEK attribute) and/or new
IPsec SAs being added to the system. IPsec SAs being added to the system. If the KD payload 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 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
decryption yields the new group KEK.
5. Payloads and Defined Values 5. Payloads and Defined Values
This document specifies use of several ISAKMP payloads, which are This document specifies use of several ISAKMP payloads, which are
defined in accordance with RFC 2408. The following payloads are defined in accordance with RFC 2408. The following payloads are
extended or further specified. extended or further specified.
Next Payload Type Value Next Payload Type Value
----------------- ----- ----------------- -----
Security Association (SA) 1 Security Association (SA) 1
skipping to change at page 22, line 14 skipping to change at page 21, line 14
SA. Alternatively, group policy might use a Re-key SA but choose to SA. Alternatively, group policy might use a Re-key SA but choose to
download a KEK to the group member only as part of the Registration download a KEK to the group member only as part of the Registration
SA. Therefore, the KEK policy (in the SA KEK attribute) would not be SA. Therefore, the KEK policy (in the SA KEK attribute) would not be
necessary as part of the Re-key SA message SA payload. necessary as part of the Re-key SA message SA payload.
Specifying multiple SATs allows multiple sessions to be part of the Specifying multiple SATs allows multiple sessions to be part of the
same group and multiple streams to be associated with a session same group and multiple streams to be associated with a session
(e.g., video, audio, and text) but each with individual security (e.g., video, audio, and text) but each with individual security
association policy. association policy.
A GAP payload allows for the distribution of group-wise policy, such
as instructions as to when to activate and de-activate SAs.
5.3. SA KEK payload 5.3. SA KEK payload
The SA KEK (SAK) payload contains security attributes for the KEK The SA KEK (SAK) payload contains security attributes for the KEK
method for a group and parameters specific to the GROUPKEY-PULL method for a group and parameters specific to the GROUPKEY-PULL
operation. The source and destination identities describe the operation. The source and destination identities describe the
identities used for the GROUPKEY-PULL datagram. identities used for the GROUPKEY-PULL datagram.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
skipping to change at page 22, line 38 skipping to change at page 21, line 41
!SRC ID Data Len! SRC Identification Data ~ !SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len! ! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~ ! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ! ! !
~ SPI ~ ~ SPI ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! RESERVED ! RESERVED ! ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ 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.
skipping to change at page 23, line 49 skipping to change at page 23, line 5
o DST Identification Data (variable length) -- Value, as indicated by o DST Identification Data (variable length) -- Value, as indicated by
the DST ID Type. the DST ID Type.
o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become must be the ISAKMP Header cookie pair where the first 8 octets become
the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" in the same and the second 8 octets become the "Responder Cookie" in the same
HDR. As described above, these cookies are assigned by the GCKS. HDR. As described above, these cookies are assigned by the GCKS.
o RESERVED2 (4 octets) -- Must be zero.
o KEK Attributes -- Contains KEK policy attributes associated with o KEK Attributes -- Contains KEK policy attributes associated with
the group. The following sections describe the possible attributes. the group. The following sections describe the possible attributes.
Any or all attributes may be optional, depending on the group policy. Any or all attributes may be optional, depending on the group policy.
5.3.1. KEK Attributes 5.3.1. KEK Attributes
The following attributes may be present in a SAK Payload. The The following attributes may be present in a SAK Payload. The
attributes must follow the format defined in ISAKMP (Section 3.3 of attributes must follow the format defined in ISAKMP (Section 3.3 of
[RFC2408]). In the table, attributes that are defined as TV are [RFC2408]). In the table, attributes that are defined as TV are
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
skipping to change at page 24, line 41 skipping to change at page 24, line 5
used to exclude group members). Defined values are specified in the used to exclude group members). Defined values are specified in the
following table. following table.
KEK Management Type Value KEK Management Type Value
------------------- ----- ------------------- -----
RESERVED 0 RESERVED 0
LKH 1 LKH 1
RESERVED 2-127 RESERVED 2-127
Private Use 128-255 Private Use 128-255
5.3.2.1. LKH
This type indicates the group management method described in Section
5.4 of [RFC2627].
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 and 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
A GDOI implementation MUST support the KEK_ALG_AES algorithm
attribute. A GDOI implementation SHOULD NOT use KEK_ALG_DES, as the
level of security is not considered strong enough for this purpose.
If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys
(e.g., LKH), and if the management algorithm does not specify the (e.g., LKH), and if the management algorithm does not specify the
algorithm for those keys, then the algorithm defined by the algorithm for those keys, then the algorithm defined by the
KEK_ALGORITHM attribute MUST be used for all keys which are included KEK_ALGORITHM attribute MUST be used for all keys which are included
as part of the management. as part of the management.
5.3.3.1. KEK_ALG_DES 5.3.3.1. KEK_ALG_DES
This algorithm specifies DES using the Cipher Block Chaining (CBC) This type specifies DES using the Cipher Block Chaining (CBC) mode as
mode as described in [FIPS81]. described in [FIPS81].
5.3.3.2. KEK_ALG_3DES 5.3.3.2. KEK_ALG_3DES
This algorithm specifies 3DES using three independent keys as This type specifies 3DES using three independent keys as described in
described in "Keying Option 1" in [FIPS46-3]. "Keying Option 1" in [FIPS46-3].
5.3.3.3. KEK_ALG_AES 5.3.3.3. KEK_ALG_AES
This algorithm specifies AES as described in [FIPS197]. The mode of This type specifies AES as described in [FIPS197]. The mode of
operation for AES is Cipher Block Chaining (CBC) as recommended in operation for AES is Cipher Block Chaining (CBC) as recommended in
[AES-MODES]. [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 KEK_ALGORITHM
skipping to change at page 26, line 30 skipping to change at page 25, line 39
RESERVED 0 RESERVED 0
SIG_HASH_MD5 1 SIG_HASH_MD5 1
SIG_HASH_SHA1 2 SIG_HASH_SHA1 2
SIG_HASH_SHA256 TBD-2 SIG_HASH_SHA256 TBD-2
SIG_HASH_SHA384 TBD-3 SIG_HASH_SHA384 TBD-3
SIG_HASH_SHA512 TBD-4 SIG_HASH_SHA512 TBD-4
RESERVED 6-127 RESERVED 6-127
Private Use 128-255 Private Use 128-255
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]. SIG_HASH_MD5 and SIG_HASH_SHA1 SHOULD NOT Standard[FIPS.180-2.2002].
be used, as the level of security is not considered strong enough for
this purpose.
SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is If the SIG_ALGORITHM is SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, or
SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1. 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
Payload.
5.3.7. SIG_ALGORITHM 5.3.7. SIG_ALGORITHM
The SIG_ALGORITHM class specifies the SIG payload signature The SIG_ALGORITHM class specifies the SIG payload signature
algorithm. Defined values are specified in the following table. algorithm. Defined values are specified in the following table.
Algorithm Type Value Algorithm Type Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
SIG_ALG_RSA 1 SIG_ALG_RSA 1
SIG_ALG_DSS 2 SIG_ALG_DSS 2
SIG_ALG_ECDSS 3 SIG_ALG_ECDSS 3
SIG_ALG_RSA_PSS TBD-6 SIG_ALG_RSA_PSS TBD-6
RESERVED 4-127 SIG_ALG_ECDSA-256 TBD-7
Private Use 128-255 SIG_ALG_ECDSA-384 TBD-8
SIG_ALG_ECDSA-521 TBD-9
A GDOI implementation MUST support the following algorithm attribute: RESERVED 8-127
SIG_ALG_RSA. Private Use 128-255
5.3.7.1. SIG_ALG_RSA 5.3.7.1. SIG_ALG_RSA
This algorithm specifies the RSA digital signature algorithm using This algorithm specifies the RSA digital signature algorithm using
the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447]. the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447].
5.3.7.2. SIG_ALG_DSS 5.3.7.2. SIG_ALG_DSS
This algorithm specifies the DSS digital signature algorithm as This algorithm specifies the DSS digital signature algorithm as
described in [FIPS186-2]. described in Section 4 of [FIPS186-3].
5.3.7.3. SIG_ALG_ECDSS 5.3.7.3. SIG_ALG_ECDSS
This algorithm specifies the Elliptic Curve digital signature This algorithm specifies the Elliptic Curve digital signature
algorithm as described in [FIPS186-2]. algorithm as described in Section 5 of [FIPS186-3]. This definition
is deprecated in favor of the SIG_ALG_ECDSA family of algorithms.
5.3.7.4. SIG_ALG_RSA_PSS 5.3.7.4. SIG_ALG_RSA_PSS
This algorithm specifies the RSA digital signature algorithm using This algorithm specifies the RSA digital signature algorithm using
the EMSA-PSS encoding method, as described in [RFC3447]. 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
in [RFC5903]. The format of the signature in the SIG payload MUST be
as specified in [RFC4754].
5.3.7.6. SIG_ALG_ECDSA-384
This algorithm specifies the 384-bit Random ECP Group, as described
in [RFC5903]. The format of the signature in the SIG payload MUST be
as specified in [RFC4754].
5.3.7.7. SIG_ALG_ECDSA-521
This algorithm specifies the 521-bit Random ECP Group, as described
in [RFC5903]. The format of the signature in the SIG payload MUST be
as specified in [RFC4754].
5.3.8. SIG_KEY_LENGTH 5.3.8. SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key The SIG_KEY_LENGTH class specifies the length of the SIG payload key
in bits. in bits.
5.4. Group Associated Policy 5.4. Group Associated Policy
RFC 3547 provides for the distribution of policy in the GROUPKEY-PULL RFC 3547 provides for the distribution of policy in the GROUPKEY-PULL
exchange in an SA payload. Policy can define GROUPKEY-PUSH policy exchange in an SA payload. Policy can define GROUPKEY-PUSH policy
(SA KEK) or traffic encryption policy (SA TEK) such as IPsec policy. (SA KEK) or traffic encryption policy (SA TEK) such as IPsec policy.
skipping to change at page 38, line 43 skipping to change at page 38, line 34
5.6.2.2. SIG_ALGORITHM_KEY 5.6.2.2. SIG_ALGORITHM_KEY
The SIG_ALGORITHM_KEY class declares that the public key for this SPI The SIG_ALGORITHM_KEY class declares that the public key for this SPI
is contained in the Key Packet Attribute, which may be useful when no is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload. will use this key was specified in the SAK payload.
5.6.3. LKH Download Type 5.6.3. LKH Download Type
The LKH key packet is comprised of attributes representing different The LKH key packet is comprised of attributes representing different
leaves 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
skipping to change at page 39, line 39 skipping to change at page 39, line 39
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys ! ! LKH Keys !
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The KEK_LKH attribute fields are defined as follows: The KEK_LKH attribute fields are defined as follows:
o LKH version (1 octet) -- Contains the version of the LKH protocol o LKH version (1 octet) -- Version of the LKH data format. Must be
which the data is formatted in. Must be one. one.
o Number of LKH Keys (2 octets) -- This value is the number of o Number of LKH Keys (2 octets) -- This value is the number of
distinct LKH keys in this sequence. distinct LKH keys in this sequence.
o RESERVED (1 octet) -- Unused, set to zero. Each LKH Key is defined o RESERVED (1 octet) -- Unused, set to zero. Each LKH Key is defined
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 20 skipping to change at page 40, line 20
~ Key Creation Date ! ~ Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date ! ~ Key expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle ! ~ Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Key Data ~ ~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH ID (2 octets) -- This is the position of this key in the binary o LKH ID (2 octets) -- Identity of the LKH node. A GCKS is free to
tree structure used by LKH. choose the ID in an implementation-specific manner (e.g., the
position of this key in a binary tree structure used by LKH).
o Key Type (1 octet) -- This is the encryption algorithm for which o Key Type (1 octet) -- Encryption algorithm for which this key data
this key data is to be used. This value is specified in Section is to be used. This value is specified in Section 5.3.3.
5.3.3.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o Key Creation Date (4 octets) -- This is the time value of when this o Key Creation Date (4 octets) -- Time value of when this key data
key data was originally generated. A time value of zero indicates was originally generated. A time value of zero indicates that there
that there is no time before which this key is not valid. is no time before which this key is not valid.
o Key Expiration Date (4 octets) -- This is the time value of when o Key Expiration Date (4 octets) -- Time value of when this key is no
this key is no longer valid for use. A time value of zero indicates longer valid for use. A time value of zero indicates that this key
that this key does not have an expiration time. does not have an expiration time.
o Key Handle (4 octets) -- This is the randomly generated value to o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely
uniquely identify a key within an LKH ID. identify a key within an LKH ID. Each new key distributed by the
GCKS for this node will have a key handle identity distinct from
previous or successive key handles specified for this node.
o Key Data (variable length) -- This is the actual encryption key o Key Data (variable length) -- Key data, which is dependent on the
data, which is dependent on the Key Type algorithm for its format. Key Type algorithm for its format. If the mode of operation for the
If the mode of operation for the algorithm requires an Initialization algorithm requires an Initialization Vector (IV), an explicit IV MUST
Vector (IV), an explicit IV MUST be included in the Key Data field be included in the Key Data field prepended to the actual key.
before the actual key.
The Key Creation Date and Key expiration Dates MAY be zero. This is The Key Creation Date and Key expiration Dates MAY be zero. This is
necessary in the case where time synchronization within the group is necessary in the case where time synchronization within the group is
not possible. not possible.
The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute
contains the Leaf identifier and key for the group member. The rest contains the Leaf identifier and key for the group member. The rest
of the LKH Key structures contain keys along the path of the key tree of the LKH Key structures contain keys along the path of the key tree
in order from the leaf, culminating in the group KEK. in order from the leaf, culminating in the group KEK.
skipping to change at page 41, line 29 skipping to change at page 41, line 30
! LKH Version ! # of LKH Keys ! RESERVED ! ! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! RESERVED2 ! ! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle ! ! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys ! ! LKH Keys !
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH version (1 octet) -- Contains the version of the LKH protocol o LKH version (1 octet) -- Version of the LKH data format. Must be
which the data is formatted in. Must be one. one.
o Number of LKH Keys (2 octets) -- This value is the number of o Number of LKH Keys (2 octets) -- Number of distinct LKH keys in
distinct LKH keys in this sequence. this sequence.
o RESERVED (1 octet) -- Unused, set to zero. o RESERVED (1 octet) -- Unused, set to zero.
o LKH ID (2 octets) -- This is the node identifier associated with o LKH ID (2 octets) -- Node identifier associated with the key used
the key used to encrypt the first LKH Key. to encrypt the first LKH Key.
o RESERVED2 (2 octets) -- Unused, set to zero. o RESERVED2 (2 octets) -- Unused, set to zero.
o Key Handle (4 octets) -- This is the value to uniquely identify the o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely
key within the LKH ID which was used to encrypt the first LKH key. identify the key within the LKH ID used to encrypt the first LKH Key.
The LKH Keys are as defined in the previous section. The LKH Key The LKH Keys are as defined in the previous section. The LKH Key
structures contain keys along the path of the key tree in order from structures contain keys along the path of the key tree in order from
the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the
group KEK. The Key Data field of each LKH Key is encrypted with the group KEK. The Key Data field of each LKH Key is encrypted with the
LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first
LKH Key is encrypted under the key defined by the LKH ID and Key LKH Key is encrypted under the key defined by the LKH ID and Key
Handle found in the LKH_UPDATE_ARRAY header. Handle found in the LKH_UPDATE_ARRAY header.
5.6.3.3. SIG_ALGORITHM_KEY 5.6.3.3. SIG_ALGORITHM_KEY
skipping to change at page 44, line 5 skipping to change at page 44, line 5
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.
6. Security Considerations 6. Algorithm Selection
For GDOI implementations to interoperate, they must support one or
more security algorithms in common. This section specifies the
security algorithm implementation requirements for standards-
conformant GDOI implementations. In call cases the choices are
intended to maintain at least 112 bits of security [SP.800-131].
Algorithms not referenced in this section can also be used.
6.1. KEK
These tables list the algorithm selections for values related to the
KEK.
Requirement KEK Management Algorithm
----------- ---------------------
SHOULD LKH
Requirement KEK Algorithm (notes)
----------- ---------------------
MUST KEK_ALG_AES with 128-bit keys
SHOULD NOT KEK_ALG_DES (1)
Requirement KEK Signature Hash Algorithm (notes)
----------- ------------------------------------
MUST SIG_HASH_SHA256
SHOULD SIG_HASH_SHA1 (2)
SHOULD NOT SIG_HASH_MD5 (3)
Requirement KEK Signature Algorithm (notes)
----------- -------------------------------
MUST SIG_ALG_RSA with 2048-bit keys
Notes:
(1) DES, with its small key size and corresponding security strength
is of questionable security for general use
(2) The use of SIG_HASH_SHA1 as a signature hash algorithm used with
GROUPKEY-PUSH messages remains safe at the time of this writing,
and is a widely deployed signature hash algorithm.
(3) Although a real weakness with second preimage resistance with
MD5 has not been found at the time of this writing, the security
strength of MD5 has been shown to be rapidly declining over time
and it's use should be understood and carefully weighed.
6.2. TEK
The following table lists the requirements for Security Protocol
support for an implementation.
Requirement KEK Management Algorithm
----------- ---------------------
MUST GDOI_PROTO_IPSEC_ESP
7. Security Considerations
GDOI is a security association (SA) management protocol for groups of GDOI is a security association (SA) management protocol for groups of
senders and receivers. Unlike a data security protocol, SA senders and receivers. Unlike a data security protocol, SA
management includes a key establishment protocol to securely management includes a key establishment protocol to securely
establish keys at communication endpoints. This protocol performs establish keys at communication endpoints. This protocol performs
entity authentication of the GDOI member or Group Controller/Key entity authentication of the GDOI member or Group Controller/Key
Server (GCKS), it provides confidentiality of key management Server (GCKS), it provides confidentiality of key management
messages, and it provides source authentication of those messages. messages, and it provides source authentication of those messages.
This protocol also uses best-known practices for defense against man- This protocol also uses best-known practices for defense against man-
in-middle, connection hijacking, replay, reflection, and denial-of- in-middle, connection hijacking, replay, reflection, and denial-of-
skipping to change at page 44, line 33 skipping to change at page 46, line 33
manner according to group policy. The security of GDOI, therefore, manner according to group policy. The security of GDOI, therefore,
is as good as the degree to which group members can be trusted to is as good as the degree to which group members can be trusted to
protect authenticators, encryption keys, decryption keys, and message protect authenticators, encryption keys, decryption keys, and message
authentication keys. authentication keys.
There are three phases of GDOI as described in this document: an There are three phases of GDOI as described in this document: an
ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is
protected by the ISAKMP Phase 1 protocol, and a new message called protected by the ISAKMP Phase 1 protocol, and a new message called
GROUPKEY-PUSH. Each phase is considered separately below. GROUPKEY-PUSH. Each phase is considered separately below.
6.1. ISAKMP Phase 1 7.1. ISAKMP Phase 1
As described in this document, GDOI uses the Phase 1 exchanges As described in this document, GDOI uses the Phase 1 exchanges
defined in [RFC2409] to protect the GROUPKEY-PULL exchange. defined in [RFC2409] to protect the GROUPKEY-PULL exchange.
Therefore all security properties and considerations of those Therefore all security properties and considerations of those
exchanges (as noted in [RFC2409]) are relevant for GDOI. exchanges (as noted in [RFC2409]) are relevant for GDOI.
GDOI may inherit the problems of its ancestor protocols [FS00], such GDOI may inherit the problems of its ancestor protocols [FS00], such
as identity exposure, absence of unidirectional authentication, or as identity exposure, absence of unidirectional authentication, or
stateful cookies [PK01]. GDOI could benefit, however, from stateful cookies [PK01]. GDOI could benefit, however, from
improvements to its ancestor protocols just as it benefits from years improvements to its ancestor protocols just as it benefits from years
of experience and work embodied in those protocols. To reap the of experience and work embodied in those protocols. To reap the
benefits of future IKE improvements, however, GDOI would need to be benefits of future IKE improvements, however, GDOI would need to be
revised in a future standards-track RFC, which is beyond the scope of revised in a future standards-track RFC, which is beyond the scope of
this specification. this specification.
6.1.1. Authentication 7.1.1. Authentication
Authentication is provided via the mechanisms defined in [RFC2409], Authentication is provided via the mechanisms defined in [RFC2409],
namely Pre-Shared Keys or Public Key encryption. namely Pre-Shared Keys or Public Key encryption.
6.1.2. Confidentiality 7.1.2. Confidentiality
Confidentiality is achieved in Phase 1 through a Diffie-Hellman Confidentiality is achieved in Phase 1 through a Diffie-Hellman
exchange that provides keying material, and through negotiation of exchange that provides keying material, and through negotiation of
encryption transforms. encryption transforms.
The Phase 1 protocol will be protecting encryption and integrity keys The Phase 1 protocol will be protecting encryption and integrity keys
sent in the GROUPKEY-PULL protocol. The strength of the encryption sent in the GROUPKEY-PULL protocol. The strength of the encryption
used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY- used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY-
PULL protocol. PULL protocol.
6.1.3. Man-in-the-Middle Attack Protection 7.1.3. Man-in-the-Middle Attack Protection
A successful man-in-the-middle or connection-hijacking attack foils A successful man-in-the-middle or connection-hijacking attack foils
entity authentication of one or more of the communicating entities entity authentication of one or more of the communicating entities
during key establishment. GDOI relies on Phase 1 authentication to during key establishment. GDOI relies on Phase 1 authentication to
defeat man-in-the-middle attacks. defeat man-in-the-middle attacks.
6.1.4. Replay/Reflection Attack Protection 7.1.4. Replay/Reflection Attack Protection
In a replay/reflection attack, an attacker captures messages between In a replay/reflection attack, an attacker captures messages between
GDOI entities and subsequently forwards them to a GDOI entity. GDOI entities and subsequently forwards them to a GDOI entity.
Replay and reflection attacks seek to gain information from a Replay and reflection attacks seek to gain information from a
subsequent GDOI message response or seek to disrupt the operation of subsequent GDOI message response or seek to disrupt the operation of
a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce
mechanism in combination with a hash-based message authentication mechanism in combination with a hash-based message authentication
code to protect against the replay or reflection of previous key code to protect against the replay or reflection of previous key
management messages. management messages.
6.1.5. Denial of Service Protection 7.1.5. Denial of Service Protection
A denial of service attacker sends messages to a GDOI entity to cause A denial of service attacker sends messages to a GDOI entity to cause
that entity to perform unneeded message authentication operations. that entity to perform unneeded message authentication operations.
GDOI uses the Phase 1 cookie mechanism to identify spurious messages GDOI uses the Phase 1 cookie mechanism to identify spurious messages
prior to cryptographic hash processing. This is a "weak" form of prior to cryptographic hash processing. This is a "weak" form of
denial of service protection in that the GDOI entity must check for denial of service protection in that the GDOI entity must check for
good cookies, which can be successfully imitated by a sophisticated good cookies, which can be successfully imitated by a sophisticated
attacker. The Phase 1 cookie mechanism is stateful, and commits attacker. The Phase 1 cookie mechanism is stateful, and commits
memory resources for cookies, but stateless cookies are a better memory resources for cookies, but stateless cookies are a better
defense against denial of service attacks. defense against denial of service attacks.
6.2. GROUPKEY-PULL Exchange 7.2. GROUPKEY-PULL Exchange
The GROUPKEY-PULL exchange allows a group member to request SAs and The GROUPKEY-PULL exchange allows a group member to request SAs and
keys from a GCKS. It runs as a "phase 2" protocol under protection keys from a GCKS. It runs as a "phase 2" protocol under protection
of the Phase 1 security association. of the Phase 1 security association.
6.2.1. Authentication 7.2.1. Authentication
Peer authentication is not required in the GROUPKEY-PULL protocol. Peer authentication is not required in the GROUPKEY-PULL protocol.
It is running in the context of the Phase 1 protocol, which has It is running in the context of the Phase 1 protocol, which has
previously authenticated the identity of the peer. previously authenticated the identity of the peer.
Message authentication is provided by HASH payloads in each message, Message authentication is provided by HASH payloads in each message,
where the HASH is defined to be over SKEYID_a (derived in the Phase 1 where the HASH is defined to be over SKEYID_a (derived in the Phase 1
exchange), the ISAKMP Message-ID, and all payloads in the message. exchange), the ISAKMP Message-ID, and all payloads in the message.
Because only the two endpoints of the exchange know the SKEYID_a Because only the two endpoints of the exchange know the SKEYID_a
value, this provides confidence that the peer sent the message. value, this provides confidence that the peer sent the message.
6.2.2. Confidentiality 7.2.2. Confidentiality
Confidentiality is provided by the Phase 1 security association, Confidentiality is provided by the Phase 1 security association,
after the manner described in [RFC2409]. after the manner described in [RFC2409].
6.2.3. Man-in-the-Middle Attack Protection 7.2.3. Man-in-the-Middle Attack Protection
Message authentication (described above) includes a secret known only Message authentication (described above) includes a secret known only
to the group member and GCKS when constructing a HASH payload. This to the group member and GCKS when constructing a HASH payload. This
prevents man-in-the-middle and connection-hijacking attacks because prevents man-in-the-middle and connection-hijacking attacks because
an attacker would not be able to change the message undetected. an attacker would not be able to change the message undetected.
6.2.4. Replay/Reflection Attack Protection 7.2.4. Replay/Reflection Attack Protection
Nonces provide freshness of the GROUPKEY-PULL exchange. The group Nonces provide freshness of the GROUPKEY-PULL exchange. The group
member and GCKS exchange nonce values first two messages. These member and GCKS exchange nonce values first two messages. These
nonces are included in subsequent HASH payload calculations. The nonces are included in subsequent HASH payload calculations. The
Group member and GCKS MUST NOT perform any computationally expensive Group member and GCKS MUST NOT perform any computationally expensive
tasks before receiving a HASH with its own nonce included. The GCKS tasks before receiving a HASH with its own nonce included. The GCKS
MUST NOT update the group management state (e.g., LKH key tree) until MUST NOT update the group management state (e.g., LKH key tree) until
it receives the third message in the exchange with a valid HASH it receives the third message in the exchange with a valid HASH
payload including its own nonce. payload including its own nonce.
Implementations SHOULD keep a record of recently received GROUPKEY- Implementations SHOULD keep a record of recently received GROUPKEY-
PULL messages and reject messages that have already been processed. PULL messages and reject messages that have already been processed.
This enables an early discard of the replayed messages. This enables an early discard of the replayed messages.
6.2.5. Denial of Service Protection 7.2.5. Denial of Service Protection
A GROUPKEY-PULL message identifies its messages using a cookie pair A GROUPKEY-PULL message identifies its messages using a cookie pair
from the Phase 1 exchange that precedes it. The cookies provide a from the Phase 1 exchange that precedes it. The cookies provide a
weak form of denial of service protection as described above, in the weak form of denial of service protection as described above, in the
sense that a GROUPKEY-PULL message with invalid cookies will be sense that a GROUPKEY-PULL message with invalid cookies will be
discarded. discarded.
The replay protection mechanisms described above provide the basis The replay protection mechanisms described above provide the basis
for denial of service protection. for denial of service protection.
6.2.6. Authorization 7.2.6. Authorization
A GCKS implementation should maintain an authorization list of A GCKS implementation should maintain an authorization list of
authorized group members. Group members should maintain a list of authorized group members. Group members will specifically list each
authorized group members as part of its Group Peer Authorization authorized GCKS in its Group Peer Authorization Database (GPAD)
Database (GPAD) [RFC5374]. [RFC5374].
6.3. GROUPKEY-PUSH Exchange 7.3. GROUPKEY-PUSH Exchange
The GROUPKEY-PUSH exchange is a single message that allows a GCKS to The GROUPKEY-PUSH exchange is a single message that allows a GCKS to
send SAs and keys to group members. This is likely to be sent to all send SAs and keys to group members. This is likely to be sent to all
members using an IP multicast group. This provides an efficient members using an IP multicast group. This provides an efficient
rekey and group membership adjustment capability. rekey and group membership adjustment capability.
6.3.1. Authentication 7.3.1. Authentication
The GROUPKEY-PULL exchange identifies a public key that is used for The GROUPKEY-PULL exchange identifies a public key that is used for
message authentication. The GROUPKEY-PUSH message is digitally message authentication. The GROUPKEY-PUSH message is digitally
signed using the corresponding private key held by the GCKS or its signed using the corresponding private key held by the GCKS or its
delegate. This digital signature provides source authentication for delegate. This digital signature provides source authentication for
the message. Thus, GDOI protects the GCKS from impersonation in the message. Thus, GDOI protects the GCKS from impersonation in
group environments. group environments.
6.3.2. Confidentiality 7.3.2. Confidentiality
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key The GCKS encrypts the GROUPKEY-PUSH message with an encryption key
that was established by the GROUPKEY-PULL exchange. that was established by the GROUPKEY-PULL exchange.
6.3.3. Man-in-the-Middle Attack Protection 7.3.3. Man-in-the-Middle Attack Protection
This combination of confidentiality and message authentication This combination of confidentiality and message authentication
services protects the GROUPKEY-PUSH message from man-in-middle and services protects the GROUPKEY-PUSH message from man-in-middle and
connection-hijacking attacks. connection-hijacking attacks.
6.3.4. Replay/Reflection Attack Protection 7.3.4. Replay/Reflection Attack Protection
The GROUPKEY-PUSH message includes a monotonically increasing The GROUPKEY-PUSH message includes a monotonically increasing
sequence number to protect against replay and reflection attacks. A sequence number to protect against replay and reflection attacks. A
group member will recognize a replayed message by comparing the group member will recognize a replayed message by comparing the
sequence number to a sliding window, in the same manner as the ESP sequence number to a sliding window, in the same manner as the ESP
protocol uses sequence numbers. protocol uses sequence numbers.
Implementations SHOULD keep a record of recently received GROUPKEY- Implementations SHOULD keep a record of recently received GROUPKEY-
PUSH messages and reject duplicate messages. This enables an early PUSH messages and reject duplicate messages. This enables an early
discard of the replayed messages. discard of the replayed messages.
6.3.5. Denial of Service Protection 7.3.5. Denial of Service Protection
A cookie pair identifies the security association for the GROUPKEY- A cookie pair identifies the security association for the GROUPKEY-
PUSH message. The cookies thus serve as a weak form of denial-of- PUSH message. The cookies thus serve as a weak form of denial-of-
service protection for the GROUPKEY-PUSH message. service protection for the GROUPKEY-PUSH message.
The digital signature used for message authentication has a much The digital signature used for message authentication has a much
greater computational cost than a message authentication code and greater computational cost than a message authentication code and
could amplify the effects of a denial of service attack on GDOI could amplify the effects of a denial of service attack on GDOI
members who process GROUPKEY-PUSH messages. The added cost of members who process GROUPKEY-PUSH messages. The added cost of
digital signatures is justified by the need to prevent GCKS digital signatures is justified by the need to prevent GCKS
skipping to change at page 48, line 32 skipping to change at page 50, line 32
where the least expensive cryptographic operation is performed first. where the least expensive cryptographic operation is performed first.
The group member first decrypts the message using a symmetric cipher. The group member first decrypts the message using a symmetric cipher.
If it is a validly formed message then the sequence number is checked If it is a validly formed message then the sequence number is checked
against the replay window. Only if the sequence number is valid is against the replay window. Only if the sequence number is valid is
the digital signature verified. Thus in order for a denial of the digital signature verified. Thus in order for a denial of
service attack to be mounted, an attacker would need to know both the service attack to be mounted, an attacker would need to know both the
symmetric encryption key used for confidentiality, and a valid symmetric encryption key used for confidentiality, and a valid
sequence number. Generally speaking this means only current group sequence number. Generally speaking this means only current group
members can effectively deploy a denial of service attack. members can effectively deploy a denial of service attack.
6.3.6. Forward Access Control 7.3.6. Forward Access Control
If a group management algorithm (such as LKH) is used, forward access If a group management algorithm (such as LKH) is used, forward access
control may not be ensured in some cases. This can happen if some control may not be ensured in some cases. This can happen if some
group members are denied access to the group in the same GROUPKEY- group members are denied access to the group in the same GROUPKEY-
PUSH message as new policy and TEKs are delivered to the group. As PUSH message as new policy and TEKs are delivered to the group. As
discussed in Section 4.1.1, forward access control can be maintained discussed in Section 1.5.1, forward access control can be maintained
by sending multiple GROUPKEY-PUSH messages, where the group by sending multiple GROUPKEY-PUSH messages, where the group
membership changes are sent from the GCKS separate from the new membership changes are sent from the GCKS separate from the new
policy and TEKs. policy and TEKs.
7. IANA Considerations 8. IANA Considerations
This memo requests IANA to make several additions to existing This memo requests IANA to make several additions to existing
registries, and to add sever new GDOI registries. When the new registries, and to add sever new GDOI registries. When the new
registries are added, the following terms are to be applied as registries are added, the following terms are to be applied as
descrined in the Guidelines for Writing an IANA Considerations described in the Guidelines for Writing an IANA Considerations
Section in RFCs [RFC5226]: Standards Action, and Private Use. Section in RFCs [RFC5226]: Standards Action, and Private Use.
7.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 [FIPS.180-2.2002]. 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 a new Algorithm Type value from the RESERVED space to
skipping to change at page 49, line 36 skipping to change at page 51, line 36
A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned
from the RESERVED space. The new algorithm id should be called from the RESERVED space. The new algorithm id should be called
GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a
value of TBD-5. value of TBD-5.
A new Next Payload Type [ISAKMP-REG] should be assigned. The new A new Next Payload Type [ISAKMP-REG] should be assigned. The new
type is called "SA Group Associated Policy (GAP)", and has a value of type is called "SA Group Associated Policy (GAP)", and has a value of
TBD-1. TBD-1.
7.2. New registries 8.2. New registries
A new namespace should be created in the GDOI Payloads registry A new namespace should be created in the GDOI Payloads registry
[GDOI-REG] to describe SA SSA Payload Values. The following rules [GDOI-REG] to describe SA GAP Payload Values. The following rules
apply to define the attributes in SA SSA Payload Values: apply to define the attributes in SA SSA Payload Values:
Attribute Type Value Type Attribute Type Value Type
---- ----- ---- ---- ----- ----
RESERVED 0 RESERVED 0
ACTIVATION_TIME_DELAY 1 B ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B DEACTIVATION_TIME_DELAY 2 B
SENDER_ID 3 V SENDER_ID 3 V
Standards Action 4-127 Standards Action 4-127
Private Use 128-255 Private Use 128-255
skipping to change at page 51, line 5 skipping to change at page 53, line 5
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
8. Acknowledgements 9. Acknowledgements
This text updates RFC 3547, and the authors with to thank the authors This text updates RFC 3547, and the authors with to thank Mark
of that specification for their extensive contributions: Mark Baugher and Hugh Harney for their extensive contributions.
Baugher, Thomas Hardjono, and Hugh Harney.
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. previously identified. Yoav Nir provided many useful technical and
editorial comments and suggestions for improvement.
9. References 10. References
9.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-05 (work in
progress), March 2010. progress), March 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.
skipping to change at page 52, line 29 skipping to change at page 54, line 29
[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", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. 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.
9.2. Informative References 10.2. Informative References
[AES-MODES]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", United States of America, National Institute
of Science and Technology NIST Special Publication 800-38A
2001 Edition, December 2001.
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[FIPS186-2] [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, January 2001. 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)
197, November 2001. 197, November 2001.
[FIPS46-3] [FIPS46-3]
"Data Encryption Standard (DES)", United States of "Data Encryption Standard (DES)", United States of
America, National Institute of Science and America, National Institute of Science and
Technology Federal Information Processing Standard (FIPS) Technology Federal Information Processing Standard (FIPS)
skipping to change at page 53, line 25 skipping to change at page 55, 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>.
[I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-01
(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
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 54, line 34 skipping to change at page 56, line 33
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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
Architecture", RFC 3740, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005. RFC 4106, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 55, line 9 skipping to change at page 57, line 14
RFC 4309, December 2005. RFC 4309, December 2005.
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", "Kerberized Internet Negotiation of Keys (KINK)",
RFC 4430, March 2006. RFC 4430, March 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006. May 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[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.
[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]
Barker, E. and A. Roginsky, "Recommendation for the
Transitioning of Cryptographic Algorithms and Key
Lengths", United States of America, National Institute of
Science and Technology DRAFT NIST Special Publication 800-
131, June 2010.
[SP.800-38A]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", United States of America, National Institute
of Science and Technology NIST Special Publication 800-38A
2001 Edition, December 2001.
[STS] Diffie, W., Van Oorschot, P., and M. Wiener, [STS] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and Authenticated Key Exchanges", Designs, "Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic
Publishers, 1992. Publishers, 1992.
Appendix A. Alternate GDOI Phase 1 protocols Appendix A. Alternate GDOI Phase 1 protocols
This section describes a manner in which other protocols could be This section describes a manner in which other protocols could be
used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1
protocol. However, they are not specified as a part of this protocol. However, they are not specified as a part of this
document. A separate document MUST be written in order for another document. A separate document MUST be written in order for another
protocol to be used as a GDOI Phase 1 protocol. protocol to be used as a GDOI Phase 1 protocol.
Other possible phase 1 protocols are also described in [RFC4046]. Other possible phase 1 protocols are also described in [RFC4046].
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Any GDOI phase 1 protocol MUST satisfy the requirements specified in
Section 2 of this document. Section 2 of this document.
A.1. IKEv2 Phase 1 protocol A.1. IKEv2 Exchange
Version 2 of the IKE protocol (IKEv2) [RFC4306] has been published.
That protocol seeks to simplify the IKE Phase 1 and Phase 2
protocols, and improve the security of the IKE protocol. 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].
IKEv2 may not include a DOI value in the SA payload. However, since Version 2 of the IKE protocol (IKEv2) [RFC4306] has been
GDOI uses a unique port, choice of a phase 2 protocol in the SA published.That protocol simplifies IKE processing, and combines the
payload using a GDOI value is not necessary. It is expected that an two phases of IKE. An IKEv2 Phase 1 negotiates an IPsec SA during
IKEv2 Phase 1 protocol definition could be run on the GDOI port. The phase 1, which was not possible in IKE. However, IKEv2 also defines
SA payload in the protocol would be specific to GDOI, or omitted if a phase 2 protocol. The phase 2 protocol is protected by the Phase
not needed at all. 1, similar in concept to how IKE Quick Mode is protected by the IKE
Phase 1 protocols in [RFC2409].
The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in It would be possible to define GDOI as a phase 2 protocol protected
the same manner as described in this document. 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.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 IKE Quick Mode [RFC2409] defined a method of encapsulating an IKEv1 Quick Mode [RFC2409]
encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK
provides a low-latency, computationally inexpensive, easily managed, provides a low-latency, computationally inexpensive, easily managed,
and cryptographically sound method of setting up IPsec security and cryptographically sound method of setting up IPsec security
associations. associations.
The KINK message format includes a GDOI field in the KINK header. The KINK message format includes a GDOI field in the KINK header.
The [RFC4430] document defines the DOI for the IPsec DOI. The [RFC4430] document defines the DOI for the IPsec DOI.
A new DOI for KINK could be defined which would encapsulate a A new DOI for KINK could be defined which would encapsulate a
GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP
skipping to change at page 58, line 29 skipping to change at page 59, line 29
o The Key Exchange Payloads (KE_I, KE_R) payloads were removed from o The Key Exchange Payloads (KE_I, KE_R) payloads were removed from
the GROUPKEY-PULL exchange. However, the specification for the GROUPKEY-PULL exchange. However, the specification for
computing keying material for the additional encryption function computing keying material for the additional encryption function
in RFC 3547 is faulty. Furthermore, it has been observed that in RFC 3547 is faulty. Furthermore, it has been observed that
because the GDOI registration message uses strong ciphers and because the GDOI registration message uses strong ciphers and
provides authenticated encryption, additional encryption of the provides authenticated encryption, additional encryption of the
keying material in a GDOI registration message provides negligible keying material in a GDOI registration message provides negligible
value. Therefore, the use of KE payloads is deprecated in this value. Therefore, the use of KE payloads is deprecated in this
memo. memo.
o The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH
exchange. The use of this payload was underspecified. In all
known use cases, the public key of used to verify the GROUPKEY-
PUSH payload is distributed directly from the key server as part
of the GROUPKEY-PULL exchange.
o Supported cryptographic algorithms were changed to meet current o Supported cryptographic algorithms were changed to meet current
guidance. Implementations are required to support AES with 128- guidance. Implementations are required to support AES with 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
skipping to change at line 2422 skipping to change at page 60, line 24
Email: bew@cisco.com Email: bew@cisco.com
Sheela Rowles Sheela Rowles
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, California 95134-1706 San Jose, California 95134-1706
USA USA
Phone: +1-408-527-7677 Phone: +1-408-527-7677
Email: sheela@cisco.com Email: sheela@cisco.com
Thomas Hardjono
MIT
77 Massachusetts Ave.
Cambridge, Massachusets 02139
USA
Phone: +1-781-729-9559
Email: hardjono@mit.edu
 End of changes. 136 change blocks. 
441 lines changed or deleted 540 lines changed or added

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