rfc2627.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

         attributes, the root will then pass the multicast group list to
         all other participants and create and distribute the Net Key.
         If a participant on the multicast group list did not meet the
         required security attributes, the leaf must be deleted from the
         list.

         Multiple issues can be raised with the distribution of the
         multicast group list and Net Key.






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


          a.  An issue exists with the time ordering of these functions.
              The multicast group list could be distributed before or
              after the link is secured (i.e. the Net Key is
              distributed).

          b.  An issue exists when a leaf refuses to join the session.
              If a leaf refuses to join a session, we can send out a
              modified list before sending out the Net Key, however
              sending out modified lists, potentially multiple times,
              would be inefficient.  Instead, the root could continue
              on, and would not send the Net Key to those participants
              on the list who rejected the session.

          For the scenario architectures which follow, we assume the
          multicast group list will be distributed to the group
          participants once before the Net Key is distributed.  Unlike
          the scheme described in [4], we recommend that the multicast
          group participant list be provided to all leaves.  By
          distributing this list to the leaves, it allows them to
          determine upfront whether they desire to participate in the
          multicast group or not, thus saving potentially unnecessary
          key exchanges.

   Four potential key management architectures to distribute keying
   material for multicast sessions are presented.  Recall that the
   features that are highly desirable for the architecture to possess
   include the time required to setup the multicast group should be
   minimized, the number of transmissions should be minimized, and
   memory/storage requirements should be minimized. As will be seen, the
   first three proposals each fall short in a different aspect of these
   desired qualities, whereas the fourth proposal appears to strike a
   balance in the features desired.  Thus, the fourth proposal is the
   one recommended for general implementation and use.

   Please note that these approaches also address securely eliminating
   users from the multicast group, but don't specifically address adding
   new users to the multicast group following initial setup because this
   is viewed as evident as to how it would be performed.

5.1  MANUAL KEY DISTRIBUTION

   Through manual key distribution, symmetric key is delivered without
   the use of public key exchanges.  To set up a multicast group Net Key
   utilizing manual key distribution would require a sequence of events
   where Net Key and spare Net Keys would be ordered by the root of the
   multicast session group. Alternate (supersession) Net Keys are
   ordered (by the root) to be used in case of a compromise of a group
   participant(s). The Net Keys would be distributed to each individual



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


   group participant, often through some centralized physical
   intermediate location. At some predetermined time, all group
   participants would switch to the new Net Key.  Group participants use
   this Net Key until a predetermined time when they need another new
   Net Key. If the Net Key is compromised during this time, the
   alternate Net Key is used. Group participants switch to the alternate
   Net Key as soon as they receive it, or upon notification from the
   root that everyone has the new Net Key and thus the switch over
   should take place. This procedure is repeated for each cryptoperiod.

   A scheme like this may be attractive because the methods exist today
   and are understood by users.  Unfortunately, this type of scheme can
   be time consuming to set up the multicast group based on time
   necessary to order keying material and having it delivered.  For most
   real time scenarios, this method is much too slow.

5.2  N Root/Leaf Pairwise Keys Approach

   This approach is a brute force method to provide a common multicast
   group Net Key to the group participants. In this scheme, the
   initiator sets the security attributes for a particular session,
   generates a list of desired group participants and transmits the list
   to all group participants.  The leaves then respond with an initial
   acceptance or rejection of participation.  By sending the list up
   front, time can be saved by not performing key exchanges with people
   who rejected participation in the session.  The root (who for this
   and future examples is assumed to be the initiator) generates a
   pairwise key with one of the participants (leaves) in the multicast
   group using some standard public key exchange technique (e.g., a
   Diffie-Hellman public key exchange.)  The root will then provide the
   security association parameters of the multicast (which may be
   different from the parameters of the initial pairwise key) to this
   first leaf.  Parameters may include items such as classification and
   policy.  Some negotiation (through the use of a Security Association
   Management Protocol, or SAMP) of the parameters may be necessary.
   The possibility exists for the leaf to reject the connection to the
   multicast group based on the above parameters and  multicast group
   list.  If the leaf rejects this session, the root will repeat this
   process with another leaf.

   Once a leaf accepts participation in the multicast session, these two
   then choose a Net Key to be used by the multicast group.  The Net Key
   could be generated through another public key exchange between the
   two entities, or simply chosen by the root, depending upon the policy
   which is in place for the multicast group ( i.e. this policy decision
   will not be a real time choice).  The issue here is the level of
   trust that the leaf has in the root.  If the initial pairwise key
   exchange provides some level of user authentication, then it seems



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


   adequate to just have the root select the Net Key at this stage.
   Another issue is the level of trust in the strength of the security
   of the generated key.  Through a cooperative process, both entities
   (leaf and root) will be providing information to be used in the
   formation of the Net Key.

   The root then performs a pairwise key exchange with another leaf and
   optionally performs the negotiation discussed earlier.  Upon
   acceptance by the leaf to join the multicast group, the root sends
   the leaf the Net Key.

   This pairwise key exchange and Net Key distribution continues for all
   N users of the multicast group.

   Root/leaves cache pairwise keys for future use.  These keys serve as
   Key Encryption Keys (KEKs) used for rekeying leaves in the net at a
   later time.  Only the root will cache all of the leaves' pairwise
   keys.  Each individual leaf will cache only its own unique pairwise
   Key Encryption Key.

   There are two cases to consider when caching the KEKs.  The first
   case is when the Net key and KEK are per session keys. In this case,
   if one wants to exclude a group participant from the multicast
   session (and rekey the remaining participants with a new Net Key),
   the root would distribute a new Net key encrypted with each
   individual KEK to every legitimate remaining participant.  These KEKs
   are deleted once the multicast session is completed.

   The second case to consider is when the KEKs are valid for more than
   one session.  In this case, the Net Key may also be valid for
   multiple sessions, or the Net Key may still only be valid for one
   session as in the above case.  Whether the Net Key is valid for one
   session or more than one session, the KEK will be cached.  If the Net
   Key is only valid per session, the KEKs will be used to encrypt new
   Net Keys for subsequent multicast sessions.  The deleting of group
   participants occurs as in the previous case described above,
   regardless of whether the Net Key is per session or to be used for
   multiple sessions.

   A scheme like this may be attractive to a user because it is a
   straightforward extension of certifiable public key exchange
   techniques. It may also be attractive because it does not involve
   third parties.  Only the participants who are part of the multicast
   session participate in the keying mechanism.  What makes this scheme
   so undesirable is that it will be transmission intensive as we scale






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


   up in numbers, even for the most computationally efficient
   participants, not to mention those with less capable hardware
   (tactical, wireless, etc.).  Every time the need arises to drop an
   "unauthorized" participant, a new Net Key must be distributed.

   This distribution requires a transmission from the Root to each
   remaining participant, whereby the new Net Key will be encrypted
   under the cover of each participant's unique pairwise Key Encryption
   Key (KEK).

   Note: This approach is essentially the same as one proposal to the
   Internet Engineering Task Force (IETF) Security Subworking Group [Ref
   1,2].

   Also note that there exist multiple twists to an approach like this.
   For example, instead of having the root do all N key exchanges, the
   root could pass some of this functionality (and control) to a number
   of leaves beneath him.  For example, the multicast group list could
   be split in half and the root tells one leaf to take half of the
   users and perform a key exchange with them (and then distribute the
   Net key) while the root will take care of the other half of the list.
   (The chosen leaves are thus functioning as a root and we can call
   them "subroots."  These subroots will have leaves beneath them, and
   the subroots will maintain the KEK of each leaf beneath it.)  This
   scales better than original approach as N becomes large.
   Specifically, it will require less time to set up (or rekey) the
   multicast net because the singular responsibility of performing
   pairwise key exchanges and distributing Net Key will be shared among
   multiple group participants and can be performed in parallel, as
   opposed to the root only distributing the Net Key to all of the
   participants.

   This scheme is not without its own security concerns.  This scheme
   pushes trust down to each subgroup controller - the root assumes that
   these "subroot" controllers are acting in a trustworthy way.  Every
   control element (root and subroots) must remain in the system
   throughout the multicast.  This effectively makes removing someone
   from the net (especially the subroots) harder and slower due to the
   distributed control.  When removing a participant from the multicast
   group which has functioned on behalf of the root, as a subroot, to
   distribute Net Key, additional steps will be necessary.  A new
   subroot must be delegated by the root to replace the removed subroot.
   A key exchange (to generate a new pairwise KEK) must occur between
   the new subroot and each leaf the removed subroot was responsible
   for.  A new Net Key will now be distributed from the root, to the
   subroots, and to the leaves.  Note that this last step would have
   been the only step required if the removed party was a leaf with no
   controlling responsibilities.



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


5.3   COMPLEMENTARY VARIABLE APPROACH

   Let us suppose we have N leaves.  The Root performs a public key
   exchange with each leaf i (i= 1,2, ..., N).  The Root will cache each
   pairwise KEK. Each leaf stores their own KEK.  The root would provide
   the multicast group list of participants and attributes to all users.
   Participants would accept or reject participation in the multicast
   session as described in previous sections.  The root encrypts the Net
   Key for the Multicast group to each leaf, using their own unique
   KEK(i).  (The Root either generated this Net Key himself, or
   cooperatively generated with one of the leaves as was discussed
   earlier).  In addition to the encrypted Net Key, the root will also
   encrypt something called complementary variables and send them to the
   leaves.

   A leaf will NOT receive his own complementary variable, but he will
   receive the other N-1 leaf complementary variables.  The root sends
   the Net Key and complementary variables j, where j=1,2,...,N and j
   not equal to i, encrypted by KEK(i) to each leaf. Thus, every leaf
   receives and stores N variables which are the Net key, and N-1
   complementary variables.

   Thus to cut a user from the multicast group and get the remaining
   participants back up again on a new Net Key would involve the
   following. Basically, to cut leaf number 20 out of the net, one
   message is sent out that says "cut leaf 20 from the net." All of the
   other leaves (and Root) generate a new Net Key based on the current
   Net Key and Complementary variable 20.  [Thus some type of
   deterministic key variable generation process will be necessary for
   all participants of the multicast group]. This newly generated
   variable will be used as the new Net Key by all remaining
   participants of the multicast group.  Everyone except leaf 20 is able
   to generate the new Net Key, because they have complementary variable
   20, but leaf 20 does not.

   A scheme like this seems very desirable from the viewpoint of
   transmission savings since a rekey message encrypted with each
   individual KEK to every leaf does not have to be sent to delete
   someone from the net.  In other words, there will be one plaintext
   message to the multicast group versus N encrypted rekey messages.
   There exists two major drawbacks with this scheme.  First are the
   storage requirements necessary for the (N-1) complementary variables.
   Secondly, when deleting multiple users from the multicast group,
   collusion will be a concern.  What this means is that these deleted
   users could work together and share their individual complementary
   variables to regain access to the multicast session.





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


5.4  HIERARCHICAL TREE APPROACH

   The Hierarchical Tree Approach is our recommended approach to address
   the multicast key management problem.  This approach provides for the
   following requisite features:

      1. Provides for the secure removal of a compromised user from the
         multicast group

      2. Provides for transmission efficiency

      3. Provides for storage efficiency

   This approach balances the costs of time, storage and number of
   required message transmissions, using a hierarchical system of
   auxiliary keys to facilitate distribution of new Net Key. The result
   is that the storage requirement for each user and the transmissions
   required for key replacement are both logarithmic in the number of
   users, with no background transmissions required. This approach is
   robust against collusion of excluded users. Moreover, while the
   scheme is hierarchical in nature, no infrastructure is needed beyond
   a server (e.g., a root), though the presence of such elements could
   be used to advantage (See Figure 1).