diff options
Diffstat (limited to 'doc/rfc/rfc1949.txt')
| -rw-r--r-- | doc/rfc/rfc1949.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc1949.txt b/doc/rfc/rfc1949.txt new file mode 100644 index 0000000..00d0691 --- /dev/null +++ b/doc/rfc/rfc1949.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group A. Ballardie +Request for Comments: 1949 University College London +Category: Experimental May 1996 + + + Scalable Multicast Key Distribution + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + The benefits of multicasting are becoming ever-more apparent, and its + use much more widespread. This is evident from the growth of the + MBONE [1]. Providing security services for multicast, such as traffic + integrity, authentication, and confidentiality, is particularly + problematic since it requires securely distributing a group (session) + key to each of a group's receivers. Traditionally, the key + distribution function has been assigned to a central network entity, + or Key Distribution Centre (KDC), but this method does not scale for + wide-area multicasting, where group members may be widely-distributed + across the internetwork, and a wide-area group may be densely + populated. + + Even more problematic is the scalable distribution of sender-specific + keys. Sender-specific keys are required if data traffic is to be + authenticated on a per-sender basis. + + This memo provides a scalable solution to the multicast key + distribution problem. + + NOTE: this proposal requires some simple support mechanisms, which, + it is recommended here, be integrated into version 3 of IGMP. This + support is described in Appendix B. + +1. Introduction + + Growing concern about the integrity of Internet communication [13] + (routing information and data traffic) has led to the development of + an Internet Security Architecture, proposed by the IPSEC working + group of the IETF [2]. The proposed security mechanisms are + implemented at the network layer - the layer of the protocol stack at + which networking resources are best protected [3]. + + + + +Ballardie Experimental [Page 1] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + Unlike many network layer protocols, the Core Based Tree (CBT) + multicast protocol [4] makes explicit provision for security; it has + its own protocol header, unlike existing IP multicast schemes + [10,11], and other recently proposed schemes [12]. + + In this document we describe how the CBT multicast protocol can + provide for the secure joining of a CBT group tree, and how this same + process can provide a scalable solution to the multicast key + distribution problem. These security services are an integral part + of the CBT protocol [4]. Their use is optional, and is dependent on + each individual group's requirements for security. Furthermore, the + use of the CBT multicast protocol for multicast key distribution does + not preclude the use of other multicast protocols for the actual + multicast communication itself, that is, CBT need only be the vehicle + with which to distribute keys. + + Secure joining implies the provision for authentication, integrity, + and optionally, confidentiality, of CBT join messages. The scheme we + describe provides for the authentication of tree nodes (routers) and + receivers (end-systems) as part of the tree joining process. Key + distribution (optional) is an integral part of secure joining. + + Network layer multicast protocols, such as DVMRP [7] and M-OSPF [9], + do not have their own protocol header(s), and so cannot provision for + security in themselves; they must rely on whatever security is + provided by IP itself. Multicast key distribution is not addressed to + any significant degree by the new IP security architecture [2]. + + The CBT security architecture is independent of any particular + cryptotechniques, although many security services, such as + authentication, are easier if public-key cryptotechniques are + employed. + + What follows is an overview of the CBT multicasting. The description + of our proposal in section 6.1 assumes the reader is reasonably + familiar with the CBT protocol. Details of the CBT architecture and + protocol can be found in [7] and [4], respectively. + +2. Overview of BCT Multicasting + + CBT is a new architecture for local and wide-area IP multicasting, + being unique in its utilization of just one shared delivery tree per + group, as opposed to the source-based delivery tree approach of + existing IP multicast schemes, such as DVMRP and MOSPF. + + A shared multicast delivery tree is built around several so-called + core routers. A group receiver's local multicast router is required + to explicitly join the corresponding delivery tree after receiving an + + + +Ballardie Experimental [Page 2] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + IGMP [8] group membership report over a directly connected interface. + A CBT join message is targeted at one of the group's core routers. + The resulting acknowledgement traverses the reverse-path of the join, + resulting in the creation of a tree branch. Routers along these + branches are called non-core routers for the group, and there exists + a parent-child relationship between adjacent routers along a branch + of the same tree (group). + +3. How the CBT Architecture Complements Security + + The CBT architecture requires "leaf" routers to explicitly join a CBT + tree. Hence, CBT is not data driven; the ack associated with a join + "fixes" tree state in the routers that make up the tree. This so- + called "hard state" remains until the tree re-configures, for + example, due to receivers leaving the group, or because an upstream + failure has occurred. The CBT protocol incorporates mechanisms + enabling a CBT tree to repair itself in the event of the latter. + + As far as the establishment of an authenticated multicast + distribution tree is concerned, DVMRP, M-OSPF, and PIM, are at a + disadvan- tage; the nature of their "soft state" means a delivery + tree only exists as long as there is data flow. Also, routers + implementing a multicast protocol that builds its delivery tree based + on a reverse-path check (like DVMRP and PIM dense mode) cannot be + sure of the previous-hop router, but only the interface a multicast + packet arrived on. + + These problems do not occur in the CBT architecture. CBT's hard state + approach means that all routers that make up a delivery tree know who + their on-tree neighbours are; these neighbours can be authenticated + as part of delivery tree set-up. As part of secure tree set-up, + neighbours could exchange a secret packet handle for inclusion in the + CBT header of data packets exchanged between those neighbours, + allowing for the simple and efficient hop-by-hop authentication of + data packets (on-tree). + + The presence of tree focal points (i.e. cores) provides CBT trees + with natural authorization points (from a security viewpoint) -- the + formation of a CBT tree requires a core to acknowledge at least one + join in order for a tree branch to be formed. Thereafter, + authorization and key distribution capability can be passed on to + joining nodes that are authenticated. + + In terms of security, CBT's hard state approach offers several + additional advantages: once a multicast tree is established, tree + state maintained in the routers that make up the tree does not time + out or change necessarily to reflect underlying unicast topology. + The security implications of this are that nodes need not be subject + + + +Ballardie Experimental [Page 3] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + to repeated authentication subsequent to a period of inactivity, and + tree nodes do not need to re-authenticate themselves as a result of + an underlying unicast topology change, unless of course, an network + (node) failure has occurred. + + Hard-state protocol mechanisms are often thought of as being less + fault tolerant than soft-state schemes, but there are pros and cons + to both approaches; we see here that security is one of the pros. + +4. The Multicast Key Distribution Problem + + We believe that multicast key distribution needs to be combined with + group access control. Without group access control, there is no point + in employing multicast key distribution, since, if there are no group + restrictions, then it should not matter to whom multicast information + is divulged. + + There are different ways of addressing group access control. The + group access control we describe requires identifying one group + member (we suggest in [14] that this should be the group initiator) + who has the ability to create, modify and delete all or part of a + group access control list. The enforcement of group access control + may be done by a network entity external to the group, or by a group + member. + + The essential problem of distributing a session (or group) key to a + group of multicast receivers lies in the fact that some central key + management entity, such as a key distribution centre (KDC) (A Key + Distribution Centre (KDC) is a network entity, usually residing at a + well-known address. It is a third party entity whose responsibility + it to generate and distribute symmetric key(s) to peers, or group + receivers in the case of multicast, wishing to engage in a "secure" + communication. It must therefore be able to identify and reliably + authenticate requestors of symmetric keys.), must authenticate each + of a group's receivers, as well as securely distribute a session key + to each of them. This involves encrypting the relevant message n + times, once with each secret key shared between the KDC and + corresponding receiver (or alternatively, with the public key of the + receiver), before multicasting it to the group. (Alternatively, the + KDC could send an encrypted message to each of the receivers + individually, but this does not scale either.) Potentially, n may be + very large. Encrypting the group key with the secret key (of a + secret-public key pair) of the KDC is not an option, since the group + key would be accessible to anyone holding the KDC's public key, and + public keys are either well-known or readily available. In short, + existing multicast key distribution methods do not scale. + + + + + +Ballardie Experimental [Page 4] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + The scaling problem of secure multicast key distribution is + compounded for the case where sender-specific keys need to be + distributed to a group. This is required for sender-specific + authentication of data traffic. It is not possible to achieve per- + sender authentication, given only a group session key. + + Recently a proposal has emerged, called the Group Key Management + Protocol (GKMP) [15]. This was designed for military networks, but + the authors have demonstrated how the architecture could be applied + to a network like the Internet, running receiver-oriented multicast + applications. + + GKMP goes a considerable way to addressing the problems of multicast + key distribution: it does not rely on a centralised KDC, but rather + places the burden of key management on a group member(s). This is the + approach adopted by the CBT solution, but our solution can take this + distributed approach further, which makes our scheme that much more + scalable. Furthermore, our scheme is relatively simple. + + The CBT model for multicast key distribution is unique in that it is + integrated into the CBT multicast protocol itself. It offers a + simple, low-cost, scalable solution to multicast key distribution. We + describe the CBT multicast key distribution approach below. + +5. Multicast Security Associations + + The IP security architecture [2] introduces the concept of "Security + Associations" (SAs), which must be negotiated in advance during the + key management phase, using a protocol such as Photuris [20], or + ISAKMP [21]. A Security Association is normally one-way, so if two- + way communication is to take place (e.g. a typical TCP connection), + then two Security Associations need to be negotiated. During the + negotiation phase, the destination system normally assigns a Security + Parameter Index to the association, which is used, together with the + destination address (or, for the sender, the sender's user-id) to + index into a Security Association table, maintained by the + communicating parties. This table enables those parties to index the + correct security parameters pertinent to an association. The + security association parameters include authentication algorithm, + algorithm mode, cryptographic keys, key lifetime, sensitivity level, + etc. + + The establishment of Security Associations (SA) for multicast + communication does not scale using protocols like Photuris, or + ISAKMP. This is why it is often assumed that a multicast group will + be part of a single Security Association, and hence share a single + SPI. It is assumed that one entity (or a pair of entities) creates + the SPI "by some means" (which may be an SA negotiation protocol, + + + +Ballardie Experimental [Page 5] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + like [20] and [21]), which is then simply multicast, together with + the SA parameters, to the group for subsequent use. However, this + precludes multicast receivers from performing sender-specific origin + authentication; all a receiver can be sure of is that the sender is + part of the multicast Security Association. + + We advocate that the primary core, either alone, or in conjunction + with the group initiator, establish the security parameters to be + used in the group communication. These are distributed as part of the + secure join process. Thereafter, individual senders can distribute + their own key and security parameters to the group. In the case of + the latter, there are two cases to consider: + + + the sender is already a group member. In this case, the sender + can decide upon/generate its own security parameters, and multi- + cast them to the group using the current group session key. + + + the sender is not a group member. In this case, before the + sender begins sending, it must first negotiate the security + parameters with the primary core, using a protocol such as Pho- + turis [20] or ISAKMP [21]. Once completed, the primary core + multicasts (securely) the new sender's session key and security + parameters to the group. + + Given that we assume the use of asymmetric cryptotechniques + throughout, this scheme provides a scalable solution to multicast + origin authentication. + + Sender-specific keys are also discussed in section 8. + +6. The CBT Multicast Key Distribution Model + + The security architecture we propose allows not only for the secure + joining of a CBT multicast tree, but also provides a solution to the + multicast key distribution problem [16]. Multicast key distribution + is an optional, but integral, part of the secure tree joining + process; if a group session key is not required, its distribution may + be omitted. + + The use of CBT for scalable multicast key distribution does not + preclude the use of other multicast protocols for the actual + multicast communication. CBT could be used solely for multicast key + distribution -- any multicast protocol could be used for the actual + multicast communication itself. + + The model that we propose does not rely on the presence of a + centralised KDC -- indeed, the KDC we propose need not be dedicated + to key distribution. We are proposing that each group have its own + + + +Ballardie Experimental [Page 6] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + group key distribution centre (GKDC), and that the functions it + provides should be able to be "passed on" to other nodes as they join + the tree. Hence, our scheme involves truly distributed key + distribution capability, and is therefore scalable. It does not + require dedicated KDCs. We are proposing that a CBT primary core + initially take on the role of a GKDC. + +6.1 Operational Overview + + When a CBT group is created, it is the group initiator's + responsibility to create a multicast group access control list (ACL) + [14]. It is recommended that this list is a digitally signed + "document", the same as (or along the lines of) an X.509 certificate + [9], such that it can be authenticated. The group initiator + subsequently unicasts the ACL to the primary core for the group. This + communication is not part of the CBT protocol. The ACL's digital + signature ensures that it cannot be modified in transit without + detection. If the group membership itself is sensitive information, + the ACL can be additionally encrypted with the public key of the + primary core before being sent. The ACL can be an "inclusion" list + or an "exclusion" list, depending on whether group membership + includes relatively few, or excludes relatively few. + + The ACL described above consists of group membership (inclusion or + exclusion) information, which can be at the granularity of hosts or + users. How these granularities are specified is outside the scope of + this document. Additionally, it may be desirable to restrict key + distribution capability to certain "trusted" nodes (routers) in the + network, such that only those trusted nodes will be given key + distribution capability should they become part of a CBT delivery + tree. For this case, an additional ACL is required comprising + "trusted" network nodes. + + The primary core creates a session key subsequent to receiving and + authenticating the message containing the access control list. The + primary core also creates a key encrypting key (KEK) which is used + for re-keying the group just prior to an old key exceeding its life- + time. This re-keying strategy means that an active key is less + likely to become compromised during its lifetime. + + The ACL(s), group key, and KEK are distributed to secondary cores as + they become part of the distribution tree. + + Any tree node with this information can authenticate a joining + member, and hence, secure tree joining and multicast session key + distribution are truly distributed across already authenticated tree + nodes. + + + + +Ballardie Experimental [Page 7] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + +6.2 Integrated Join Authentication and Multicast Key Distribution + + For simplicity, in our example we assume the presence of an + internetwork-wide asymmetric key management scheme, such as that + proposed in [17]. However, we are not precluding the use of + symmetric cryptographic techniques -- all of the security services we + are proposing, i.e. integrity, authentication, and confidentiality, + can all be achieved using symmetric cryptography, albeit a greater + expense, e.g. negotiation with a third party to establish pairwise + secret keys. For these reasons, we assume that a public (asymmetric) + key management scheme is globally available, for example, through the + Domain Name System (DNS) [17] or World Wide Web [18]. + + NOTE: given the presence of asymmetric keys, we can assume digital + signatures provide integrity and origin authentication services + combined. + + The terminology we use here is described in Appendix A. We formally + define some additional terms here: + + + grpKey: group key used for encrypting group data traffic. + + + ACL: group access control list. + + + KEK: key encrypting key, used for re-keying a group with a new + group key. + + + SAparams: Security Association parameters, including SPI. + + + group access package (grpAP): sent from an already verified tree + node to a joining node. + + [token_sender, [ACL]^SK_core, {[grpKey, KEK, + SAparams]^SK_core}^PK_origin-host, + {[grpKey, KEK, SAparams]^SK_core}^PK_next-hop]^SK_sender + + NOTE: SK_core is the secret key of the PRIMARY core. + + As we have already stated, the elected primary core of a CBT tree + takes on the initial role of GKDC. In our example, we assume that a + group access control list has already been securely communicated to + the primary core. Also, it is assumed the primary core has already + participated in a Security Association estabishment protocol [20,21], + and thus, holds a group key, a key-encrypting key, and an SPI. + + NOTE, there is a minor modification required to the CBT protocol + [4], which is as follows: when a secondary core receives a join, + instead of sending an ack followed by a re-join to the primary, + + + +Ballardie Experimental [Page 8] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + the secondary forwards the join to the primary; the ack travels + from the primary (or intermediate on-tree router) back to the join + origin. All routers (or only specific routers) become GKDCs after + they receive the ack. + + We now demonstrate, by means of an example, how CBT routers join a + tree securely, and become GKDCs. For clarity, in the example, it is + assumed all routers are authorised to become GKDCs, i.e. there is no + trusted-router ACL. + + In the diagram below, only one core (the primary) is shown. The + process of a secondary joining the primary follows exactly what we + describe here. + + In the diagram, host h wishes to join multicast group G. Its local + multicast router (router A) has not yet joined the CBT tree for the + group G. + + b b b-----b + \ | | + \ | | + b---b b------b + / \ / KEY.... + / \/ + b C C = Core (Initial Group Key Dist'n Centre) + / \ A, B, b = non-core routers + / \ + / \ ======= LAN where host h is located + B b------b + \ + \ NOTE: Only one core is shown, but typically +host h A a CBT tree is likely to comprise several. + o | +===================== + + Figure 1: Example of Multicast Key Distribution using CBT + + A branch is created as part of the CBT secure tree joining process, + as follows: + + + Immediately subsequent to a multicast application starting up on + host h, host h immediately sends an IGMP group membership + report, addressed to the group. This report is not suppressible + (see Appendix B), like other IGMP report types, and it also + includes the reporting host's token, which is digitally signed + + h --> DR (A): [[token_h]^SK_h, IGMP group membership report] + + + + +Ballardie Experimental [Page 9] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + (A host's token differs in two respects compared with tokens + defined in [9]. To refresh, a token assists a recipient in the + verification process, and typically contains: recipient's + unique identity, a timestamp, and a pseudo-random number. A + token is also usually digitally signed by its originator. + Firstly, A host's token does not contain the intended + recipient's identity, since this token may need to traverse + several CBT routers before reaching a GKDC. A host does not + actually know which router, i.e. GKDC, will actually + acknowledge the join that it invoked. Secondly, the host's + token is digitally signed -- this is usual for a token. + However, tokens generated by routers need not be explicitly + digitally signed because the JOIN-REQUESTs and JOIN-ACKs that + carry them are themselves digitally signed.) + + + In response to receiving the IGMP report, the local designated + router (router A) authenticates the host's enclosed token. If + successful, router A formulates a CBT join-request, whose target + is core C (the primary core). Router A includes its own token in + the join, as well as the signed token received from host h. The + join is digitally signed by router A. + + NOTE 1: router A, like all CBT routers, is configured with the + unicast addresses of a prioritized list of cores, for different + group sets, so that joins can be targeted accordingly. + + NOTE 2: the host token is authenticated at most twice, once by + the host's local CBT router, and once by a GKDC. If the local + router is already a GKDC, then authentication only happens once. + If the local router is not already a GKDC, a failed authentica- + tion check removes the overhead of generating and sending a CBT + join-request. + + Router A unicasts the join to the best next-hop router on the + path to core C (router B). + + A --> B: [[token_A], [token_h]^SK_h, JOIN-REQUEST]^SK_A + + + B authenticates A's join-request. If successful, B repeats the + previous step, but now the join is sent from B to C (the pri- + mary, and target), and the join includes B's token. Host h's + token is copied to this new join. + + B --> C: [[token_B], [token_h]^SK_h, JOIN-REQUEST]^SK_B + + + C authenticates B's join. As the tree's primary authorization + point (and GKDC), C also authenticates host h, which triggered + the join process. For this to be successful, host h must be + + + +Ballardie Experimental [Page 10] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + included in the GKDC's access control list for the group. If h + is not in the corresponding access control list, authentication + is redundant, and a join-nack is returned from C to B, which + eventually reaches host h's local DR, A. + + Assuming successful authentication of B and h, C forms a group + access package (grpAP), encapsulates it in a join-ack, and digi- + tally signs the complete message. C's token, host h's signed + token, a signed ACL, and two (group key, KEK) pairs are included + in the group access package; one for the originating host, and + one for the next-hop CBT router to which the join-ack is des- + tined. Each key pair is digitally signed by the issuer, i.e. the + primary core for the group. The host key pair is encrypted using + the public key of the originating host, so as to be only deci- + pherable by the originating host, and the other key pair is + encrypted using the public key of the next-hop router to which + the ack is destined -- in this case, B. Host h's token is used + by the router connected to the subnet where h resides so as to + be able to identify the new member. + + C --> B: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_C + + + B authenticates the join-ack from C. B extracts its encrypted + key pair from the group access package, decrypts it, authenti- + cates the primary core, and stores the key pair in encrypted + form, using a local key. B also verifies the digital signature + included with the access control list. It subsequently stores + the ACL in an appropriate table. The originating host key pair + remains enciphered. + + The other copy of router B's key pair is taken and deciphered + using its secret key, and immediately enciphered with the public + key of next-hop to which a join-ack must be passed, i.e. router + A. A group access package is formulated by B for A. It contains + B's token, the group ACL (which is digitally signed by the pri- + mary core), a (group key, KEK) pair encrypted using the public + key of A, and the originating host's key pair, already + encrypted. The group access package is encapsulated in a join- + ack, the complete message is digitally signed by B, then for- + warded to A. + + B --> A: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_B + + + A authenticates the join-ack received from B. A copy of the + encrypted key pair that is for itself is extracted from the + group access package and deciphered, and the key issuer (primary + core) is authenticated. If successful, the enciphered key pair + is stored by A. The digital signature of the included access + + + +Ballardie Experimental [Page 11] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + control list is also verified, and stored in an appropriate + table. The key pair encrypted for host h is extracted from the + group access package, and is forwarded directly to host h, which + is identified from the presence of its signed token. On + receipt, host h decrypts the key pair for subsequent use, and + stores the SA parameters in its SA table. + + A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h] + + Going back to the initial step of the tree-joining procedure, if the + DR for the group being joined by host h were already established as + part of the corresponding tree, it would already be a GKDC. It would + therefore be able to directly pass the group key and KEK to host h + after receiving an IGMP group membership report from h: + + A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h] + + If paths, or nodes fail, a new route to a core is gleaned as normal + from the underlying unicast routing table, and the re-joining process + (see [4]) occurs in the same secure fashion. + +7. A Question of Trust + + The security architecture we have described, involving multicast key + distribution, assumes that all routers on a delivery tree are trusted + and do not misbehave. A pertinent question is: is it reasonable to + assume that network routers do not misbehave and are adequately + protected from malicious attacks? + + Many would argue that this is not a reasonable assumption, and + therefore the level of security should be increased to discount the + threat of misbehaving routers. As we described above, routers + periodically decrypt key pairs in order to verify them, and/or re- + encrypt them to pass them on to joining neighbour routers. + + In view of the above, we suggest that if more stringent security is + required, the model we presented earlier should be slightly amended + to accommodate this requirement. However, depending on the security + requirement and perceived threat, the model we presented may be + acceptable. + + We recommend the following change to the model already presented + above, to provide a higher level of security: + + All join-requests must be authenticated by a core router, i.e. a join + arriving at an on-tree router must be forwarded upstream to a core if + the join is identified as being a "secure" join (as indicated by the + presence of a signed host token). + + + +Ballardie Experimental [Page 12] + +RFC 1949 Scalable Multicast Key Distribution May 1996 + + + 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: A.Ballardie@cs.ucl.ac.uk + +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] + |