The IESG has approved the following document:
- 'MSEC Group Key Management Architecture '
<draft-ietf-msec-gkmarch-08.txt> as an Informational RFC
This document is the product of the Multicast Security Working Group.
The IESG contact persons are Russ Housley and Sam Hartman.
Technical Summary
This document defines the common architecture for Multicast Security
(MSEC) key management protocols that support a variety of application,
transport, and network layer security protocols. It also defines the
Group Security Association (GSA), and describes the key management
protocols that help establish a GSA. The framework and guidelines
described in this document allow for a modular and flexible design of
group key management protocols for a variety of different settings
that are specialized to applications needs. MSEC key management
protocols may be used to facilitate secure one-to-many, many-to-many,
or one-to-one communication.
Working Group Summary
The MSEC Working Group came to rough consensus on this document.
Protocol Quality
This document was reviewed by Russ Housley for the IESG.
RFC Editor Note
1) Remove the directions to comments. Immediately after the abstract:
OLD: Comments on this document should be sent to msec@securemulticast.org.
NEW: <delete>
2) Update the Table of contents:
OLD: 10.0 References and Bibliography..................................32
NEW: 10.0 Informative References.......................................32
^^^^^^^^^^^^^^^^^^^^^^
3) Replace the 1st paragraph of Section 5.4
OLD:
The rekey message may be sent using reliable multicast. There are
multiple types of reliable multicast protocols and products, which
have different properties. However, there are no standard reliable
multicast protocols at the present time. Thus, this document makes
no recommendation for use of a particular reliable multicast
protocol or set of protocols for the purposes group key management.
The suitability of NAK-based, ACK-based or other reliable multicast
methods are determined by the particular needs of the group key
management application and environment. In the future, group key
management protocols may choose to use particular standards-based
approaches that meet the needs of the particular application. A
secure announcement facility is needed to signal the use of a
reliable multicast protocol, which must be specified as part of
group policy. The reliable multicast announcement and policy
specification, however, can only follow the establishment of
reliable multicast standards and are not considered further in this
document.
NEW:
The rekey message may be sent using reliable multicast. There are
several types of reliable multicast protocols with different
properties. However, there are no standards track reliable
multicast protocols published at this time, although IETF consensus
has been reached on two protocols that are intended to go into
standards track [NORM, RFC3450]. Thus, this document does not
recommend a particular reliable multicast protocol or set of
protocols for the purposes of reliable group rekeying. The
suitability of NAK-based, ACK-based, or other reliable multicast
methods are determined by the application needs and operational
environment. In the future, group key management protocols may
choose to use particular standards-based approaches that meet the
needs of the particular application. A secure announcement facility
may be needed to signal the use of a reliable multicast protocol,
which could be specified as part of group policy. The reliable
multicast announcement and policy specification, however, can only
follow the establishment of reliable multicast standards and are not
considered further in this document.
4. In Section 5.5, update the 1st partial paragraph on page 20.
OLD:
same time, the GCKS cannot handle all those messages. We refer to
this as an out-of-sync implosion.
NEW:
same time, the GCKS might not be able to handle all those messages.
^^^^^^^^^^^^^^^^^
We refer to this as an out-of-sync implosion.
5. In Section 7.0, update the 2nd Paragraph, 1st line
OLD: As described in the Requirements section above, the group key
NEW: As described in the Requirements section (Section 2), the group key
^^^^^^^^^^^^
6. On Page 29, update the 1st paragraph, 10th line
OLD: be robust when denial of service attacks or network partitions lead
NEW: be robust when denial of service attacks or network partitions leads
^
7. Change the title of Section 10.0 (as was done in the table of contents).
OLD: References and Bibliography
NEW: Informative References
8. Add 2 references in Section 10.0
After [MVV] add:
[NORM] B. Adamon, C. Bormann, M. Handley, J. Macker, NACK-Oriented
Reliable Multicast Protocol (NORM), draft-ietf-rmt-pi-norm-10.txt
After [RFC3547] add:
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP:
A Transport Protocol for Real-Time Applications, RFC 3550 (Proposed
Standard), July 2003.
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
