rfc2627.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,292 行 · 第 1/4 页

   the multicast group need to be brought up on-line and communicating
   more quickly.  Other participants in the multicast group can then be
   brought in when they wish.  In this type of approach though, there
   does not exist a finite period of time by when it can be ensured all
   participants will be a part of the multicast group.

   For example, in the case of a single root, the hierarchy is set up
   once, in the beginnning, by the initiator (also usually the root) who
   also generates the group participant list. The group of keys for each
   participant can then be individually requested (pulled) as soon as,
   but not until, each participant wishes to join the session.

5.4.2.3  Sender Specific Authentication

   In the multicast environment, the possibility exists that
   participants of the group at times may want to uniquely identify
   which participant is the sender of a multicast group message.  In the
   multicast key distribution system described by Ballardie [4], the
   notion of "sender specific keys" is presented.

   Another option to allow participants of a multicast group to uniquely
   determine the sender of a message is through the use of a signature
   process.  When a member of the multicast group signs a message with
   their own private signature key, the recipients of that signed
   message in the multicast group can use the sender's public
   verification key to determine if indeed the message is from who it is
   claimed to be from.

   Another related idea to this is the case when two users of a
   multicast group want to communicate strictly with each other, and
   want no one else to listen in on the communication.  If this
   communication relationship is known when the multicast group is
   originally set up, then these two participants could simply be placed
   adjacent to one another at the lowest level of the hierarchy (below a
   binary node).  Thus, they would naturally share a secret pairwise
   key.  Otherwise, a simple way to accomplish this is to perform a
   public key based pairwise key exchange between the two users to



Wallner, et al.              Informational                     [Page 18]

RFC 2627             Key Management for Multicast              June 1999


   generate a traffic encryption key for their private unicast
   communications.  Through this process, not only will the encrypted
   transmissions between them be readable only by them, but unique
   sender authentication can be accomplished via the public key based
   pairwise exchange.

5.4.2.4  Rekeying the Multicast Group and the Use of Group Key
         Encryption Keys

   Reference [4] makes use of a Group Key Encryption Key that can be
   shared by the multicast group for use in periodic rekeys of the
   multicast group. Aside from the potential security drawbacks of
   implementing a shared key for encrypting future keys, the use of a
   Group Key Encryption Key is of no benefit to a multicast group if a
   rekey is necessary due to the known compromise of one of the members.
   The strategy for rekeying the multicast group presented in Section
   5.4.1 specifically addresses this critical problem and offers a means
   to accomplish this task with minimal message transmissions and
   storage requirements.

   The question though can now be asked as to whether the rekey of a
   multicast group will be necessary in a non-compromise scenario.  For
   example, if a user decides they do not want to participate in the
   group any longer, and requests the list controller to remove them
   from the multicast group participant list, will a rekey of the
   multicast group be necessary?  If the security policy of the
   multicast group mandates that deleted users can no longer receive
   transmissions, than a rekey of a new net key will be required.  If
   the multicast group security policy does not care that the deleted
   person can still decrypt any transmissions (encrypted in the group
   net key that they might still hold), but does care that they can not
   encrypt and transmit messages, a rekey will once again be necessary.
   The only alternative to rekeying the multicast group under this
   scenario would require a recipient to check every received message
   sender, against the group participant list.  Thus rejecting any
   message sent by a user not on the list.  This is not a practical
   option.  Thus it is recommended to always rekey the multicast group
   when someone is deleted, whether it is because of compromise reasons
   or not.

5.4.2.5  Bulk Removal of Participants

   As indicated in Section 2, the need may arise to remove users in
   bulk.  If the users are setup as discussed in Section 5.4.1 into
   subgroups that wish to communicate securely all being under the same
   node, bulk user removal can be done quite simply if the whole node is
   to be removed.  The same technique as described in Section 5.4.1 is
   performed to rekey any shared node key that the remaining



Wallner, et al.              Informational                     [Page 19]

RFC 2627             Key Management for Multicast              June 1999


   participants hold in common with the removed node.

   The problem of bulk removal becomes more difficult when the
   participants to be removed are dispersed throughout the tree.
   Depending on how many participants are to be removed, and where they
   are located within the hierarchy, the number of transmissions
   required to rekey the multicast group could be equivalent to brute
   force rekeying of the remaining participants. Also the question can
   be raised as to at what point the remaining users are restructured
   into a new hierarchical tree, or should a new multicast group be
   formed.  Restructuring of the hierarchical tree would most likely be
   the preferred option, because it would not necessitate the need to
   perform pairwise key exchanges again to form the new user unique
   KEKs.

5.4.2.6  ISAKMP Compatibility

   Thus far this document has had a major focus on the architectural
   trade-offs involved in the generation, distribution, and maintenance
   of traffic encryption keys (Net Keys) for multicast groups.  There
   are other elements involved in the establishment of a secure
   connection among the multicast participants that have not been
   discussed in any detail.  For example, the concept of being able to
   "pick and choose" and negotiating the capabilities of the key
   exchange mechanism and various other elements is a very important and
   necessary aspect.

   The NSA proposal to the Internet Engineering Task Force (IETF)
   Security Subworking Group [Ref. 3] entitled "Internet Security
   Association and Key Management Protocol (ISAKMP)" has attempted to
   identify the various functional elements required for the
   establishment of a secure connection for the largest current network,
   the Internet.  While the proposal has currently focused on the
   problem of point to point connections, the functional elements should
   be the same for multicast connections, with appropriate changes to
   the techniques chosen to implement the individual functional
   elements.  Thus the implementation of ISAKMP is compatible with the
   use of the hierarchical tree approach.

6.0  SUMMARY

   As discussed in this report, there are two main areas of concern when
   addressing solutions for the multicast key management problem.  They
   are the secure initialization and rekeying of the multicast group
   with a common net key.  At the present time, there are multiple
   papers which address the initialization of a multicast group, but
   they do not adequately address how to efficiently and securely remove
   a compromised user from the multicast group.



Wallner, et al.              Informational                     [Page 20]

RFC 2627             Key Management for Multicast              June 1999


   This paper proposed a hierarchical tree approach to meet this
   difficult problem.  It is robust against collusion, while at the same
   time, balancing the number of transmissions required and storage
   required to rekey the multicast group in a time of compromise.

   It is also important to note that the proposal recommended in this
   paper is consistent with other multicast key management solutions
   [4], and allows for multiple options for its implementation.

7.0 Security Considerations

   Security concerns are discussed throughout this memo.

8.0  REFERENCES

   1. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management
      Protocol Architecture", RFC 2094, September 1994.

   2. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management
      Protocol Specification", RFC 2093,  September 1994.

   3. Maughan, D., Schertler, M. Schneider, M. and J.Turner, "Internet
      Security Association and Key Management Protocol, Version 7",
      February 1997.

   4. Ballardie, T., "Scalable Multicast Key Distribution", RFC 1949,
      May 1996.

   5. Wong, C., Gouda, M. and S. Lam, "Secure Group Communications Using
      Key Graphs", Technical Report TR 97-23, Department of Computer
      Sciences, The University of Texas at Austin, July 1997.




















Wallner, et al.              Informational                     [Page 21]

RFC 2627             Key Management for Multicast              June 1999


Authors' Addresses

   Debby M. Wallner
   National Security Agency
   Attn: R2
   9800 Savage Road  STE 6451
   Ft. Meade, MD.  20755-6451

   Phone: [phone]
   EMail: [e-mail]


   Eric J. Harder
   National Security Agency
   Attn: R2
   9800 Savage Road  STE 6451
   Ft. Meade, MD.  20755-6451

   Phone: [phone]
   EMail: [e-mail]


   Ryan C. Agee
   National Security Agency
   Attn: R2
   9800 Savage Road  STE 6451
   Ft. Meade, MD.  20755-6451
























Wallner, et al.              Informational                     [Page 22]

RFC 2627             Key Management for Multicast              June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Wallner, et al.              Informational                     [Page 23]