Multicast Security (MSEC) Group Key Management Architecture
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, msec mailing list <email@example.com>, msec chair <firstname.lastname@example.org> Subject: Document Action: 'MSEC Group Key Management Architecture' to Informational RFC The IESG has approved the following document: - 'MSEC Group Key Management Architecture ' <draft-ietf-msec-gkmarch-09.txt> as an Informational RFC This document is the product of the Multicast Security Working Group. The IESG contact persons are Russ Housley and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-09.txt
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 email@example.com. 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.