draft-ietf-msec-gdoi-update-02.txt   draft-ietf-msec-gdoi-update-03.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 3, 2007 March 02, 2007 Expires: March 17, 2008 September 14, 2007
Updates to the Group Domain of Interpretation (GDOI) Updates to the Group Domain of Interpretation (GDOI)
draft-ietf-msec-gdoi-update-02 draft-ietf-msec-gdoi-update-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2007. This Internet-Draft will expire on March 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo describes updates to the Group Domain of Interpretation This memo describes updates to the Group Domain of Interpretation
(GDOI) [RFC3547]. It provides clarification where the original text (GDOI) [RFC3547]. It provides clarification where the original text
is unclear. It also includes a discussion of algorithm agility is unclear. It also includes a discussion of algorithm agility
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4. GCKS and Group Member Authorization . . . . . . . . . . . . . 13 4. GCKS and Group Member Authorization . . . . . . . . . . . . . 13
4.1. Authorization using the CERT/POP Payloads . . . . . . . . 13 4.1. Authorization using the CERT/POP Payloads . . . . . . . . 13
4.2. Authorization through other methods . . . . . . . . . . . 13 4.2. Authorization through other methods . . . . . . . . . . . 13
5. New GDOI Attributes . . . . . . . . . . . . . . . . . . . . . 14 5. New GDOI Attributes . . . . . . . . . . . . . . . . . . . . . 14
5.1. Signature Hash Algorithm . . . . . . . . . . . . . . . . . 14 5.1. Signature Hash Algorithm . . . . . . . . . . . . . . . . . 14
5.2. Support of AH . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Support of AH . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Sender-Specific Attributes . . . . . . . . . . . . . . . . 16 5.3. Sender-Specific Attributes . . . . . . . . . . . . . . . . 16
5.3.1. SENDER_ID . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. SENDER_ID . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1.1. GCKS Semantics . . . . . . . . . . . . . . . . . . 17
5.3.1.2. Group Member Semantics . . . . . . . . . . . . . . 18
6. New IPsec Security Association Attributes . . . . . . . . . . 18 6. New IPsec Security Association Attributes . . . . . . . . . . 19
6.1. Address Preservation . . . . . . . . . . . . . . . . . . . 18 6.1. Address Preservation . . . . . . . . . . . . . . . . . . . 19
6.2. SA Direction . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. SA Direction . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
The Group Domain of Interpretation (GDOI) is a group key management The Group Domain of Interpretation (GDOI) is a group key management
protocol fitting into the Multicast Security Group Key Management protocol fitting into the Multicast Security Group Key Management
Architecture [RFC4046]. GDOI is used to disseminate policy and Architecture [RFC4046]. GDOI is used to disseminate policy and
corresponding secrets to a group of participants. GDOI is corresponding secrets to a group of participants. GDOI is
implemented on hosts and intermediate systems to protect group IP implemented on hosts and intermediate systems to protect group IP
communication (e.g., IP multicast packets) by encapsulating them with communication (e.g., IP multicast packets) by encapsulating them with
the IP Encapsulating Security Payload (ESP) [RFC4303] packets. the IP Encapsulating Security Payload (ESP) [RFC4303] packets.
skipping to change at page 5, line 42 skipping to change at page 5, line 42
IKEv1 cipher algorithms come from the "Encryption Algorithm" list in IKEv1 cipher algorithms come from the "Encryption Algorithm" list in
the IANA IPsec registry [IPSEC-REG], and the hash algorithms come the IANA IPsec registry [IPSEC-REG], and the hash algorithms come
from the "Hash Algorithm" list in the same registry. The IANA IPsec from the "Hash Algorithm" list in the same registry. The IANA IPsec
registry currently includes the SHA2-256, which is intended to be the registry currently includes the SHA2-256, which is intended to be the
SHA-256 algorithm. SHA-256 algorithm.
In summary, there are no cryptographic algorithm agility issues with In summary, there are no cryptographic algorithm agility issues with
the IKEv1 Phase 1 protocol when used as a GDOI "phase 1" protocol. the IKEv1 Phase 1 protocol when used as a GDOI "phase 1" protocol.
For a more detailed analysis of the use of hash algorithms in IKE and For a more detailed analysis of the use of hash algorithms in IKE and
IPsec, see [I-D.hoffman-ike-ipsec-hash-use]. IPsec, see RFC 4894 [RFC4894].
2.2. GROUPKEY-PUSH message 2.2. GROUPKEY-PUSH message
The GROUPKEY-PUSH message is protected by an encryption cipher for The GROUPKEY-PUSH message is protected by an encryption cipher for
confidentiality and a digital signature for message integrity. The confidentiality and a digital signature for message integrity. The
encryption cipher is described by the IANA GDOI registry as the encryption cipher is described by the IANA GDOI registry as the
KEK_ALGORITHM attribute [GDOI-REG]. The digital signature comprises KEK_ALGORITHM attribute [GDOI-REG]. The digital signature comprises
both a hash algorithm defined by the GDOI SIG_HASH_ALGORITHM both a hash algorithm defined by the GDOI SIG_HASH_ALGORITHM
attribute and a public key signature algorithm defined by the attribute and a public key signature algorithm defined by the
SIG_ALGORITHM attribute. This memo adds the SHA-256 algorithm to the SIG_ALGORITHM attribute. This memo adds the SHA-256 algorithm to the
skipping to change at page 11, line 16 skipping to change at page 11, line 16
RFC 3547 Section 3.2.1 says "The GCKS responder will xor the DH RFC 3547 Section 3.2.1 says "The GCKS responder will xor the DH
secret with the KD payload and send it to the member Initiator, which secret with the KD payload and send it to the member Initiator, which
recovers the KD by repeating this operation as in the Oakley IEXTKEY recovers the KD by repeating this operation as in the Oakley IEXTKEY
procedure [RFC2412]". However, the IEXTKEY procedure does not xor procedure [RFC2412]". However, the IEXTKEY procedure does not xor
the DH shared secret with an entire payload, and the DH shared secret the DH shared secret with an entire payload, and the DH shared secret
is not likely to be long enough to cover the entire payload. is not likely to be long enough to cover the entire payload.
Therefore, the following amended procedure MUST be used for PFS. Therefore, the following amended procedure MUST be used for PFS.
1. The GCKS and group member MUST derive an encryption key and IV 1. The GCKS and group member MUST derive an encryption key and IV
(if needed by the encryption algorithm mode) using the dhEphem (if needed by the encryption algorithm mode) using the dhEphem
method described in Section 6.1.21 of [NIST.800-56A.2006]. method described in Section 6.1.2.1 of [NIST.800-56A.2006].
2. The key derivation function MUST be the preferred key derivation 2. The key derivation function MUST be the preferred key derivation
function described in Section 5.8.1 of [NIST.800-56A.2006]. The function described in Section 5.8.1 of [NIST.800-56A.2006]. The
"kdf" function MUST be algorithm defined in the group policy as "kdf" function MUST be algorithm defined in the group policy as
the SIG_HASH_ALGORITHM attribute. The "keydatalen" input will be the SIG_HASH_ALGORITHM attribute. The "keydatalen" input will be
the number of bits necessary for the encryption algorithm plus the number of bits necessary for the encryption algorithm plus
the number of bits needed by the algorithm mode (if any). The the number of bits needed by the algorithm mode (if any). The
following kdf "OtherInfo" values MUST be hashed: following kdf "OtherInfo" values MUST be hashed:
* AlgorithmID: This value represents the encryption algorithm * AlgorithmID: This value represents the encryption algorithm
skipping to change at page 17, line 22 skipping to change at page 17, line 22
One attribute with the type of SENDER_ID is defined in this memo. One attribute with the type of SENDER_ID is defined in this memo.
5.3.1. SENDER_ID 5.3.1. SENDER_ID
Several new AES counter-based modes of operation have been specified Several new AES counter-based modes of operation have been specified
for ESP [RFC3686],[RFC4106],[RFC4309],[RFC4543] and AH [RFC4543]. for ESP [RFC3686],[RFC4106],[RFC4309],[RFC4543] and AH [RFC4543].
These AES counter-based modes require that no two senders in the These AES counter-based modes require that no two senders in the
group ever send a packet with the same IV. This requirement can be group ever send a packet with the same IV. This requirement can be
met using the method described in met using the method described in
[I-D.draft-ietf-msec-ipsec-group-counter-modes], which requires each [I-D.ietf-msec-ipsec-group-counter-modes], which requires each sender
sender to be allocated a unique Sender ID (SID). The SENDER_ID to be allocated a unique Sender ID (SID). The SENDER_ID attribute is
attribute is used to distribute a SID to a group member during the used to distribute a SID to a group member during the GROUPKEY-PULL
GROUPKEY-PULL message. message. Other algorithms with the same need may be defined in the
future; the sender MUST use the IV construction method described
above with those algorithms as well.
The SENDER_ID attribute value contains the following fields. The SENDER_ID attribute value contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SID Length ! SID Value ~ ! SID Length ! SID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o SID Length (1 octet) -- Number of bits to be used in the SID field o SID Length (1 octet) -- A natural number defining the number of
of the counter mode transform nonce. bits to be used in the SID field of the counter mode transform
nonce.
o SID Value (variable) -- The Sender ID value allocated to the group o SID Value (variable) -- The Sender ID value allocated to the group
member. member.
The sender MUST construct the IVs in each SA TEK according to 5.3.1.1. GCKS Semantics
[I-D.draft-ietf-msec-ipsec-group-counter-modes], by using the
SENDER_ID value as the Sender Identifier field, for each of the ESP
encryption algorithms that requires that IV values be distinct, and
for each of the AH authentication algorithms that requires a distinct
IV.
Algorithms needing distinct IVs are specified in The GCKS maintains a SID counter (SIDC). It is incremented each time
[RFC3686],[RFC4106],[RFC4309] and [RFC4543]. Other algorithms with a SENDER_ID attribute is distributed to a group member.The first
the same need may be defined in the future; the sender MUST use the group member to register is given the SID of 1.
IV construction method described above with those algorithms as well.
Any group member registering will be given a new SID value, which
allows group members to act as a group sender when an older SID value
becomes unusable (as described in the next section).
A GCKS MAY allocate multiple SID values in one SA SSA payload.
Allocating several SID values at the same time to a group member
expected to send at a high rate would obviate the need for the group
member to re-register as frequently.
If a GKCS allocates all SID values, it can no longer respond to GDOI
registrations. and must re-initialize the entire group. This is done
by issuing DELETE notifications for all ESP and AH SAs in a GDOI
rekey message, resetting the SIDC to zero, and creating new ESP and
AH SAs that match the group policy. When group members re-register,
the SIDs are allocated again beginning with the value 1 as described
above. Each re-registering group member will be given a new SID and
the new group policy.
5.3.1.2. Group Member Semantics
The SENDER_ID attribute value distributed to the group member MUST be
used by that group member as the Sender Identifier (SID) field
portion of the IV. The SID is used for all counter mode SAs
distributed by the GCKS to be used for communications sent as a part
of this group.
When the Sender-Specific IV (SSIV) field for any IPsec SA is
exhausted, the group member MUST no longer act as a sender using its
active SID. The group member SHOULD re-register, during which time
the GCKS will issue a new SID to the group member. The new SID
replaces the existing SID used by this group member, and also resets
the SSIV value to it's starting value. A group member MAY re-
register prior to the actual exhaustion of the SSIV field to avoid
dropping data packets due to the exhaustion of available SSIV values
combined with a particular SID value.
6. New IPsec Security Association Attributes 6. New IPsec Security Association Attributes
The Multicast Extensions to RFC 4301 [I-D.ietf-msec-ipsec-extensions] The Multicast Extensions to RFC 4301 [I-D.ietf-msec-ipsec-extensions]
describes new attributes to an IPsec security association. These describes new attributes to an IPsec security association. These
attributes describe policy that a group key management system must attributes describe policy that a group key management system must
convey in order to support those extensions. The GDOI SA TEK payload convey in order to support those extensions. The GDOI SA TEK payload
distributes IPsec policy using IPsec security association attributes distributes IPsec policy using IPsec security association attributes
defined in [ISAKMP-REG]. This section defines how GDOI can convey defined in [ISAKMP-REG]. This section defines how GDOI can convey
the new attributes as IPsec Security Association Attributes. the new attributes as IPsec Security Association Attributes.
skipping to change at page 21, line 25 skipping to change at page 22, line 25
o Protocol analysis has revealed a man-in-the-middle attack when the o Protocol analysis has revealed a man-in-the-middle attack when the
GCKS does not authorize group members based on their IKEv1 GCKS does not authorize group members based on their IKEv1
authentication credentials. This is true even when a CERT and POP authentication credentials. This is true even when a CERT and POP
payloads are used for authorization. Although suggested as an payloads are used for authorization. Although suggested as an
option in RFC 3547, a GDOI device (group member or GCKS) SHOULD option in RFC 3547, a GDOI device (group member or GCKS) SHOULD
NOT accept an identity in a CERT payload that does not match the NOT accept an identity in a CERT payload that does not match the
IKEv1 identity used to authenticate the group member. IKEv1 identity used to authenticate the group member.
o Any SA TEK specicifying a counter-based mode of operation with o Any SA TEK specicifying a counter-based mode of operation with
multiple senders MUST construct the IVs in each SA TEK according multiple senders MUST construct the IVs in each SA TEK according
to [I-D.draft-ietf-msec-ipsec-group-counter-modes]. The SID MUST to [I-D.ietf-msec-ipsec-group-counter-modes]. The SID MUST either
either be pre-configured on all group members or distributed using be pre-configured on all group members or distributed using the
the SENDER_ID attribute in the SA SSA payload. However, use use SENDER_ID attribute in the SA SSA payload. However, use use of
of the SENDER_ID attribute is RECOMMENDED. the SENDER_ID attribute is RECOMMENDED.
9. Acknowledgements 9. Acknowledgements
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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[I-D.draft-ietf-msec-ipsec-group-counter-modes]
McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic",
draft-ietf-msec-ipsec-group-counter-modes-000 (work in
progress), February 2007.
[I-D.ietf-msec-ipsec-extensions] [I-D.ietf-msec-ipsec-extensions]
Weis, B., Gross, G., and D. Ignjatic, "Multicast 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", draft-ietf-msec-ipsec-extensions-05 (work in Protocol", draft-ietf-msec-ipsec-extensions-06 (work in
progress), July 2007.
[I-D.ietf-msec-ipsec-group-counter-modes]
McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic",
draft-ietf-msec-ipsec-group-counter-modes-00 (work in
progress), February 2007. progress), February 2007.
[NIST.800-56A.2006] [NIST.800-56A.2006]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST 800-56A, Using Discrete Logarithm Cryptography", NIST 800-56A,
March 2006, <http://csrc.nist.gov/publications/nistpubs/ March 2006, <http://csrc.nist.gov/publications/nistpubs/
800-56A/sp800-56A_May-3-06.pdf>. 800-56A/sp800-56A_May-3-06.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 24, line 5 skipping to change at page 25, line 5
RFC 4303, December 2005. RFC 4303, December 2005.
10.2. Informative References 10.2. Informative References
[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.hoffman-ike-ipsec-hash-use]
Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
draft-hoffman-ike-ipsec-hash-use-05 (work in progress),
January 2007.
[IPSEC-REG] [IPSEC-REG]
Internet Assigned Numbers Authority, "Internet Key Internet Assigned Numbers Authority, "Internet Key
Exchange (IKE) Attributes IKE Attributes", IANA Registry, Exchange (IKE) Attributes IKE Attributes", IANA Registry,
December 2005, December 2005,
<http://www.iana.org/assignments/ipsec-registry>. <http://www.iana.org/assignments/ipsec-registry>.
[ISAKMP-REG] [ISAKMP-REG]
Internet Assigned Numbers Authority, "Internet Security Internet Assigned Numbers Authority, "Internet Security
Association and Key Management Protocol (ISAKMP) Association and Key Management Protocol (ISAKMP)
Identifiers ISAKMP Attributes", IANA Registry, Identifiers ISAKMP Attributes", IANA Registry,
skipping to change at page 26, line 5 skipping to change at page 26, line 11
RFC 4106, June 2005. RFC 4106, June 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005. RFC 4309, December 2005.
[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.
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key
Exchange (IKE) and IPsec", RFC 4894, May 2007.
Authors' Addresses Authors' Addresses
Brian Weis Brian Weis
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, California 95134-1706 San Jose, California 95134-1706
USA USA
Phone: +1-408-526-4796 Phone: +1-408-526-4796
Email: bew@cisco.com Email: bew@cisco.com
 End of changes. 20 change blocks. 
49 lines changed or deleted 82 lines changed or added

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