Document Action: 'MSEC Group Key Management Architecture' to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux