draft-ietf-msec-gdoi-update-10.txt   draft-ietf-msec-gdoi-update-11.txt 
Obsoletes: 3547 (once approved) B. Weis Obsoletes: 3547 (once approved) B. Weis
Internet-Draft S. Rowles Internet-Draft S. Rowles
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: February 9, 2012 T. Hardjono Expires: February 13, 2012 T. Hardjono
MIT MIT
August 8, 2011 August 12, 2011
The Group Domain of Interpretation The Group Domain of Interpretation
draft-ietf-msec-gdoi-update-10 draft-ietf-msec-gdoi-update-11
Abstract Abstract
This document describes the Group Domain of Interpretation (GDOI) This document describes the Group Domain of Interpretation (GDOI)
protocol specified in RFC 3547. The GDOI provides group key protocol specified in RFC 3547. The GDOI provides group key
management to support secure group communications according to the management to support secure group communications according to the
architecture specified in RFC 4046. The GDOI manages group security architecture specified in RFC 4046. The GDOI manages group security
associations, which are used by IPsec and potentially other data associations, which are used by IPsec and potentially other data
security protocols. This document replaces RFC 3547. security protocols. This document replaces RFC 3547.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 9, 2012. This Internet-Draft will expire on February 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.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.3. Group Member Operations . . . . . . . . . . . . . . . . . 13 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 13
3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 14 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 14
3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 15 3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 15
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 17 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 18
4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 18 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 19
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 18 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 19
4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 18 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 19
4.4. Group Member Operations . . . . . . . . . . . . . . . . . 19 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 20
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 21 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 22
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 21 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 22
5.2. Security Association Payload . . . . . . . . . . . . . . . 22 5.2. Security Association Payload . . . . . . . . . . . . . . . 23
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 23 5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 30 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 31
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 32 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 33
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 37 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 38
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 46 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 47
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 49 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 50
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 51 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 52
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 52 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 53
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 54 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 55
7.4. Forward and Backward Access Control . . . . . . . . . . . 55 7.4. Forward and Backward Access Control . . . . . . . . . . . 56
7.5. Derivation of keying material . . . . . . . . . . . . . . 57 7.5. Derivation of keying material . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8.1. Additions to current registries . . . . . . . . . . . . . 58 8.1. Additions to current registries . . . . . . . . . . . . . 59
8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 58 8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 59
8.3. Cleanup of existing registries . . . . . . . . . . . . . . 60 8.3. Cleanup of existing registries . . . . . . . . . . . . . . 61
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 64 10.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 67 Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 68
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 68 Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
Secure group and multicast applications require a method by which Secure group and multicast applications require a method by which
each group member shares common security policy and keying material. each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI), This document describes the Group Domain of Interpretation (GDOI),
which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group
key management system. The GDOI distributes security associations key management system. The GDOI distributes security associations
(SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and (SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and
potentially other data security protocols used in group applications. potentially other data security protocols used in group applications.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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.
3.1. Authorization 3.1. Authorization
The Phase 1 identity MUST be used by a GCKS to authorize the Phase 2 It is important that a group member explicitly trust entities that it
(GROUPKEY-PULL) request for a group key. A group member MUST ensure expects to act as a GCKS for a particular group. When no
that the Phase 1 identity of the GCKS is an authorized GCKS. When no
authorization is performed, it is possible for a rogue GDOI authorization is performed, it is possible for a rogue GDOI
participant to perpetrate a man-in-the-middle attack between a group participant to perpetrate a man-in-the-middle attack between a group
member and a GCKS [MP04]. member and a GCKS [MP04]. Group members MUST specifically list each
authorized GCKS in its Group Peer Authorization Database (GPAD)
[RFC5374]. A group member MUST ensure that the Phase 1 identity of
the GCKS is an authorized GCKS.
It is important that a GCKS explicitly authorize group members before
providing them with group policy and keying material. A GCKS
implementation SHOULD have a method of authorizing group members
(e.g., by maintaining an authorization list). When the GCKS performs
authorization, it MUST use the Phase 1 identity to authorize the
GROUPKEY-PULL request for group policy and keying material.
3.2. Messages 3.2. Messages
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a
which is the "key" in the keyed hash used in the ISAKMP HASH payloads which is the "key" in the keyed hash used in the ISAKMP HASH payloads
[RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1 [RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1
defined in this document, SKEYID_a is derived according to [RFC2409]. defined in this document, SKEYID_a is derived according to [RFC2409].
Each GROUPKEY-PULL message hashes a uniquely defined set of values Each GROUPKEY-PULL message hashes a uniquely defined set of values
(described below) and includes the result in the HASH payload. (described below) and includes the result in the HASH payload.
Nonces permute the HASH and provide some protection against replay Nonces permute the HASH and provide some protection against replay
 End of changes. 16 change blocks. 
43 lines changed or deleted 52 lines changed or added

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