Multicast

   

IPSec is a point-to-point protocol. One side encrypts, the other decrypts, and both sides share a key or keys. There is a single recipient and single sender for each IPSec packet. In multicast, there are many recipients of a single packet, and quite often, many senders to a particular (single) multicast address. This is a completely different paradigm for IPSec. Antireplay protection cannot work if there are many senders. Data source authentication cannot work if all people in a group share a key. In addition, IKE won't work because it is designed to establish a shared key between two parties, but in multicast there must be a shared group key (or perhaps a tree of shared keys) that each recipient must have. Obviously, applying IPSec to multicast is tricky.

An IPSec SA is identified by the triple of protocol, SPI, and destination address. This address can be a multicast address. The only issue there is allocation of the SPI. In regular IPSec, it is the destination that chooses the SPI. In multicast, there is no single "destination" for a given address. Instead, the SPI is allocated by a group controller who is also, most likely, responsible for key generation and access control (more on this later when we discuss multicast key management).

So by just flipping the responsibility for SPI generation we can use IPSec to secure multicast traffic, right? Not quite. Remember that IPSec provides not only confidentiality and data integrity, it also provides source authentication and antireplay services. The latter two will fail in a multicast environment where many entities share a key and can all send packets to the same address. If everyone shares a key, all you can say about the sender of a "secured" multicast packet is that it was sent by someone in the group, not necessarily by the claimed sender. Similarly, if many people are sending packets to the same multicast address with the same SPI, there is no way to synchronize the antireplay counters so that no single counter value is used more than once and that the window could properly advance.

Source Authentication

Antireplay is something many users of multicast can live without, but source authentication of multicast traffic is not. It is critical for many multicast applications, and is a nontrivial problem that has yet to be adequately solved. Imagine a company that sells news or information. The company's reputation is based on the reliability of the information it sells. If it decided secure multicast was a way to save money and still deliver its information only to select recipients (which is similar to the motivation in setting up a VPN instead of paying for an expensive leased line), it would quickly lose its reputation and its customers, because any subscriber could forge "news" items or inject bogus information into the otherwise legitimate feed. Obviously, this problem has to be solved.

One way is to have each sender digitally sign each packet sent. This would provide nonreputable source authentication, but at a great cost. Current digital signature technologies (RSA, DSA) are too slow for bulk data protection. The bit rate of delivery would drop so drastically as to be largely unusable for most multicast applications. A speed-up can be realized by using a small exponent for an RSA key pair. This might be acceptable to certain applications for which forgery of the entire stream is a problem, but one or two packets is not. For others, though, this is still unacceptable.

Another technique described by Gennaro and Rohatgi in the proceedings of Crypto '97 uses a single public key (asymmetric) signature and a symmetrically-keyed hashing technique that takes advantage of the fact that the sender can know what the next packet it is going to send will be (Figure 12.2). This idea uses a strong digital signature on a keyed hash of the second packet appended to the first packet sent. The signed digest in the first packet is a keyed hash of the second packet and it can be checked when the second packet is received. Accompanying the second packet is a digest from a keyed hash of the third packet. If a keyed hash of the second packet (including the digest for the third packet) can validate the signature obtained in the first packet, the sender of the first packet can be unambiguously identified. Then, when the third packet is received, which carries a keyed hash digest of the fourth packet, it can be authenticated by computing a keyed hash digest and checking that against the value in the second packet, and so on.

Figure 12.2. Source Authentication of Multicast a la Gennaro and Rohatgi.

graphics/12fig02.gif

Notice that each keyed hash is over the entire next packet, including the digest of the subsequent packet. This is to prevent someone from hijacking the stream in the middle and injecting bogus packets into the stream. Of course, the requirement this places on the sender is that the sender must know all of the input prior to sending the first packet. For many situations this is unacceptable, but for some, like the multicasting of movies or software distributions, it is entirely acceptable. The sender can generate the entire stream and sends out the first packet only after the entire data set has been processed.

The only requirement on the receiver is that he or she maintain a small buffer to hold the authenticating information for the next packet.

This is a very clever idea that is extended to multisender groups in the paper by using one-time signatures. Of course, this technique has problems if a packet is lost or received out of order since the chaining technique would collapse. Chung Kei Wong and Simon Lam in the paper "Digital Signatures for Flows and Multicasts," extended this technique to adapt to unreliable communications.

Another technique for source authentication of multicast traffic (by G. Itkis, in a presentation made to the Crypto '96 conference) uses the authentication digest technique of AH, but extends it to use many digests. The idea is that for any particular sender of a group, there are n keys. Each member of the group, and therefore recipient of the traffic, is granted k of the n keys, where k < n (Figure 12.3). Each packet is sent with n digests representing a keyed hash with each of the n keys, and each recipient validates those digests that correspond to the keys he or she holds. If any of the digests for which he or she holds a key is incorrect, the packet is dropped. If they are all correct he or she must then assume the rest of the digests that were not checked are correct. Obviously, one member could forge packets to other members who shared the same keys, but given a suitably large n and a relatively small k the number of members that share the same set of keys will be small. It is possible to forge packets if a coalition of i members were to form, such that the union of all keys shared by all i members is equal to n. The probability of such a coalition forming is remote, though, because members do not have a way of learning who other members are (or of learning which members are unscrupulous enough to enter into such an illegitimate coalition) or what keys other members are holding. The drawback of this technique is the added computation on the sender of n keyed hashes and also the difficulty in determining the distribution of keys such that it will be difficult, if not impossible, for members of the group to form a forgery coalition.

Figure 12.3. Source Authentication of Multicast a la Itkis.

graphics/12fig03.gif

This idea has been subsequently incorporated into a paper "Multicast Security: A Taxonomy of Secure Multicast Protocols and Efficient Authentication Schemes" by Canetti, Garay, Itkis, Micciancio, Naor, and Pinkas, which was presented at the INFOCOM '99 conference. This paper also includes several complexity measures between this scheme and a scheme using digital signatures.

Obviously, no single method of providing source authentication of multicast is acceptable for all, or even most, applications. Much work continues to be done in this field.

Key Management

Key management is also a difficult problem in multicast security. As mentioned, IKE is designed to establish a shared key (or keys) between two peers. It does so by performing an authenticated Diffie-Hellman exchange. While it is possible to extend a Diffie-Hellman to more than two members, it becomes a computational nightmare. Also, the addition or deletion of a single member would require another n-way exchange (where n is the current number of members of the group) at great computational cost. Some new key management technique is necessary. Most multicast key management protocols use a centralized key distribution center, or centers, that provide the key to qualified entities.

Other issues affecting multicast key management are join latency it should not take prohibitively long to obtain the key(s) and receive secured multicast traffic; rekeying it should be easy to retire an old key and distribute a new one to all key members; and, forced member removal if a member of the group must be removed, the group must be rekeyed in such a way such that this member is not able to obtain the new key.

There are quite a few multicast key-management protocols. Some are specific to a multicast routing protocol while others are protocol-independent. Some construct a key distribution tree, which is congruent to a multicast (data) delivery tree, while others require no such structures.

All of the most popular methods of multicast key management share a common method of using unicast technology for initial key acquisition. A new or candidate member of a secure group uses a unicast protocol to obtain the key from a key holder or key manager. Almost all differ in who that key holder or key manager is, and where in the network that entity resides, though. They also differ in how rekeying is done; many of the key-management proposals try to optimize the time it takes to forcibly remove a member from the group.

Key Management for Multicast

Three members of the United States National Security Agency, Debby Wallner, Eric Harder, and Ryan Agee, wrote an influential paper on multicast key management and submitted it to the IETF. This document describes a wide variety of applications and explores the various architectural requirements they place on a secure multicast solution.

While the analysis of the various scenarios is quite complete (and the reader is encouraged to obtain a copy of this work), it is the architecture analysis and, most important, the recommended architecture that makes this paper important. Four possible architectures are discussed, each of which performs basically the same function, albeit in slightly differing manners.

The first is the most obvious: manual key distribution. The group key is distributed to members in some out-of-band manner without any sort of on-line key exchange. It is possible to take advantage of this single step to distribute multiple keys, each with a limited lifetime. The drawback of this approach is that it scales poorly to large or dynamic groups. It is also inadequate if forced member removal is necessary.

The next technique described is where a shared secret is established between each group member and the key holder. This shared secret can be, for instance, the result of an authenticated Diffie-Hellman exchange. This secret can be used as a key encrypting key (KEK), which can be used to distribute the shared group key to individual members. Each member would retain the secret it shares with the key distributor, but the key distributor would have to retain the secrets of all the group members to whom it has distributed the key. This is attractive due to its simplicity and the ability to implement such a system in a straightforward way. The drawback is, again, scaling. As the number of members in the group rises, so does the work required by the key distributor. It must establish a shared secret with each party, and for large groups, the key distributor could easily be overwhelmed. At the least, the key acquisition latency would be too great. Another drawback is what happens when a single member is forcibly removed. The new key would have to be individually distributed to each remaining group member. Again, the latency to rekey would be too much for large groups.

The rekey latency can be addressed by adding a "complimentary variable" to the shared KEK scheme described above. In this technique, a set of these variables is sent to each member, along with the group key (all encrypted by the KEK, of course). Each member is assigned a complimentary variable but is given the complimentary variable of every other member of the group. So for a group of n members, there will be n complimentary variables and each member j receives all variables i where i = 1,2,..., n, but i ! = j. In other words, each member knows the complimentary variable of every other member but does not know her own. To forcibly remove a member from the secure group, say "member 20," the group owner sends a message saying "remove member 20 and all members generate a new key using the existing key and the complimentary variable for member 20 (this can be done, for instance, by hashing the two together). Since member 20 did not have her own complimentary variable, she is unable to compute the new key and is, effectively, out of the group. The main drawback to this is that each time a member joins the group a new complimentary variable must be sent out to all established group members. Another drawback is that each member must store the complimentary variable of every other member of the group, and for large groups, this storage requirement can become unbearable.

In light of the deficiencies of these approaches, the technique recommended by the authors is that of a hierarchical tree. In this technique there is no one single key, there are many. The keys are maintained by the group owner by constructing and maintaining the hierarchical tree (Figure 12.4). Each node in the tree represents another key. At the root of the tree is the main group key. Each group member is a leaf of the tree and each member is given the set of keys from the root, through all intermediate nodes, to the leaf that represents itself.

Figure 12.4. The Hierarchical Tree.

graphics/12fig04.gif

To construct such a tree, the key server (who may or may not be the root of the tree) establishes a shared secret (a KEK) with each leaf node, each user. The root key and the key of the leaf's parent nodes are transmitted to it encrypted in its KEK. The tree nodes (all parts that are not leaves) are merely logical and do not represent any actual group entity. Addition of a new user entails only establishment of a KEK and then a single message containing all the keys of its parent nodes encrypted in that KEK.

Forced member removal is interesting. Imagine that the tree in Figure 12.4 should be rekeyed in such a manner that member N is unable to obtain the new key that member N is forcibly removed from the group. To do this, all keys held by user N must be renewed and distributed to all the people that need them, in this case, those that hold keys F, B, or A.

The rekey is performed bottom up. Therefore, the first key to change is key F. Before that key can be used, it must be transmitted to all those that use it, in this case O and P (remember N is being removed). Therefore, the new key F is sent to leaf O in O's key and to leaf P in P's keys. Next, B is replaced by sending it encrypted in E, the new F, and G. A is then rekeyed by sending it to all members encrypted in the new C, D, and the new B.

Rekeying is much less labor-intensive and impacts a smaller amount of members than the previous techniques. For a group of n members, the group owner must do 2 * log n key encryptions to rekey the group. In addition, the storage requirements to implement this technique are not onerous. For a tree of depth d, each user must store d+1 keys while the group owner must keep all keys.

Secure Multicast Key Distribution

A multicast key distribution protocol specific to core-based trees (CBT) is described by Tony Ballardie in RFC1949. CBT is a multicast architecture that uses central routers, called cores, to build a multicast delivery tree.

RFC1949 ties multicast key distribution to the actual joining of the secure group. Access control is applied to the multicast join and the key is distributed along with a join acknowledgment. The utility of this approach is open to debate since there is no way to insure that only group members receive multicast traffic. It is generally placed on a shared medium, after all. Given that the data is encrypted, this is generally not viewed as a problem. On the other hand, by tying key acquisition to the group join, two birds are effectively being killed with a single stone.

In RFC1949, a group access package comprised of the group key, a key encrypting key (for rekeying the group key), and security association information, is distributed by authorized routers of the distribution tree to joining nodes. Each router that is part of the CBT tree will eventually become a group key distribution center (GKDC) and has the authority to distribute a group access package to a host wishing to join the secure group.

IPSec is assumed to protect the multicast data traffic using an SA created from the group access package.

When a node wishes to join a secure CBT tree, it sends an IGMP report to the group. In this report is a token, similar to the cookies that IKE uses, which is generated by, and is unique to, the host. This token is signed by the host wishing to join the group, and therefore to acquire the group key.

The local designated router (DR) authenticates the report by checking the signature on the token. If valid and the local designated router is already a GKDC, it can perform an access control check on the host and directly distribute a group access package if the host passes. If the DR is not a GKDC, and is therefore not part of the CBT, it must form a join request and target the tree's core. The join request contains the host's token, the DR's token, and is digitally signed by the DR. The entire message is sent to the core via the next-hop router on path back to the core.

The next-hop router must then authenticate the join request and, if successful, construct a new join request with the original host's token, its own token. This new join request is digitally signed by the next-hop router and sent toward the core. This is repeated until the core, or a DR that is already a GKDC, receives the join message.

When the core (or a GKDC on the CBT) receives the join, it must authenticate the host that started this whole chain of messaging. If the host passes the access control check, it constructs a join acknowledgment message and sends it back along the path that the original join took. Just as the join was reconstructed and resigned at each hop, so must the join acknowledgment be authenticated, decrypted, reconstructed, re-encrypted, signed, and forwarded on toward the host. At each hop, the group access package, including access control information, will be retained, since each router, now part of the tree, becomes a GKDC.

This group access package is actually the access control list for the group, plus two sets of group key, plus key encrypting key, plus SA parameters. One of the sets is encrypted in the public key of the host that is the ultimate destination of the join acknowledgment and the other is encrypted in the public key of the next-hop router. The final hop is at the host, who can decrypt the access control package (since it was encrypted by the core with his public key) and recover all information necessary to create an SA to receive the multicast data.

The hop-by-hop processing required by RFC1949 will impose considerable join latency on members. As the tree is built, the need for a join request to be sent all the way to the core is mitigated, but there will, most likely, still be cases where a single request for the key (and also for membership in the group) will require several hops, and therefore several public key operations. There is also an issue with this technique necessitating storage of the group key (and the key encrypting key) in all routers that comprise the CBT. The more people, or in this case routers, that know a key, the less likely that key will remain a secret. RFC1949 is a secure and scalable method of distributing group keys, but its costs are considerable.

MKMP

A protocol called the multicast key management protocol (MKMP) has been proposed by Dan Harkins and Naganand Doraswamy (yes, the authors of this book) as a way to quickly distribute keys to members of a multicast group in a manner that can scale from small groups to large, and from dense groups to sparse. It is not bound to any key-management protocol or secure multicast framework. In this manner, it is appropriate for use in most any secure multicast deployment.

In MKMP there is a single entity, called the group key manager (or GKM) who is responsible for generating the keys used to protect the multicast data and also for generating all access control information. The GKM also decides whether to delegate key distribution authority to other entities, called group key distributors (GKDs). It is this delegation that allows MKMP to scale.

If the GKM elects not to delegate authority to distribute keys, it would resemble the second technique described by Wallner, et al, where each group member shares a secret with the key manager. In this case, the GKM must be prepared to satisfy all requests for the key. For a group that is anticipated to have not very many members, this isn't a problem. (Note that the GKM will know how large the group can become because he is constructing the access control information. He or she alone can determine who obtains the key.) For a large group, this may be a problem, because a protocol that provides mutual authentication, like MKMP, requires public key operations to do the authentication.

When key distribution delegation is desired, the GKM solicits key distributors by sending a special message to the multicast data group. This message contains the identities of the entities that the GKM desires to become key distributors, or GKDs, and is sent with the Router Alert (RFC 2113) option set (Figure 12.5). This identity can be an explicit IP address, a subnetwork, a distinguished name from a certificate, the distinguished name of an acceptable certification authority (CA), or any combination of the same. For instance, the GKM can solicit GKDs that reside in a particular subnet and have certificates that are signed by a particular CA.

Figure 12.5. Solicitation of Group Key Distributors.

graphics/12fig05.gif

Of course, initially, the multicast data distribution tree will be either nonexistent or quite small, and the solicitation message will not travel far and will most likely not be received by any of the targeted key distributors. As hosts join the group and obtain the key from the only available source the GKM the multicast tree will be constructed and the solicitation message will be able to be received by more designated key distributors.

By setting the Router Alert option on the solicitation message, all routers on the multicast distribution tree will inspect this packet. A non-MKMP-aware router will not know how to parse it and will merely forward the packet on, albeit on its slow switched path. An MKMP-aware router will be able to parse the packet and determine whether it is on the list of potential GKDs. If it is, and it desires to become a GKD, it can obtain the group key from the GKM using the MKMP's key distribution protocol. Along with the key, the GKD also obtains group access control information so it can know who is allowed to obtain the key and who is not allowed to obtain the key, and something called the group information tuple, or GIT. The GIT is a token that can be used to prove key distribution authority to host. The GIT contains the multicast data group address and the identity of the GKD, thus binding the router to the group. The GIT is signed by the GKM to prove that the router identified in the GIT as a GKD is authorized to distribute the key. Otherwise, why would a host believe a router that claims the authority to distribute keys for a specific multicast data group?

As the multicast data distribution tree is built, the solicitation messages will be received by more and more routers and therefore have a higher chance of reaching potential GKDs. For any given area, the first host that joins the group will have to obtain the key from the GKM because there will be no branch of the multicast data distribution tree for it to attach to and therefore no neighborhood GKD. This branch must be built using the underlying multicast routing protocol (PIM, CBT, etc.). But after that initial key acquisition from the GKM, the key solicitation messages will be received by routers on the multicast data distribution tree and any potential GKD in that area would receive the message and acquire the key, thereby becoming a full-fledged GKD. Subsequent requests to obtain the group key by candidate group members in that area can be made to the GKD.

Note that GKDs will therefore arise only in areas that already have multicast data group members. This is A Good Thing. There will be no unnecessary distribution of the key to entities that would not have an opportunity to distribute the key. The fewer places this group key resides, the higher the chance of it remaining secret.

A host that wishes to obtain the key must first decide from where to obtain it. From the GKM or from a neighborhood GKD? This determination is made by probing for a GKD in its immediate area. This probe takes the form of a message sent to a special multicast address, the ALL_MKMP_DEVICES group, in a flood-and-prune-style with administrative scoping to prevent it from being sent to too wide an area. This flood-and-prune method of probing will result in a temporal state being retained in routers that must flood this packet out of its other interfaces. For routers that run multicast routing protocols like PIM this won't be a problem, but for other protocols, like DVMPR, this could be a problem because the state will be retained for upward of two hours.

If a router receives a probe for a group for which it is a GKD, it must respond to the sending host with a probe response indicating that it is a duly authorized GKD for the particular multicast data group. This response must therefore contain the GIT that the GKD received from the GKM at the time it obtained the group key.

A host that receives a response to its probe can obtain the key from the router that responded, provided, of course, that the GIT is authentic and has been signed by the GKM. A host that receives no response to its probe must obtain the key from the GKM itself.

In this manner key distribution scales with the group for which the key is being distributed.

MKMP also defines a key distribution protocol[5] that allows for the key to be distributed in a mutually authenticated manner. It contains a liveness proof to prevent replay attacks against the key holder. It also distributes the key with a minimum of expensive public key operations. Key distribution takes place between a key acquirer and key holder (either the GKM or a GKD to which this responsibility has been delegated). The protocol uses public key cryptography to encrypt a random number of the key acquirer's choosing. This random number is encrypted in the public key of the key holder and transmitted to the key holder. The key holder can then decrypt the random number and generate another, seemingly random, number by taking the exclusive-or (XOR) of the secret key and the key acquirer's random number. This new number, the result of the XOR operation, is encrypted in the public key of the key acquirer and transmitted back. The key acquirer, upon receipt, can decrypt this number and take the XOR of it with his or her original random number and construct the secret key. Each side must also compute an authenticating hash that contains cookies (when the group key is requested both the GKM and GKDs generate a cookie, similar to an IKE cookie, unique to the requestor) and state from the exchange that binds the parties to the exchange and proves that they are active participants in the exchange.

[5] The key distribution protocol itself has been patented by Cisco Systems, Inc. but will be licensed for use in MKMP in a standard, nondiscriminatory manner. The fee, if any, for its use in MKMP will be nominal.

MKMP assumes that IPSec will be used to secure the actual transmission of the multicast data. It therefore also provides a mechanism for the key holder to distribute security association information to the key requestor along with the key.

MKMP can scale, but its ability to scale depends on proper delegation of distribution authority. If the GKM makes a poor choice of routers to whom it solicits key distribution authority, it can end up servicing most, if not all, requests for the key. On the plus side, MKMP distributes the key with only two public key operations on each side. Contrast this with the technique of using an authenticated Diffie-Hellman exchange to establish the shared key between the member and key holder, which would require two exponentiations for the Diffie-Hellman and probably two public key operations for the authentication. On the downside, the flood-and-prune technique MKMP employs to probe for GKDs may be inappropriate for certain multicast data routing protocols.

There are quite a few protocols to distribute a group key, many more than are described here. Each has its benefits and costs that must be weighed when choosing a protocol to use. Because no one protocol is satisfactory, work continues on new protocols and also on improving existing protocols by lessening the impact of, or eliminating, their weaknesses. The descriptions of these protocols may change in the future.

Multicast security is being addressed in the IRTF (a sister of the IETF that does the Research prior to the Engineering, it's the Internet Research Task Force) because the issues with it are so large that it is necessary to do some research prior to beginning the engineering of a solution. The IRTF working group is called SMuG, for Secure Multicast Group. This group is chartered to deal with all aspects of multicast security and introduces techniques and protocols back into the Multicast Security (MSEC) Working Group of the IETF where solutions based on IRTF research are engineered to become standard protocols.


   
Top


IPSec(c) The New Security Standard for the Internet, Intranets, and Virtual Private Networks
IPSec (2nd Edition)
ISBN: 013046189X
EAN: 2147483647
Year: 2004
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net