Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic
Note: This ballot was opened for revision 06 and is now closed.
(Tim Polk) Yes
(Jari Arkko) No Objection
Comment (2010-08-24 for -)
A review by Ari Keränen: 4. Group Key Management Conventions o When a GKMS determines that a particular group member is no longer a part of the group, then it MAY re-allocate any sender identifier associated with that group member for use with new group member. In this case, the GKMS MUST first delete and replace any active AH or ESP SAs with which the SID may have been used. How does the "delete and replace" happen in practice if the GKMS is a different entity than the one with the active AH or SA? A GKMS MUST support a group member notifying the GCKS that its IV space will soon be exhausted and requires a new SA to be distributed. A group member SHOULD notify the GCKS in advance of its IV space being exhausted. A GCKS MAY choose to ignore this notification based on policy (e.g., if the group member appears to be asking for new SAs so frequent as to negatively affect group communications). Ignoring the IV space exhaustion notifications probably has some security implications worth noting in the security considerations sections.
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
(David Harrington) No Objection
Comment (2010-08-23 for -)
I support Alexey's DISCUSS. "MUST support" is ambiguous. and the following SHOULD/MAY combination is so loose, it is unclear what a compliant implementation MUST support.
(Russ Housley) No Objection
Alexey Melnikov (was Discuss) No Objection
(Dan Romascanu) No Objection
(Robert Sparks) No Objection
(Sean Turner) (was Discuss) No Objection
#1: Sec 2: It is the basis for several modes of operation that combine encryption, including CCM and GCM. combine with what? I assume you mean "combine authentication with encryption, including CCM and GCM."