rfc1949.txt

RFC 的详细文档！

   The implication of this is that key distribution capability remains
   with the core routers and is not distributed to non-core routers
   whose joins have been authenticated. Whilst this makes our model
   somewhat less distributed than it was before, the concept of key
   distribution being delegated to the responsibility of individual
   groups remains.  Our scheme therefore retains its attractiveness over
   centralized schemes.

8.  The Multicast Distribution of Sender-Specific Keys

   Section 5, in part, discussed the scalable distribution of sender-
   specific keys and sender-specific security parameters to a multicast
   group, for both member-senders, and non-member senders. If asymmetric
   cryptotechniques are employed, this allows for sender-specific origin
   authentication.

   For member-senders, the following message is multicast to the group,
   encrypted using the current group session key, prior to the new
   sender transmitting data:

            {[sender_key, senderSAparams]^SK_sender}^group_key

   Non-member senders must first negotiate (e.g. using Photuris or
   ISAKMP) with the primary core, to establish the security association
   parameters, and the session key, for the sender.  The sender, of
   course, is subject to access control at the primary.  Thereafter, the
   primary multicasts the sender-specific session key, together with
   sender's security parameters to the group, using the group's current
   session key.  Receivers are thus able to perform origin
   authentication.

                           Photuris or ISAKMP
             1. sender <----------------------> primary core

          2. {[sender_key, senderSAparams]^SK_primary}^group_key

   For numerous reasons, it may be desirable to exclude certain group
   members from all or part of a group's communication.  We cannot offer
   any solution to providing this capability, other than requiring new
   keys to be distributed via the establishment of a newly-formed group
   (CBT tree).










Ballardie                     Experimental                     [Page 13]

RFC 1949          Scalable Multicast Key Distribution           May 1996


9.  Summary

   This memo has offered a scalable solution to the multicast key
   distribution problem. Our solution is based on the CBT architecture
   and protocol, but this should not preclude the use of other multicast
   protocols for secure multicast communication subsequent to key
   distribution. Furthermore, virtually all of the functionality present
   in our solution is in-built in the secure version of the CBT
   protocol, making multicast key distribution an optional, but integral
   part, of the CBT protocol.









































Ballardie                     Experimental                     [Page 14]

RFC 1949          Scalable Multicast Key Distribution           May 1996


Appendix A

   The following terminology is used throughout this document:

   +    PK_A indicates the public key of entity A.

   +    SK_A indicates the secret key of entity A. The secret key can be
        used by a sender to digitally sign a digest of the message,
        which is computed using a strong, one-way hash function, such as
        MD5 [19].

   +    Unencrypted messages will appear enclosed within square brack-
        ets, e.g. [X, Y, Z]. If a message is digitally signed, a super-
        script will appear outside the right hand bracket, indicating
        the message signer.  Encrypted messages appear enclosed within
        curly braces, with a superscript on the top right hand side out-
        side the closing curly brace indicating the encryption key, e.g.
        {X, Y, Z}^{PK_A}.

   +    a token is information sent as part of a strong authentication
        exchange, which aids a receiver in the message verification pro-
        cess. It consists of a timestamp, t (to demonstrate message
        freshness), a random, non-repeating number, r (to demonstrate
        message originality), and the unique name of the message
        recipient (to demonstrate that the message is indeed intended
        for the recipient).  A digital signature is appended to the
        token by the sender (which allows the recipient to authenticate
        the sender). The token is as follows:

             [t_A, r_A, B]^{SK_A} --  token sent from A to B.

   +    A --> B:  -- denotes a message sent from A to B.

Appendix B

   The group access controls described in this document require a few
   simple support mechanisms, which, we recommend, be integrated into
   version 3 of IGMP. This would be a logical inclusion to IGMP, given
   that version 3 is expected to accommodate a variety of multicast
   requirements, including security. Furthermore, this would remove the
   need for the integration of a separate support protocol in hosts.

   To refresh, IGMP [8] is a query/response multicast support protocol
   that operates between a multicast router and attached hosts.

   Whenever an multicast application starts on a host, that host
   generates a small number of IGMP group membership reports in quick
   succession (to overcome potential loss). Thereafter, a host only



Ballardie                     Experimental                     [Page 15]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   issues a report in response to an IGMP query (issued by the local
   multicast router), but only if the host has not received a report for
   the same group (issued by some other host on the same subnet) before
   the host's IGMP random response timer expires. Hence, IGMP,
   incorporates a report "suppression" mechanism to help avoid "IGMP
   storms" on a subnet, and generally conserve bandwidth.

   We propose that IGMP accommodate "secure joins" - IGMP reports that
   indicate the presence of a digitally signed host (or user) token.
   These report types must not be suppressible, as is typically the case
   with IGMP reports; it must be possible for each host to independently
   report its group presence to the local router, since a GKDC bases its
   group access control decision on this information.

   This functionality should not adversely affect backwards
   compatibility with earlier versions of IGMP that may be present on
   the same subnet; the new reports will simply be ignored by older IGMP
   versions, which thus continue to operate normally.

Security Considerations

   Security issues are discussed throughout this memo.

Author's Address

   Tony Ballardie,
   Department of Computer Science,
   University College London,
   Gower Street,
   London, WC1E 6BT,
   ENGLAND, U.K.

   Phone: ++44 (0)71 419 3462
   EMail: [e-mail]

References

   [1] MBONE, The Multicast BackbONE; M. Macedonia and D. Brutzman;
   available from http://www.cs.ucl.ac.uk/mice/mbone_review.html.

   [2] R. Atkinson. Security Architecture for the Internet Protocol; RFC
   1825, SRI Network Information Center, August 1995.

   [3] D. Estrin and G. Tsudik. An End-to-End Argument for Network Layer,
   Inter-Domain Access Controls; Journal of Internetworking & Experience,
   Vol 2, 71-85, 1991.





Ballardie                     Experimental                     [Page 16]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   [4] A. Ballardie, S. Reeve, N. Jain. Core Based Tree (CBT) Multicast -
   Protocol Specification; Work in Progress, 1996. Available from:
   ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-spec-XX.txt.

   [5] R. Atkinson. IP Authentication Header; RFC 1826, SRI Network
   Information Center, August 1995.

   [6] R. Atkinson. IP Encapsulating Security Payload; RFC 1827, SRI Net-
   work Information Center, August 1995.

   [7] A. Ballardie. Core Based Tree (CBT) Multicast Architecture; Work
   in progress, 1996. Available from:
   ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-arch-XX.txt

   [8] W. Fenner. Internet Group Management Protocol, version 2 (IGMPv2),
   Work in progress, 1996.

   [9] CCITT Data Communication Networks Directory (Blue Book). Recommen-
   dation X.509, Authentication Framework.

   [10] T. Pusateri. Distance-Vector Multicast Routing Protocol (DVMRP)
   version 3. Working draft, February 1996.

   [11] J. Moy. Multicast Extensions to OSPF; RFC 1584, SRI Network
   Information Center, March 1994.

   [12] D. Estrin et al. Protocol Independent Multicast, protocol specif-
   ication; Work in progress, January 1996.

   [13] R. Braden, D. Clark, S. Crocker and C. Huitema. Security in the
   Internet Architecture. RFC 1636, June 1994.

   [14] A. Ballardie and J. Crowcroft. Multicast-Specific Security
   Threats and Counter-Measures. In ISOC Symposium on Network and Distri-
   buted System Security, February 1995.

   [15] H. Harney, C. Muckenhirn, and T. Rivers. Group Key Management
   Protocol (GKMP) Architecture. Working draft, 1994.

   [16] N. Haller and R. Atkinson. RFC 1704, On Internet Authentication.
   SRI Network Information Center, October 1994.

   [17] C. Kaufman and D. Eastlake. DNS Security Protocol Extensions.
   Working draft, January 1996.

   [18] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, A.
   Secret.  The World Wide Web. Communications of the ACM, 37(8):76-82,
   August 1994.



Ballardie                     Experimental                     [Page 17]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   [19] R. Rivest. RFC 1321, The MD-5 Message Digest Algorithm, SRI Net-
   work Information Center, 1992.

   [20] P. Karn, W. Simpson. The Photuris Session Key Management Proto-
   col; Working draft, January 1996.

   [21] D. Maughan, M. Schertler. Internet Security Association and Key
   Management Protocol; Working draft, November 1995.











































Ballardie                     Experimental                     [Page 18]