INTERNET-DRAFT HASM Secure Multicast System Brian Coan Expires April 2002 Vikram Kaul Sanjai Narain William Stephens Telcordia Technologies, Inc. November 2001 HASM: Hierarchical Application-Level Secure Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The HASM system addresses some of the current limitations of end-to-end secure multicast. Specifically, the techniques used in HASM can achieve: (1) multiple autonomous administrative units, each with its own locally-managed authentication and authorization server, (2) efficiency in rekeying portions of a multicast group by using network elements to translate between keys (all without trusting any single network element to securely manage message text in the clear), and (3) defense against denial-of-service attacks by using a secure extension of IGMP. The HASM system makes use of (1) network support, including extensions to the Internet Group Management Protocol (IGMP), extended firewall functionality, and router support for encryption and decryption and (2) host operating system support, specifically extensions to IGMP. Coan et al. [Page 1] INTERNET-DRAFT HASM Secure Multicast System November 2001 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Multiple Autonomous Administrative Domains . . . . . . . . . . . 5 3 Network Support for Key Translation . . . . . . . . . . . . . . . 8 3.1 Maintaining Local Keys using Commutative Encryption . . . . 8 3.2 Maintaining Local Keys using Standard Encryption . . . . . 9 3.3 Operation of Both Solutions . . . . . . . . . . . . . . . . 9 4 Secure IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 IGMP and Multicast Routing . . . . . . . . . . . . . . . 10 4.2 Security Threats . . . . . . . . . . . . . . . . . . . . 12 4.3 Security Protocols . . . . . . . . . . . . . . . . . . . 13 4.4 IGMP Security Designs . . . . . . . . . . . . . . . . . . 14 4.4.1 Design 0: Baseline . . . . . . . . . . . . . . . 15 4.4.2 Design 1: Receiver Authorization . . . . . . . . 16 4.4.3 Design 2: Sender and Receiver Authorization . . . 17 4.4.4 Design 3: Fine Grained Authentication and Authorization . . . . . . . . . . . . . 19 4.4.5 Summary of Design Choices . . . . . . . . . . . . . 20 5 Implementation Status . . . . . . . . . . . . . . . . . . . . . 20 5.1 HASM Client Daemon . . . . . . . . . . . . . . . . . . . 21 5.2 HASM Server Daemon . . . . . . . . . . . . . . . . . . . 21 5.3 HASM Translator Daemon . . . . . . . . . . . . . . . . . 21 5.4 Application Modification for HASM . . . . . . . . . . . . 22 5.5 Component Interaction . . . . . . . . . . . . . . . . . . 22 5.6 Security Properties of HASM . . . . . . . . . . . . . . . 25 5.7 Confidentiality and Integrity of Multicast . . . . . . . 25 5.7.1 Single Encapsulation . . . . . . . . . . . . . . . 26 5.7.2 Single Decapsulation . . . . . . . . . . . . . . . 27 5.7.3 Double Encapsulation . . . . . . . . . . . . . . . 27 5.7.4 Double Decapsulation . . . . . . . . . . . . . . . 29 5.7.5 Inter-domain Translation . . . . . . . . . . . . . 30 5.8 Message Sequence Charts . . . . . . . . . . . . . . . . . 32 5.8.1 Client Session Key Request and Response . . . . . 32 5.8.2 Server Session Key Request and Response . . . . . 32 5.8.3 Multicast Data Transmission and Reception . . . . 33 5.8.4 Domain Rekeying over Multicast . . . . . . . . . . 34 5.8.5 Domain Rekeying after Reauthentication over Unicast 35 5.9 Message Formats . . . . . . . . . . . . . . . . . . . . . 36 5.9.1 HASM Header Format . . . . . . . . . . . . . . . . 36 5.9.2 HASM Key Format . . . . . . . . . . . . . . . . . . 36 5.9.3 HASM Key Request Format . . . . . . . . . . . . . . 37 5.9.4 HASM Key Response Format. . . . . . . . . . . . . . 38 5.9.5 HASM Key Reject Format . . . . . . . . . . . . . . 39 5.9.6 HASM Key Trigger Format . . . . . . . . . . . . . . 39 5.9.7 HASM Application Data Format. . . . . . . . . . . . 39 6 Acknowledgment and Disclaimer . . . . . . . . . . . . . . . . . 40 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Coan et al. [Page 2] INTERNET-DRAFT HASM Secure Multicast System November 2001 1 Introduction IP multicast was initially available in the Internet in March 1992 in an overlay network called the MBONE (with the initial use being distribution of a live audio feed from the IETF). It is now widely available as a built-in capability of routers and has been widely used in many applications. The use of IP multicast requires some supporting functionality in the operating systems of host computers. For example, a host must participate in the Internet Group Management Protocol (IGMP) to communicate to its edge router the multicast groups (named by a D-class IP address) to which applications on that host currently wish to belong. The router uses the knowledge obtained from IGMP to determine which multicast groups it needs to join. The goal of secure IP multicast is to achieve the important security properties of confidentiality, integrity, authentication, access control, dynamically changeable authorization, non-repudiation, and protection against denial-of-service attacks. As summarized in the work of Canetti et al. [CGI99], much of the current research on providing secure multicast focuses on the use of end-to-end cryptography in the style popularized in the Kerberos system [KNT91]. These techniques can achieve significant security functionality, without requiring any support from routers, firewalls, or host operating systems. However, there are some security goals (such as defense against denial of service attacks and improved support for dynamic changes in the authorized membership of groups) that have proved difficult to accomplished without using other more powerful approaches. The standard way to use end-to-end encryption to achieve secure IP multicast is (1) to establish a shared session key to be used to encrypt and decrypt all traffic on a given multicast group, (2) to use an authentication and authorization server (called an A/A server in the remainder of this draft) to maintain a database of currently authorized session members, and (3) to have the A/A server make the shared session key available to the currently authorized session members. To set this up, one needs to establish an initial security association between the A/A server and each host in the universe of potential multicast session members. The A/A server needs to maintain a database that for each multicast session indicates which of the known hosts are authorized members. The A/A server must also maintain the current shared key for each multicast session. For each authorized session member, the A/A server will give that member the current shared multicast session key on demand. Multicast senders use this key to encrypt data before multicasting. Multicast receivers use this key to decrypt incoming data (which also provides limited authentication of the sender), specifically, data that is successfully decrypted must have come from one of the currently authorized possessors of the shared key. Generally, no effort is made to protect the actual multicast traffic itself. So, an unauthorized Coan et al. [Page 3] INTERNET-DRAFT HASM Secure Multicast System November 2001 host may receive encrypted traffic (which it presumably cannot decipher without the shared session key) or send garbage traffic to the multicast group (which traffic should be discarded by session members because it fails to decrypt to sensible messages). In an ongoing multicast session, there are three reasons why it may be necessary to distribute a new session key. (1) If a new member joins, the session may be rekeyed to prevent the new member from being able to decrypt traffic from before the join. This rekeying can be implemented by multicasting the new key to current members (encrypted with current key) and unicasting the new key to the new member (using the security association with the A/A server. (2) On expiration of the current multicast key, the session may be rekeyed to limit the amount of data encrypted with old key. This rekeying can be implemented by multicasting new key to current members encrypted with current key. (3) If a member is ejected, the session may be rekeyed to prevent the departing member from decrypting any new traffic. Rekeying of the multicast session can be implemented either by requiring each member to obtain the new key in a one-to-one interaction with the A/A server or by multicasting the new key encrypted with a selection of existing keys, using a sophisticated method, like tree-structured keys, to hide the new key from the ejected member [WGL98]. Tree-structured methods allow the new key to be multicast in a form visible to all authorized members and not the ejected member using O(log n) keys, where n is the number of multicast participants. Still, the use of a single shared key for the entire multicast group is a barrier to the scalability of the rekeying operation. The following are definitions of the previously mentioned security properties that are desirable for IP multicast. * Confidentiality: The adversary cannot read the message. * Integrity: The adversary cannot change the message. * Authentication: A recipient can verify that the claimed sender of a message is the actual sender. * Access control: Only authorized parties can participate in the multicast communication. * Dynamic authorization: There is a mechanism to dynamically change the list of authorized participants. * Non-repudiation: A recipient can prove to a third party what messages it got. * No denial of service: Unauthorized parties cannot disrupt the communication. Coan et al. [Page 4] INTERNET-DRAFT HASM Secure Multicast System November 2001 The following table summarizes the extent to which basic end-to-end multicast security achieves these listed goals. Additionally, the figure summarizes the additional security functionality that can be obtained through the use of enhanced mechanisms. |Kerberos|Tree of|Mac Codes| |Secure |Shared |Shared |or Local |Public|IGMP |Key |Keys |Key Scope|Keys |Protocol Confidentiality | YES | | | | Integrity | YES | | | | Authentication | NO | | YES | YES | Access Control | YES | | | | Dynamic Authorization| SLOW | FAST | | | Non-Repudiation | NO | | | YES | No Denial-of-Service | NO | | | | YES Current limitations of end-to-end methods are: inadequate defense against denial-of-service attacks, limited support for dynamically changing authorization, and limited support for multiple autonomous administrative domains. The focus of the work on HASM is to improve secure multicast by using some network support and some limited extensions in host operating systems. The network support that we make use of includes extensions to the Internet Group Management Protocol (IGMP) run between hosts and edge routers, extended firewall functionality (specifically to achieve coordination with the A/A server to suppress unauthorized multicast traffic), and router support for encryption and decryption. The support in host operating systems that we make use of consists of support for extended IGMP. HASM includes techniques to enable: (1) multiple autonomous administrative domains, each with its own locally-managed A/A server, (2) efficient rekeying of portions of a multicast group by using network elements to translate between keys (all without trusting any single network element to securely manage any text in the clear), and (3) defense against denial-of-service attacks by using a secure extension of IGMP. We begin this document with a description of the mechanisms and we then go on to describe the current implementation and its status. 2 Multiple Autonomous Administrative Domains We consider the situation where there are multiple administrative domains, each with a need to maintain administrative control over its own A/A server. A very basic security design for this environment can provide a peering arrangement among the various A/A servers and can be implemented without any network support; however, some firewall support can limit the propagation of denial-of-service attacks between administrative domains. Coan et al. [Page 5] INTERNET-DRAFT HASM Secure Multicast System November 2001 DOMAIN 1 | Domain 2 | | | | Local IP-----Firewall-------Firewall-----Local IP Network | Network | | | | | | | | | | Hosts A/A | Hosts A/A Server | Server The design, which can operate in the network illustrated above, is to use a single shared session key that is distributed by the A/A servers. Each domain has its own A/A server, with limited trust among A/A servers of the various domains. The A/A server in each domain manages its own list of authorized session members and authenticates its own members, even in shared sessions. The A/A servers either use an algorithm like Diffie-Hellman [DH79] to generate the shared session key or they delegate the task of choosing the key to one A/A server in one domain. Some multicast sessions are shared among domains and some are not. A domain controls which of its sessions are shared. Firewall support may limit the scope of non-shared sessions; however, no rekeying at the boundary between coalition networks is performed. In Section 3, we will consider what more can be done with rekeying at domain boundaries. Certain initial security associations are required. Within a domain, we need a security association (shared key) between the local A/A server and each potential multicast participant (hosts and possibly the firewall). Each pair of domains must have a security association (shared key) between their A/A servers. Each A/A server maintains the following information in its authorization database for each multicast group. * Which local hosts (i.e., hosts within this domain) belong to the multicast group. * Which other domains may have hosts in the multicast group (just the domain name is maintained, not the identity of individual hosts). * The identity of the (unique) domain that is the lead for the multicast group. * The current shared key for the multicast group. * A domain-specific key for authentication (e.g., generating MAC codes). A MAC or message authentication code is a keyed secure hash of a message. Coan et al. [Page 6] INTERNET-DRAFT HASM Secure Multicast System November 2001 A valid request for the session key must come either from a host within the local domain or from a peer A/A server (in a different domain). If the request is from a host in the local network, the A/A server does the following: (1) authenticate the host, (2) determine whether the host is authorized, and (3) return the session key and the MAC key, encrypted with shared secret (shared between the A/A server and the requesting host). If this is not the lead A/A server for the multicast group, the session key may have to be obtained from the lead A/A server; however, the MAC code is provided from the local A/A server. If the request is from a peer A/A server, the A/A server receiving the request does the following: (1) authenticate the A/A server, (2) determine whether the A/A server is authorized and is making its request to the lead partner, and (3) return the session key, encrypted with the shared secret. The behavior required for an individual multicast session member is very similar to what is required in the case of a single A/A server. When the member wishes to join the session, it goes to its local A/A server to obtain the shared key for the multicast session, plus the authentication key. It uses these keys to encrypt, decrypt, and authenticate session messages, with authentication used to verify the domain from which the message originated. To facilitate rekeying, a session member accepts new multicast session keys that are sent with the currently valid multicast session key. This approach to having multiple autonomous administrative domains can operate without any network support in routers and firewalls. One vulnerability is that it opens multicast groups that should be private to a single domain to some unauthorized access (at the transport level) by nodes in other administrative domains, including (1) generation garbage traffic and (2) receipt of encrypted traffic from unauthorized groups. The overall negative impact of these unauthorized activities can include waste of network bandwidth, possible denial of service to legitimate users, and access to encrypted traffic for possible cryptographic attack. Improved security can be obtained by configuring firewalls to pass only multicast traffic from groups that involve at least two coalition members. The creation of a shared session key among n participants (e.g., A/A servers) can be accomplished using the algorithm of Diffie and Hellman [DH76]. We now explain that algorithm for two participants. The required initial information (shared by both parties) is: p a prime (all computations are done in GF(p), meaning mod p) and g a generator mod p (meaning for all x, there exists y such that x = g^y mod p. Each participant is assured that it contributes to the shared key, thus protecting against a weak key selected by a single participant. Let's call the participants A and B. As shown in the figure below, participant A, picks value a and participant B picks value b. After the exchange of two messages, the shared key, g^(ab) mod p, is known to both participants. Any observer of the message exchange between A and B fails to learn the shared key because knowledge of p, g, g^a, and g^b does not enable efficient computation of g^(ab). Coan et al. [Page 7] INTERNET-DRAFT HASM Secure Multicast System November 2001 Participant A Participant B 1. Compute g^a 1. Compute g^b 2. Send to B: g^a 2. Send to A: g^b 3. Compute (g^b)^a 3. Compute (g^a)^b The techniques that we have described in this section still require global coordination among all of the domains participating in a session in order to perform a rekeying operation. In the next section we describe techniques that (with the use of some additional network support) can often make the rekeying be an autonomous activity within each administrative domain. 3 Network Support for Key Translation The method for key translation as traffic crosses between administrative domains operates with limited router or firewall support (at network borders). It uses shared and partially shared session keys distributed by A/A (Authentication/Authorization) servers. Each domain has its own A/A server, which is administered locally. There only needs to be limited trust among A/A servers of the different domains. Each domain independently manages its own list of authorized session members for each multicast session. Each domain authenticates its own multicast session members, even in shared sessions. Each domain chooses keys for local use within its domain, with joint selection for shared keys to be used for interdomain traffic. Some multicast sessions are shared among domains and some are not, with each domain controlling which of its sessions are shared. Firewall support is used to limit the scope of non-shared sessions. Two variations of the design (using different cryptographic primitives) are given in the next two subsections. 3.1 Maintaining Local Keys using Commutative Encryption This variant of the design requires commutative encryption, meaning that a message encrypted with key K_a and then key K_b is equal to that same message encrypted with key K_b and then key K_a. It does enable the switch of encryption key within the network, without producing clear text in the network or providing any single point of attack. It requires a pipeline of two network elements at a domain border to perform the key change. Domain A uses K_a within its network, domain B uses key K_b within its network, etc. These domain-specific keys are assigned by each local A/A server and are known only within the local domain. All domains use K_s for inter-domain traffic transfers. The distribution of K_s is coordinated among all of the A/A servers of all partners. This variant of the design enables significant autonomy in local rekeying within a domain. Coan et al. [Page 8] INTERNET-DRAFT HASM Secure Multicast System November 2001 Encryption of message M sent to next host to the right: {{M}K_a}K_s --> {{M}K_s}K_b --> {M}K_a --> {M}K_s --> {M}K_b --> A R R R R B Knows: Knows: Knows: Knows: Knows: Knows: K_a K_s K_a K_b K_s K_b ----------- Domain A ---------- ----------- Domain B ---------- 3.2 Maintaining Local Keys using Standard Encryption This variant of the design requires double encryption, but works with any cryptosystem. It enables the switch of encryption key within the network, without producing clear text in the network or having any single point of attack. It needs the network element at the border between domains to perform the key change. Domain A uses K_a within its network, domain B uses key K_b within its network, etc. These domain-specific keys are assigned by each local A/A server and are known only within the local domain. All domains also use K_s for local and inter-domain traffic and K_t as an additional key for inter-domain traffic. The distribution of K_s and K_t is coordinated among all of the A/A servers of all partners. This variant enables significant autonomy in local rekeying (where the local key can be changed autonomously), but it does require wide knowledge of the inter-domain key K_s. The transfer key K_t only needs to be known at the gateway for each domain. The rekeying strategy is that a change in the local key is generally sufficient and can be accomplished efficiently. Encryption of message M sent to next host to the right: {{M}K_s}K_a --> {{M}K_s}K_b --> {{M}K_s}K_a --> {{M}K_s}K_t --> {{M}K_s}K_b --> A R R R R B Knows: Knows: Knows: Knows: Knows: Knows: K_a, K_s No Keys K_a, K_t K_b, K_t No Keys K_b, K_s ----------- Domain A ---------- ----------- Domain B ---------- 3.3 Operation of Both Solutions Within a domain the following types of security associations (e.g., shared keys) are initially needed: (1) between the local A/A server and each potential multicast participant (host) and (2) between the local A/A server and each network element that must perform either encryption of decryption of multicast traffic. Additionally, each pair of domains must have a security association between their A/A servers. Coan et al. [Page 9] INTERNET-DRAFT HASM Secure Multicast System November 2001 In addition to the information required for the protocol given in Section 2, each A/A server must maintain the following information in its authorization database for each multicast group. * Which network elements are authorized to perform encryption and decryption (and which key(s) the element is authorized to use). * The current shared key for the multicast group and the local key for the group (key specific to this domain). In addition to interacting with local hosts (to provide both local and shared keys) and peer A/A servers as required for the solution given in Section 2, each A/A server must be prepared to interact with those local network elements charged with either encrypting or decrypting multicast traffic. For requests from local network elements, the A/A server should do the following: (1) authenticate the network element and verify that it is authorized, (2) determine what key the network element is authorized to have, (3) obtain the key either locally or from a peer A/A server, as required, and (4) return encrypted key to the requesting network element. The main advantages of using network support for rekeying is that it can limit the scope of many rekeying operations, thus providing both efficiency and local autonomy within a domain. For solution 2, we anticipate that most ordinary rekeying operations (to handle member joins, member ejections, and key expiration) can be done using only the key that is local to the domain. In solution 1, the main disadvantages are the requirement to use commutative encryption and the need to have a chain of two network elements perform key transformation. The main advantage is that all rekeying operations are local, requiring the participation of only a limited number of network elements or hosts. 4 Secure IGMP We now analyze the role of IGMP (Internet Group Membership Protocol) in an overall secure multicast architecture. We present four designs for secure multicast with IGMP. The baseline design (which provides end-to-end security functionality, but is open to some attacks such as denial of service) has already been implemented in prototype form. We are in the process of implementing two of our other designs that provide additional security functionality. IGMP operates between an edge router and the hosts directly connected to that router (say by an access LAN). A host H that wishes to join a multicast group M as a receiver uses IGMP to inform its edge router of this wish. The edge router then uses the multicast routing mechanisms to ensure that it gets traffic for group M (if this isn't already the case) and the edge router then broadcasts the traffic for group M on the access LAN to which host H is connected. IGMP gives an edge Coan et al. [Page 10] INTERNET-DRAFT HASM Secure Multicast System November 2001 router only an inexact view of the multicast group membership on each access LAN that it serves. Because of the open approach that pervades much of the Internet design, IGMP (in its current standard form) is only intended to let an edge router decide whether there exists a need to send the traffic from a given multicast group on a given access LAN. IGMP does not necessarily give an edge router an accurate current view of which of the hosts that it serves currently belongs to a given multicast group. A sender to a multicast group does not have to be a member of that group and hence doesn't have to use IGMP at all. Given all of these attributes, IGMP as currently defined provides essentially no security functionality. 4.1 IGMP and Multicast Routing We are addressing the security of IGMP separately from the overall multicast security issue. To understand why this approach makes sense, it is important to review some of the key differences between the IGMP protocol and multicast routing protocols like DVMRP, PIM-SM, PIM-DM, CBT, OCBT, HIP, and KHIP. The multicast routing protocols can be made more secure by securing the pairwise communication among the participating routers. IGMP operates in a different portion of the network from the multicast routing protocol. IGMP operates between hosts and edge routers. Within hosts, IGMP generally operates within the OS kernel as a part of the IP stack functionality. Multicast routing protocols operate only among network routers. Because IGMP is implemented at hosts, there is strong need for standardization. There is essentially a single IETF standard for IGMP, although there presently are three different versions of this standard with each new version having some added functionality. There is backward compatibility among the three existing versions of IGMP. In contrast, there exist multiple multicast routing protocols with somewhat more limited interoperability within a single administrative domain. For future reference, we review the functionality of the three versions of IGMP. Version 1 has a REPORT message that a host uses to express its interest in a particular multicast group. Whenever an edge router has a current REPORT message for a particular multicast group (1) it uses the multicast routing protocol to make sure that it is a member of that multicast group and (2) it broadcasts the traffic for that multicast group on any access LAN where there is a current REPORT message for that group. REPORT messages time out with a configuration dependent timeout value. When the current REPORT message for a group is about to timeout, an edge router will broadcast a QUERY message to determine if there is still a host with interest in the group. Hosts listen for QUERY messages and respond with REPORT messages (if they are interested in the given group). Hosts also Coan et al. [Page 11] INTERNET-DRAFT HASM Secure Multicast System November 2001 listen for REPORT messages and suppress sending additional REPORT messages for the same group. Version 1 of IGMP only has REPORT and QUERY messages. Hence there is no way for a host to indicate explicitly that it has left a group. An abandoned request for a given multicast group will eventually time out and (assuming that there are no other receivers for that group) the edge router will eventually (1) stop broadcasting the traffic on the access LAN and (2) use the multicast routing protocol to leave the group (possibly causing some branch of the multicast routing tree to be pruned). The absence of an explicit leave mechanism can cause performance problems if hosts quickly "surf" many multicast groups. Before the abandoned requests have timed out, an edge router can be carrying traffic for a number of unneeded multicast groups. This problem is addressed in version 2 of the protocol, which adds a LEAVE message. A host that is no longer interested in the multicast group sends a LEAVE message. An edge router that receives a leave message uses the QUERY/REPORT mechanism to determine if any other hosts are interested in that same multicast group. In versions 1 and 2 of IGMP, the granularity of messages is the multicast group. It is possible for a host to wish to make its selections based also on the identity of the sender. A host may wish to receive traffic from some senders to the group and not others. Version 3 of IGMP adds this additional functionality. 4.2 Security Threats Standard IP multicast provides no effective security mechanism and is wide open to essentially all possible security threats. The contents of the multicast are sent in the clear for all to read. There is no authorization and authentication mechanism for senders. There is no authorization and authentication mechanism for receivers. There is no way to reliably determine the source of a given message. There is no defense against replaying of previously sent messages. There is no concentrated knowledge of the group membership. A number of denial-of-service attacks are possible. Some of these security threats are best addressed by securing the network of routers. Some are best addressed by end-to-end security mechanisms, like those presented in Sections 1, 2, and 3 of this paper. And, some are best addressed by adding security mechanisms to IGMP. For the purpose of refining our security design for IGMP and ensuring that the security issues that we address in the IGMP domain are not better addressed elsewhere, we consider the already-presented baseline design in which there is an end-to-end security mechanism among all members (senders and receivers) of a given multicast group. The end-to-end security mechanism that we assume consists of a Kerberos-like A/A server [KNT91] that has shared private keys with Coan et al. [Page 12] INTERNET-DRAFT HASM Secure Multicast System November 2001 each host and router, that maintains a list of the authorized senders and receivers for each multicast group, and that distributes session keys to authorized members. We have analyzed the security vulnerabilities that remain (primarily in the areas of denial of service and ready availability of encrypted traffic for analysis). Our additional IGMP security designs address these remaining vulnerabilities. The end-to-end security mechanism in its most basic form is enough to ensure that only authorized parties can create and read the properly encrypted messages for the multicast group. Using a single shared session key, it does not ensure that the identity of senders can be determined and it does not ensure that receivers and senders will not change roles. Most of these additional threats can be addressed by additional end-to-end mechanisms (that don't involve IGMP). Signing of messages using public keys, single MAC codes, or carefully chosen sets of MAC codes can be used to make it possible to determine the sender of a given message, and can also make sure that an authorized receiver can't assume the role of a sender. It is somewhat harder to address the case of a host that is authorized to be a sender and not receiver, but which dishonestly attempts to receive packets (this situation is partially addressed by our Design 1 and more completely addressed by our Design 3). One area of security attack that is not well addressed by end-to-end security mechanism is denial-of-service attacks. These attacks include (1) unauthorized senders joining the group and sending garbage (meaning not properly encrypted) traffic to use up bandwidth, (2) unauthorized receivers joining the group to cause additional traffic (traffic that is unreadable by the unauthorized receiver) to be sent to consume network resources, and (3) unauthorized receivers joining the group to obtain large amounts of encrypted traffic to launch code breaking attacks. We address these areas in our IGMP security designs. 4.3 Security Protocols In our security modifications to IGMP and in other security protocols that we discuss in this paper, we will (of necessity) be using a variety of security protocols. It is notoriously difficult to design correct security protocols [CJ97]. A number of published security protocols, including one of the influential and widely know protocols of Needham and Shroeder [NS78] have been shown to have security flaws, sometimes years after initial publication [L95, L96]. Automatic and manual techniques for verifying security protocols are only now reaching some level of maturity [CJ97, C00]. Given the current state of the art in security protocols, our approach wherever possible will be to make use of existing, well-tried security protocols such as those employed in Kerberos [KNT91]. Coan et al. [Page 13] INTERNET-DRAFT HASM Secure Multicast System November 2001 In our IGMP security designs, we make use of two authorization and authentication protocols, which we now illustrate for future reference. In the first protocol, a client goes to an A/A server to obtain a ticket (proof of service authorization and shared session key with a limited period of validity) and presents this ticket to a server. Below, we give a high-level illustration of this protocol with the client being a host and the server being the edge router. An implementation of this protocol in the style of Kerberos would depend on having shared keys between the authentication/authorization server and each host and router in the network. For simplicity, the the Kerberos hierarchy of ticket granting authorities is not shown. In the second protocol, which was used to distribute the session keys as described in Sections 1, 2, and 3, a client goes to the A/A server to obtains a shared session key. This protocol is illustrated in below, together with a description of a possible shared-key implementation. +----------+ | Edge | | Router | +----------+ ^ | | | | 3. Present Ticket | | | | +----------+ 1. Request Ticket +----------+ | | --------------------------> | | | Host | |A/A Server| | | 2. Obtain Ticket | | +----------+ <-------------------------- +----------+ 4.4 IGMP Security Designs We have produced four security designs for IGMP, each with a different level of security. We have implemented the baseline design, Design 0, which only provides end-to-end security mechanisms. Design 1 (Receiver Authorization) provides protection against denial of service attacks by potential receivers. Design 2 (Sender and Receiver Authorization) provides protection against denial of service attacks by potential senders and receivers. We may defer the implementation of Design 3, which provides additional security mechanisms whose benefit we have not yet completely analyzed. Coan et al. [Page 14] INTERNET-DRAFT HASM Secure Multicast System November 2001 4.4.1 Design 0: Baseline For this baseline design, no changes are made to IGMP. Instead multicast security is based entirely on end-to-end security measures taken among the senders and the receivers. Each member of the multicast group obtains one or more session keys. In the simplest case, all group members have the same session key. Some additional security can be obtained if each sender uses its own session key and each receiver has session keys that correspond only to the senders that it is authorized to listen to. Advantages and Disadvantages This simple approach to multicast security does provide significant security functionality without needing any changes to IGMP or to the kernel-level IP stack on individual host computers. Using this approach and assuming that the encryption is sufficiently strong, only authorized group members can send and receive valid messages. A receiver can detect and discard messages that have not been encrypted with the shared session key. In the basic shared key approach, this design does not protect against repudiation and impersonation. Any host that is authorized to have a shared session key can play any role that is possible for that key. For example, a host that is authorized to have the key so that it can receive multicast traffic could instead decide to impersonate the sender. If two senders are intended to use the same session key, then they could potentially impersonate each other. If multiple senders share the same session key, then any authorized sender (even ones that are not authorized to receive) could also receive and read the multicast traffic. Most of these repudiation and impersonation concerns could be addressed (albeit at greater cost) by using public keys instead of shared session keys. Our subsequent designs that make modifications to IGMP also address these concerns, but without requiring the use of more expensive public keys. Another major weakness of this design is that it is open to a number of denial-of-service attacks. Unauthorized receivers can launch (somewhat limited) denial-of-service attacks by requesting to receive multicast traffic. These receivers won't be able to understand what they get, but the will unnecessarily use bandwidth in the network and on their own access LAN. These unauthorized receivers will also potentially obtain access to a large volume of encrypted traffic, possibly facilitating code-breaking attacks. Unauthorized senders can also mount significant denial-of-service attacks, specifically by flooding the multicast group with unencrypted, invalid traffic. This flooding attack won't produce multicast traffic that appears valid to receivers; however, it may use significant amounts of network bandwidth. The subsequent designs that we present do offer protection of denial-of-service attacks. Coan et al. [Page 15] INTERNET-DRAFT HASM Secure Multicast System November 2001 Implementation Approach We already have an implementation of this design as more fully described in Section 5 of this paper. The basic implementation idea is that each session member obtains a shared key from the A/A server. The member then uses this session key to encrypt or decrypt multicast traffic as appropriate. 4.4.2 Design 1: Receiver Authorization This design focuses on receiver authorization. IGMP is modified to require that a potential receiver demonstrate to its edge router that it has authorization to receive. This demonstration of authorization is done with a ticketing protocol like that described in Section 4.3. In addition to IGMP modifications, this design assumes the use of end-to-end security mechanisms as described in Design 0. These mechanisms will be refined in other phases of this project. Advantages and Disadvantages In addition to the benefits of Design 0, this design offers a number of benefits related to the prevention of denial-of-service attacks by potential receivers. An unauthorized receiver is unable to initiate the broadcast of multicast session traffic on its access LAN. An edge router has inexact knowledge of which hosts on a given access network are in the multicast group. As long as one host demonstrates that it is an authorized receiver, then the edge router joins the group and broadcasts its traffic on the access LAN. The encrypted traffic is visible to all hosts on the network, whether or not they are authorized receivers. It appears that this sharing is inherent in the use of broadcast access technology. We have identified only two small vulnerabilities of broadcasting on the access LAN. The first vulnerability is that a large volume of encrypted traffic is available to unauthorized receivers for possible code-breaking attacks. This situation seems inherent in the use of broadcast technology in an access network. We do not address it in any of our designs. The second vulnerability is that a host that (1) shares an access LAN with an authorized receiver, (2) is not itself an authorized receiver, and (3) has the shared session key because it is an authorized sender, can see and decrypt traffic from some other authorized sender (presuming that all senders use the same multicast session key). This second vulnerability can be addressed by (1) adopting the policy that all authorized senders are also authorized receivers, (2) using a different session key for each authorized sender, or (3) adopting our Design 3 for modified IGMP. As in Design 0, unauthorized senders can still mount significant denial-of-service attacks, specifically by flooding the multicast group with invalid traffic. The prevention of flooding attacks by potential senders is addressed in the next two designs that we present. Coan et al. [Page 16] INTERNET-DRAFT HASM Secure Multicast System November 2001 Implementation Approach The basic approach to implementing this design is to use one or more A/A servers that have a current view of what hosts are authorized for each multicast group. A potential receiver interacts with that A/A server to obtain a ticket, which it then presents to its edge router as a part of a modified IGMP protocol. The modification to IGMP focuses on alterations to the two (or three) messages in the existing protocol. Let's consider each message individually. * Report Message: This message is made secure as follows. A potential receiver obtains a ticket from the A/A server. This ticket is presented to the edge router. Initial and subsequent report messages are encrypted using the shared session key in the ticket. This key is only shared between the one potential receiver and the edge router. A small modification is needed to the existing requirement that hosts on an access LAN monitor Report messages and not send redundant instances. Two alternative solutions are possible. First, we could change IGMP to require all hosts on the access LAN to respond to every Query message. This only adds a small amount of overhead. Second, we could have the edge router echo valid report messages. When the edge router gets a valid report message. It broadcasts an instance of that message signed with the edge router's signature. * Leave Message: These messages should only come from authorized receivers who had previously joined the multicast group. They only need to be understood by the edge router. They can be made secure by requiring that they be encrypted with the session key that the departing recipient obtained when it got its ticket from the A/A server. * Query Message: Query messages are now broadcast from an edge router to all hosts on an access LAN. The reason for applying security to these messages is to prevent (limited denial-of-service) attacks in which a malicious host on the access LAN spoofs a Query message. The consequences of a spoofed Query message appear to be limited to wasted activity on the access LAN. A malicious host on that access LAN could achieve similar damage by simple flooding. Nevertheless, it appears prudent to apply some security to Query messages. One way of securing these messages is simply to require that the edge router sign each Query message that it sends. An alternative approach that leaks a little less information to unauthorized receivers is for the edge router to individually send a Query message to each receiver that has demonstrated authorization. Each Query message would be encrypted with the session key that the receiver previously presented to the edge router. 4.4.3 Design 2: Sender and Receiver Authorization This design focuses on sender authorization. It augments Design 1, which provides receiver authorization functionality. IGMP is extended to apply to both senders and receivers. Before attempting to send any Coan et al. [Page 17] INTERNET-DRAFT HASM Secure Multicast System November 2001 traffic to the multicast group, a potential sender is required to participate in a new IGMP-like protocol. In this protocol, the potential sender demonstrates to its edge router that it has authorization to send. This demonstration of authorization is done with a ticketing protocol like that described in Section 4.3 and like that used in Design 1. Additionally, each packet from the sender is authenticated (for source) by the edge router. This authentication is done by a mechanism like an IPsec tunnel. In addition to IGMP modifications and extensions, this design assumes the use of end-to-end security mechanisms as described in the first three sections of this paper. These mechanisms will be refined in other phases of this project. Advantages and Disadvantages In addition to the benefits of Designs 0 and 1, this design prevents a number of denial-of-service attacks by potential senders. An unauthorized sender is prevented from launching traffic that consumes resources within the network and at legitimate receivers. Of course, the unauthorized receiver can consume resources on its access LAN and at its edge router. This Design, like Designs 0 and 1 has the vulnerability that a host that (1) shares an access LAN with an authorized receiver, (2) is not itself an authorized receiver, and (3) has the shared session key because it is an authorized sender, can see and decrypt traffic from some other authorized sender (assuming the use of the same multicast session key for all senders). As explained previously, there are several ways to address this vulnerability. One of those ways is to use Design 3 for modifying IGMP. Implementation Approach End-to-end security functionality is implemented as in Design 0. Receiver authentication and authorization is implemented as in Design 1. For sender authentication and authorization, there are two separate implementation issues that we treat separately. An edge router must be able to determine which hosts that it serves are authorized senders for a multicast group. To accomplish this, IGMP is augmented to provide for interaction between senders and edge routers. This is a significant change. A potential sender interacts with the A/A server to obtain a ticket, which it then presents to its edge router as a part of the extended IGMP protocol. The extension adds two new messages to IGMP. We consider each message individually. * Request Message: This message is a request to be allowed to send to the multicast group; it is made secure as follows. A potential sender obtains a ticket from the A/A server. This ticket is presented to the edge router. The Request message can also be used to establish a session key (between the sender and the edge router) for authentication of the source of all multicast traffic that originates from this sender. Coan et al. [Page 18] INTERNET-DRAFT HASM Secure Multicast System November 2001 * Reject Message: This message is required to provide feedback to senders that either the presentation of a ticket failed or the ticket previously presented has expired. To defend against spoofed error messages (from malicious hosts on the same LAN), this message is made secure by requiring the signature of the edge router. To achieve reasonable throughput, the authorization functionality provided by the extended IGMP should be done rarely, say at the start of sending and at ticket expiration. Still, per-packet checking is needed to make sure that no malicious host spoofs packets from an authorized sender (that happens to be on the same access LAN). Because of the use of end-to-end security mechanisms, an authorized receiver would discard spoofed packets, but these spoofed packets do consume network bandwidth. The specific activity that is needed on a per-packet basis is authentication (reliably determining the identity of the sender), not authorization. This ongoing authentication is accomplished using an IPsec tunnel, MAC codes, or some other similar mechanism. 4.4.4 Design 3: Fine Grained Authentication and Authorization This is the Design with the highest level of security. Its focus is to address potential vulnerabilities caused by the use of a shared access LAN. All interaction between a sender and an edge router goes over an IPsec tunnel. Similarly, all interaction between a receiver and an edge router goes over an IPsec tunnel. Authorization requests from potential senders and receivers are made over the IPsec tunnels using a 2-party version of the extended IGMP protocol used in Design 2. Advantages and Disadvantages This design offers most of the benefits of Designs 0, 1, and 2. In addition, it gives edge routers better control of which hosts are participating in the multicast group. One benefit of this more exact knowledge is that it can be used to prevent the previously discussed vulnerability in which an authorized sender can receive and understand some multicast information (from a different authorized sender) for which it does not have authorization. We are still evaluating whether this benefit could be better achieved by other means. The most significant disadvantage of this approach is that it requires that multicast traffic be sent multiple times on a single access LAN (once per authorized receiver, properly encrypted to use the IPsec tunnel for that receiver). Multiple sending of a potentially large volume of data on a broadcast access network seems to negate some of the expected benefits of using multicast at all. Implementation Approach This design is implemented by having all interaction between a multicast group participant (whether sender or receiver) and its edge router conducted over an IPsec tunnel. The A/A server is still used, Coan et al. [Page 19] INTERNET-DRAFT HASM Secure Multicast System November 2001 but its main role is to provide authorization. IGMP is modified to run pairwise between each group member (sender or receiver) and its edge router. 4.4.5 Summary of Design Choices The following table summarizes the security functionality of the four design choices for secure IGMP that we have presented in this section of this report. Capability |Design|Design|Design|Design| | 0 | 1 | 2 | 3 | | | | | | End-to-end encryption of | | | | | multicast session, with key given | YES | YES | YES | YES | only to authorized members | | | | | | | | | | Receivers demonstrate | | | | | authentication and authorization | | YES | YES | YES | to edge routers | | | | | | | | | | Senders demonstrate | | | | | authentication and authorization | | | YES | YES | to edge routers | | | | | | | | | | Edge routers have exact | | | | | knowledge and control of | | | | YES | group members on subnet | | | | | Summary of design choices for secure IGMP. 5 Implementation Status We are in the process of implementing our design choices starting with the Design 0: Baseline option as described in Section 4.4.1. Our ultimate goal is to implement portions of our design in network elements as appropriate. Our initial step is to demonstrate the concepts in an application-level implementation. The implementation is an end-to-end secure multicast solution which we have named Hierarchical Application-Level Secure Multicasting (HASM). The following are the characteristics of the current OpenSSL/Linux implementation. HASM is currently implemented at the application-level and supports secure IGMP Design 0++. It provides A/A and Key distribution servers and integrated key translation functionality. The multicasting application gets keys from HASM key reception clients. HASM offers a hierarchical structure for servers to provide distributed rekeying and reauthentication support, with separation of domains. Coan et al. [Page 20] INTERNET-DRAFT HASM Secure Multicast System November 2001 The HASM system has the following components: HASM Client Daemon, HASM Server Daemon, HASM Translator Daemon, and Application (modified for HASM) 5.1 HASM Client Daemon The HASM Client Daemon is a multi-threaded process that has: (1) information about a designated HASM server which will authenticate, authorize, and grant access to this client and (2) a socket connection to wait for a local application that desires the keys. The process maintains information about a designated HASM server which will authenticate, authorize, and grant access to this client. As needed, it requests from the designated server session keys for the group. To do this it uses a temporary SSL/TCP connection with the server using x509 certificate based authentication. Rekeying events are handled either over the secure multicast group, or on the SSL/TCP connection. 5.2 HASM Server Daemon The HASM Server Daemon is a multi-threaded process that is configured with some designated level in the key distribution and control hierarchy. For example, a domain would have one server at the top level in the hierarchy. It maintains information about HASM servers that are above it in the hierarchy or that are its peers at the top level. It also maintains an A/A database for the prospective members (clients) and an open socket connection to wait for a prospective clients (members) to request keys. The process maintains information about a designated HASM server which will authenticate, authorize, and grant access to this server (acting as a client) to get session keys for a higher secure group. To do this it uses a temporary SSL/TCP connection with the clients using x509 certificate based authentication. The server issues rekeying events (either over the secure multicast group, or on the SSL/TCP connection), as needed. 5.3 HASM Translator Daemon The HASM Translator Daemon provides integrated key translation functionality by joining two separate secure multicast groups (which might be on the same class D address/port). The translator maintains KLower (which it has received as a client from the local domain server) and KEqual (which it has received from a hierarchically higher server). The data that arrives on the lower multicast group is decapsulated/ decrypted using KLower and then encapsulated/encrypted using KEqual and sent on the higher secure multicast group. The same process is applied in the reverse direction. Coan et al. [Page 21] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.4 Application Modification for HASM Any application that needs to be able to use the multicast session keys has to be modified. The changes include the addition of a separate thread which communicated with the HASM Client Daemon, and gets keys that have been delivered to the client. Also required are minor modifications in the initialization and Input/Output functions that the application uses. More specifically, the following functions are called at appropriate places: * HASM_api_initialize(...) * HASM_api_encapsulate(...) * HASM_api_decapsulate(...) The first function HASM_api_initialize() is called inside the main routine of the application. This is a blocking function, and will not return unless a connection has been established with the HASM Client on the localhost and the port which is an argument. The multicast address and port for the application are also part of the arguments, because the Key distribution server makes decisions based on them. The next function, HASM_api_encapsulate() is used to do the multicast security from the keys that have been received from the HASM Server (via the HASM client). The security is provided as part of encryption of the data, and creation of a message digest. Double encryption could also be employed, but that is invisible to the application programmer. The function is introduced before the cleartext message is to be sent. Instead, the encapsulated message is sent on the multicast address. The last function, HASM_api_decapsulate() is used at the receiver. The function is introduced after an an encapsulated message is received on the multicast address. It is decapsulated, and then provided to the application. 5.5 Component Interaction The next few diagrams illustrate the interaction between two partners with each partner having its own AA and Key distribution server at hierarchical level 1. Each partner also has a Translator, which acts as translation point between the local key and the inter-domain key. The following figure illustrates the Local Control group that is subscribed to by the Server, the translator and all the clients. All control information regarding the group travels on this secure group. Coan et al. [Page 22] INTERNET-DRAFT HASM Secure Multicast System November 2001 +--------------+ | | | HASM Server | | Level 1 | +-------+------+ ^ | | +-------------+ | | HASM | +------------------->| Translator | | | Domain 1 | | +-------------+ Local HASM Control Group +--------------+ | +--------------+ | | | | | | HASM Client |<----------------+-------------->| HASM Client | | | | | +------*-------+ +------*-------+ * * * * +------*-------+ +------*-------+ | Assoc. APP | | Assoc. APP | +--------------+ +--------------+ The following diagram illustrates the data flow in a local domain. Notice that the server is not involved. The translator picks up the double encapsulated data and translates it to the inter-domain group. +-------------+ | HASM | +------------------->| Translator | | | Domain 1 | | +-------------+ Local HASM Data Group +--------------+ | +--------------+ | | | | | | HASM Client | | | HASM Client | | | | | | +------*-------+ | +------*-------+ * | * * | * +------*-------+ | +------*-------+ | Assoc. APP |<----------------+-------------->| Assoc. APP | +--------------+ +--------------+ Coan et al. [Page 23] INTERNET-DRAFT HASM Secure Multicast System November 2001 Inter-domain control is maintained on the inter-domain control group as illustrated in the following figure. The servers and translators from the local domains are part of this control group. +--------------+ | | | HASM Server | | Level 2 | +-------+------+ ^ | | Interdomain +--------------+ HASM Control +--------------+ | | Group | | | HASM Server |<----------------+-------------->| HASM Server | | Level 1 | | | Level 1 | +--------------+ | +--------------+ | +-------------+ | +-------------+ | HASM | | | HASM | | Translator |<-----+---->| Translator | | Domain 1 | | Domain 2 | +-------------+ +-------------+ Inter-domain data group lies between the local domain translators, as illustrated in the following figure. The translators convert data from on secure group onto the interdomain group and vice-versa. +-------------+ +-------------+ | HASM | | HASM | +---->| Translator |<------------->| Translator |<-------+ | | Domain 1 | Interdomain | Domain 2 | | | +-------------+ HASM Data +-------------+ | | | | Group | +-------------+ +--------------+ | | Domain 1 Domain 2 Local Local HASM Data HASM Data Group Group | | +------------+ | | +------------+ | Assoc. APP |<----+ +---->| Assoc. APP | +------------+ | | +------------+ | | +------------+ | | +------------+ | Assoc. APP |<----+ +---->| Assoc. APP | +------------+ +------------+ Coan et al. [Page 24] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.6 Security Properties of HASM HASM implements authentication, authorization and access control during a member's initial access to the groups. A local certification authority (CA)is created as described in the previous section. This CA signs all the certificate requests to create the certificates that are used by the authorized prospective member and key servers. Access control is generic, and all authorized members are granted access in the current version of HASM. Unicast connections are secured using SSL and x509 certificates. Confidentiality and integrity are dependent on the shared unicast session cipher that the client and the key server agree on. Some of the possible combinations that we use are: EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 5.7 Confidentiality and Integrity of Multicast Confidentiality and integrity of the multicast session are dependent on the key and the encryption and integrity algorithms used by the members. The following steps are taken: * A Hash of the application data that has to be delivered on the multicast port is created. The hash function is dependent on the integrity algorithm. * The Hash is then attached to the application data. * The resulting data (app+hash) is then encrypted using the encryption algorithm. The receiver, which has the same session key takes the following steps: * The received data is decrypted to get the application data and the hash as created by the sender. The decryption algorithm has to be complimentary to the encryption algorithm. * A Hash of the application data that was received is created. The hash function is dependent on the integrity algorithm, which should be the same as the sender integrity algorithm. * The two hash values are compared. If there are no inconsistencies, then the application data is accepted, other wise it is rejected. Coan et al. [Page 25] INTERNET-DRAFT HASM Secure Multicast System November 2001 The following confidentiality capabilities are part of HASM: DES, RC4, IDEA, RC2, Blowfish, Cast5, and RC5. The following integrity capabilities are part of HASM: MD2, MD4, MD5, SHA, SHA1, DSS, DSS1, MDC2, and RIMPD160. These capabilities can be combined to provide various flavors of confidentiality and integrity on the multicast session. 5.7.1 Single Encapsulation The following diagram illustrates single encapsulation where raw data is encrypted, and also, a message digest of the data is created. The encrypted data and the digest are attached, and then encapsulated into the HASM Application data packet format. +-------------+ +----------------+ | | Encrypt | | | Raw Data +--------------------------->| Encrypted Data +-----+ | | | | | +-----+-------+ +----------------+ | | | | | | | | | | | | Create Message Digest +--------------+ | +---------------------------------->|Message Digest| | +-------+------+ | | | | | | | | | | | | Append | +-----+ +------+ | | +---------------------+ +--- | | |+--------+----+-----+| | +----------------+ |+--------+----+-----+| | | | |+--------+----------+| Put into | | Encrypted Data | ||*******************||<-------------------+ | | ||*******************|| message | +--------------+-+ ||*******************|| | |Message Digest| |+*******************+| | +--------------+ |+*********+ | +--- +---------------------+ Encapsulated Data to be sent on the multicast group. Coan et al. [Page 26] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.7.2 Single Decapsulation The following diagram illustrates the encrypted data and message digest are extracted from the received encapsulated data. The encrypted data is decrypted using the same key as used in the encryption. Then, a message digest of the raw data is created, and compared with the received message digest. If the comparison is without errors, then the raw data is forwarded to higher layer. Encapsulated received data +----------------------+ +--- |+--------+----+-----+ | | +----------------+ |+--------+----+-----+ | | | | |+--------+----------+ | Detach from | | Encrypted Data +----+ ||*******************| |------------------>| | | | ||*******************| | message | +--------------+-+ | ||*******************| | | |Message Digest| | |+*******************+ | | +-------+------+ | |+*********+ | +--- | | +----------------------+ | | | | +------ | | | +--------------+ | | | |Message Digest|<----------------------+ | | +--------------+ | | | | | COMPARE | | | | | | +-------------+ | | +--------------+ | | Decrypt| | |Message Digest|<--------+ Raw Data |<------------+ | +--------------+ | | +------ +-------------+ 5.7.3 Double Encapsulation The following diagram illustrates the raw data is first encapsulated (encrypted + message digest) using the first (global) key. The encapsulated message is then treated as raw data for another round of encapsulation with the second (local) key. Coan et al. [Page 27] INTERNET-DRAFT HASM Secure Multicast System November 2001 +-------------+ +----------------+ | | Encrypt(1) | | | Raw Data +--------------------------->| Encrypted Data +-----+ | | | | | +-----+-------+ +----------------+ | | | | Create Message Digest(1)+--------------+ | +---------------------------------->|Message Digest| | +-------+------+ | | | | Append | +-----+ +------+ | | +-----------------------+ +--- | | | +--------+----+-----+ | | +----------------+ | +--------+----+-----+ | | | | | +--------+----------+ | Put into | | Encrypted Data | | |*******************| |<------------------+ | | | |*******************| | message | +--------------+-+ | |*******************| | | |Message Digest| | +*******************+ | | +--------------+ | +*********+ | +--- +----------+------------+ | +-----+ |Use encapsulated date |as raw data for the |second encapsulation | +-------------+ +----------------+ | Single | Encrypt(2) | | | Encrypted |--------------------------->| Encrypted Data +-----+ | Data | | (2) | | +-----+-------+ +----------------+ | | | | Create Message Digest(2)+--------------+ | +---------------------------------->|Message Digest| | +-------+------+ | | | | Append | +-----+ +------+ | | +----------------------+ +--- | | |+--------+----+-----+ | | +----------------+ |+--------+----+-----+ | | | | |+--------+----------+ | Put into | | Encrypted Data | ||###################| |<------------------+ | (2) | ||###################| | message | +--------------+-+ ||###################| | | |Message Digest| |+###################+ | | +--------------+ |+########## | +--- +----------------------+ Double encapsulated data to be sent on the multicast group Coan et al. [Page 28] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.7.4 Double Decapsulation Double encapsulated received data +----------------------+ +--- |+--------+----+-----+ | | +----------------+ |+--------+----+-----+ | | | | |+--------+----------+ | Detach from | | Encrypted Data +----+ ||###################| |----------------->| | | | ||###################| | message | +--------------+-+ | ||###################| | | |Message Digest| | |+###################+ | | +-------+------+ | |+########## | +--- | | +----------------------+ | | | | +------ | | | +--------------+ | | | |Message Digest|<----------------------+ | | +--------------+ | +--COMPARE +-------------+ | | | +--------------+ | Single | Decrypt(2)| | | |Message Digest|<--------+ Encrypted |<------------+ | | +--------------+ | Data | | +------ +-------+-----+ | | |If the first decapsulation is correct | |then, use the data as single encapsulated | |data +--------------------------------------+ | | +-----------------------+ +--- | +--------+----+-----+ | | +----------------+ | +--------+----+-----+ | | | | | +--------+----------+ | Detach from | | Encrypted Data +----+ | |*******************| |----------------->| | | | | |*******************| | message | +--------------+-+ | | |*******************| | | |Message Digest| | | +*******************+ | | +-------+------+ | | +*********+ | +--- | | +----------+------------+ | | | | +------ | | | +--------------+ | | | |Message Digest|<----------------------+ | | +--------------+ | | | COMPARE | | +-------------+ | | +--------------+ | | Decrypt(1)| | |Message Digest|<--------+ Raw Data |<------------+ | +--------------+ | | +------ +-------------+ Coan et al. [Page 29] INTERNET-DRAFT HASM Secure Multicast System November 2001 The following diagram illustrated double decapsulation. The received encapsulated data is decapsulated by using the second (local) key. The resulting decrypted data is in fact single encapsulated data. A message digest of the same is created and compared with the received message digest for integrity. In case of a match, the decrypted data is treated as a single encapsulated HASM packet, and undergoes another round of decapsulation, this time, using the first (global) key. A message digest match insures integrity. 5.7.5 Inter-domain Translation The following diagram illustrates inter-domain translation. Once a double encapsulated HASM packet reaches the translator, it is decapsulated once using the second (local) key. After insuring integrity, the resulting single encapsulated HASM packet is treated like raw data ready for encapsulation. The translator encapsulates this data using the inter-domain data key. The receiving translator receives the double encapsulated data (global & inter-domain) and first decapsulates using the inter-domain key. After checking for integrity, the translator encapsulates the resulting data with the local key and sends it to its local domain, where double decapsulation at the end APPs retrieves the original data. Coan et al. [Page 30] INTERNET-DRAFT HASM Secure Multicast System November 2001 +----------------------+ +--- |+--------+----+-----+ | | +----------------+ |+--------+----+-----+ | | | | |+--------+----------+ | Detach from | | Encrypted Data +----+ ||###################| |----------------->| | | | ||###################| | message | +--------------+-+ | ||###################| | | |Message Digest| | |+###################+ | | +-------+------+ | |+########## | +--- | | +----------------------+ | | | | +------ | | | +--------------+ | | | |Message Digest|<----------------------+ | | +--------------+ | +--COMPARE +-------------+ | | | +--------------+ | Single | Decrypt(2)| | | |Message Digest|<--------+ Encrypted |<------------+ | | +--------------+ | Data | | +------ +-------+-----+ | | |If the first decapsulation is correct | |then, use the data is sent out by the | |translator after encryption by the | |inter-domain data key | | +--------------------------------------+ | | +-----------------------+ | +--------+----+-----+ | | +--------+----+-----+ | | +--------+----------+ | +----------------+ | |*******************| | Encrypt using | | | |*******************| |---------------------->| Encrypted Data +-+ | |*******************| |inter-domain data key | | | | +*******************+ | +----------------+ | | +*********+ | | +----------+------------+ | | Create Message Digest +--------------+ | +------------------------------>|Message Digest| | +-------+------+ | This encapsulated message travels on the | | inter-domain multicast data group. It is | Append | received by the other peer translators, +-----+ +------+ and the reverse process carried out. | | +----------------------+ +--- | | |+--------+----+-----+ | | +----------------+ |+--------+----+-----+ | | | | |+--------+----------+ | Put into | | Encrypted Data | ||&&&&&&&&&&&&&&&&&&&| |<------------------+ | | ||&&&&&&&&&&&&&&&&&&&| | message | +--------------+-+ ||&&&&&&&&&&&&&&&&&&&| | | |Message Digest| |+&&&&&&&&&&&&&&&&&&&+ | | +--------------+ |+&&&&&&&&&+ | +--- +----------------------+ Coan et al. [Page 31] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.8 Message Sequence Charts 5.8.1 Client Session Key Request and Response The Application APP requests a session key from the HASM Client Daemon residing on the same host. The HASM Client Daemon initiates a SSL Handshake with the designated HASM Server Daemon. After x509 authentication and authorization is successful, the HASM Client forwards the Key Request to the server, which makes access decisions based on the group/port requirements. If Access is permitted, the server hands down the local session key to the client, which forwards it to the application. The server joins both the Local-Data and the Local-Control secure groups if it hasn?t already done so. The client joins the Local-Control group. The application joins the Local-Data group. The client does NOT terminate the SSL/TCP session with the server until it receives the global key. APP----------------------HASM-----------------------HASM CLIENT SERVER | | | |----------------------->| | | Key Request |<------------------------->| | |<----- SSL Handshake ----->| | |<------------------------->| | | | | |-------------------------->| | | Key Request Process | | Validity | |<--------------------------| |<-----------------------| Key Response (local) | | Key Response (local) | | | | | +----------------------------+ | HOST | +----------------------------+ 5.8.2 Server Session Key Request and Response The HASM Server Daemon at Level 1 initiates a SSL Handshake with the designated HASM Server Daemon Level 2. After x509 authentication and authorization is successful, the HASM Server forwards the Key Request to the Level 2 server, which makes access decisions based on the group/port requirements. If Access is permitted, the level 2 server hands down the local session key to the level 1 server, which already has its own local session key that it had sent down to the client and application (Section 5.8.1). The server on level 2 joins both its Local-Data and the Local-Control secure groups if it hasn?t already done so. Note that the Local-Data and Local-Control groups for the server at level 2 are NOT the same as the Local-Data and Local-Control groups for the server at level 1. Also, the server at level 1 (which is a client to the server at level 2) joins the Local-Control group. The server at level 2 also sends in the global key to the server at Coan et al. [Page 32] INTERNET-DRAFT HASM Secure Multicast System November 2001 level 1, which, in turn, forwards it to the client (that has not disconnected because it is still waiting for the global key) --HASM-----------------------HASM-----------------------HASM CLIENT SERVER (level1) SERVER(level2) | | | | | | |<------------------------->| | |<----- SSL Handshake ----->| | |<------------------------->| | | | | |-------------------------->| | | Key Request Process | | Validity | |<--------------------------| | | Key Response (local) | | | |<------------------------>| | |<----- SSL Handshake ---->| | |<------------------------>| | | | | |------------------------->| | | Key Request Process | | Validity | |<-------------------------| | | Key Response (local) | | | | | |<-------------------------| |<--------------------------| Key Response (global) | | Key Response (global) | | | | | | | | 5.8.3 Multicast Data Transmission and Reception The Domain1 server/translator has the R-Local-Data and B-Interdomain-Data keys, and all members in Domain1 have the R-Local-Data and O-Global-Data keys. The Domain2 server/translator has the G-Local-Data and B-Interdomain-Data keys, and all members in Domain1 have the G-Local-Data and the O-Global-Data keys. When some application data has to be sent by the sender in Domain1, it first uses the O-Global-Data key to encapsulate. Then the encapsulated data is further encapsulated by the R-Local-Data key. All members in Domain1 employ double decapsulation, first by the R-Local-Data key and then by the O-Global-Data key. The translator in Domain1 decapsulates using the R-Local-Data key. Further, the translator encapsulates the decapsulated message using the B-Interdomain-Data key and sends it out. This message is picked up by the translator in Domain2, where it is decapsulated using the B-Interdomain-Data key. It is then encapsulated using the G-Local-Data key, and sent out. This double encapsulated multicast message is picked up by the receiver members of Domain2 and double decapsulated, first using the G-Local-Data key and then the O-Global-Data key. Coan et al. [Page 33] INTERNET-DRAFT HASM Secure Multicast System November 2001 APP---------APP---------HASM # HASM---------APP---------APP | | TRANSLATOR # TRANSLATOR | | | | | # | | | Send | | # | | | |---------->|---------->| # | | | | Rec. Translate # | | | | | |------#---->| | | | | | # Translate | | | | | # |---------->|---------->|Rec. | | | # | Rec. | | | | # | | | | | | # |<----------|<----------|Send | | | # Translate Rec. | | | |<-----#-----| | | | | Translate # | | | |<----------|<----------| # | | | Receive Rec. | # | | | | | | # | | | # <------- Domain 1---------> # <---------- Domain 2------> <-------------> Inter-domain 5.8.4 Domain Rekeying over Multicast The message sequence chart below shows the HASM server generates a new P-local key and encapsulates it using the R-Local-Control key for the current multicast session. It then sends the message which is picked up by the HASM clients, which decapsulate it using the R-Local-Control key. The extracted P-Local-Data key is forwarded to the application. The extracted P-Local-Control key is used for all further local control sessions. APP---------HASM-------------APP---------HASM-------------HASM | CLIENT | CLIENT SERVER | | | | | | | | | Generate | | | | New Key | |<---------------------------|<---------------| | Switch Key | Switch Key | |<----------| |<----------| | | Key Resp. | | Key Resp. | | | (local) | | (local) | | Switch Key | Switch Key | | | | | | | | | | | | +----------------+ +----------------+ | HOST | | HOST | +----------------+ +----------------+ Coan et al. [Page 34] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.8.5 Domain Rekeying after Reauthentication over Unicast The message sequence chart below shows the HASM server creates a trigger message and encapsulates it using the R-Local-Control key, and then sends it over the control multicast session. All HASM clients which are subscribed to this secure control multicast session, pick up the message, decapsulate it using the R-Local-Control key. Then the SSL handshake is restarted by each client. After successful authentication, the key request is sent again, and if access is granted, the P-local key is sent to the successful client over the secure SSL/TCP connection. The extracted P-Local-Data key is forwarded to the application. The extracted P-Local-Control key is used for all further local control sessions. APP----------------------HASM-----------------------HASM | CLIENT SERVER | | | | | Generate trigger | |<--------------------------| and | Reauthenticate | new key | with server | | | | | |<------------------------->| | |<----- SSL Handshake ----->| | |<------------------------->| | | | | |-------------------------->| | | Key Request Process | | Validity | |<--------------------------| |<-----------------------| Key Response (local) | | Key Response (local) | | | |<--------------------------| |<-----------------------| Key Response (global) | | Key Response (global) | | | | | | | | +----------------------------+ | HOST | +----------------------------+ Coan et al. [Page 35] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.9 Message Formats This section gives the formats for HASM messages and headers. 5.9.1 HASM Header Format The following is the format of a HASM header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol ID - 2 octets Protocol Version - 1 octet Protocol Command - 1 octets Possible values: Protocol ID = 101(numeric) Protocol version = 2(numeric) = (Currently on version 2) Protocol command = numeric COMMAND_HASM_KEY_REQUEST 0 COMMAND_HASM_KEY_RESPONSE 1 COMMAND_HASM_KEY_REJECT 2 COMMAND_HASM_KEY_TRIGGER 3 COMMAND_HASM_APPL_DATA 4 5.9.2 HASM Key Format The following is the format of a HASM key. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast salt value (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast salt value (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast password value (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast password value (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Encryption Algorithm type (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast Encryption Algorithm type (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Message Digest Algorithm type (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast Message Digest Algorithm type (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Type | +-+-+-+-+-+-+-+-+ Coan et al. [Page 36] INTERNET-DRAFT HASM Secure Multicast System November 2001 Multicast Salt value - 8 octets - Used to indicate the salt. Multicast Password value - 8 octets - Used to indicate the password. These two values are used to create the key. Multicast Encryption Algorithm type - 8 octets - Used to indicate the symmetric algorithm for encryption and decryption Multicast message Digest Algorithm type - 8 octets - Used to indicate the message digest algoritym used in conjunction with the encryption algorithm Key type - 1 octet - Used to indicate either a global key or a local key Possible values: Multicast Salt value = Any randomly generated salt (character string) Multicast Password value = Any randomly generated password (character string) Multicast Encryption algorithm type = Character string, such as Null, des_ecb, des_ede, des_ede3, des_cfb, des_ede_cfb, des_ede3_cfb, des_ofb, des_ede_ofb, des_ede3_ofb, des_cbc, des_ede_cbc, des_ede3_cbc, desx_cbc, rc4, rc4_40, idea_ecb, idea_cfb, idea_ofb, idea_cbc, rc2_ecb, rc2_cbc, rc2_40_cbc, rc2_64_cbc, rc2_cfb, rc2_ofb, bf_ecb, bf_cbc, bf_cfb, bf_ofb, cast5_ecb, cast5_cbc, cast5_cfb, cast5_ofb, rc5_32_12_16_cbc, rc5_32_12_16_ecb, rc5_32_12_16_cfb, rc5_32_12_16_ofb Multicast Message Digest algorithm type = Character string, such as Null, md2, md4, md5, sha, sha1, dss, dss1, mdc2, ripemd160 Key Type = numeric value, either HASM_KEY_LOCAL 0 HASM_KEY_GLOBAL 1 5.9.3 HASM Key Request Format The following is the format of a HASM key request message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Multicast Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coan et al. [Page 37] INTERNET-DRAFT HASM Secure Multicast System November 2001 HASM Header - The predefined header with command = COMMAND_HASM_KEY_REQUEST Requested Multicast Port = Port number of the multicfast group (numeric) Requested Multicast Address = Class D address for the multicast group (character string) 5.9.4 HASM Key Response Format The following is the format of a HASM key response message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast salt value (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast salt value (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast password value (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast password value (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Encryption Algorithm type (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast Encryption Algorithm type (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Message Digest Algorithm type (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multicast Message Digest Algorithm type (32:63) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Type | +-+-+-+-+-+-+-+-+ HASM Header - The predefined header with command = COMMAND_HASM_KEY_RESPONSE HASM Key - The predefined message with the required components Coan et al. [Page 38] INTERNET-DRAFT HASM Secure Multicast System November 2001 5.9.5 HASM Key Reject Format The following is the format of a HASM key reject message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rejection Reasons (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Rejection Reasons (32:63) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Rejection Reasons (64:95) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Rejection Reasons (96:127) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HASM Header - The predefined header with command = COMMAND_HASM_KEY_REJECT Rejection reason - Character string with reasons of rejection 5.9.6 HASM Key Trigger Format The following is the format of a HASM key trigger message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HASM Header - The predefined header with command = COMMAND_HASM_KEY_TRIGGER 5.9.7 HASM Application Data Format The following is the format of a HASM application data message. Coan et al. [Page 39] INTERNET-DRAFT HASM Secure Multicast System November 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID. | Proto Ver. | Proto Command.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uncoded Data Length | Coded Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulated Data (0:31) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Encapsulated Data (32:64) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Encapsulated Data (64:95) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | +-+-+-+-+-+-+-+ HASM Header - The predefined header with command = COMMAND_HASM_APPL_DATA Uncoded Data Length = 2 octets = Length of the uncoded Data (numeric) Coded Data Length = 2 octets = Length of the coded Data Encapsulated Data = variable length = Encrypted data with message digest 6 Acknowledgment and Disclaimer This document is based on work supported by DARPA under contract number F30602-00-C-0065. Any opinions, findings, and conclusions or recommendations expressed in this internet draft are those of the authors and do not necessarily reflect the views of the United States Air Force. 7 References [CGI99] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor and B. Pinkas, A taxonomy of multicast security issues and efficient constructions. Infocom 1999. [CJ97] John Clark and Jeremy Jacob, "A Survey of Authentication Protocol Literature: Version 1.0," unpublished manuscript, November 1997. [C00] Ernie Cohen, "TAPS: A First-Order Verifier for Cryptographic Protocols," Journal of Computer Security, to appear. Short versions appear in Computer Security Foundations Workshop, June 2000 and in the Proceedings of the ACM Conference on Computer-Aided Verification, July 2000. Coan et al. [Page 40] INTERNET-DRAFT HASM Secure Multicast System November 2001 [DH76] W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, vol. IT-22, no. 6, pp. 644-654, November 1976. [KNT91] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution of the Kerberos Authentication Service," Proceedings of the Spring EurOpen Conference, Troms, Norway, April 1991. [L95] Gavin Lowe, "An Attack on the Needham-Schroeder Public Key Authentication Protocol," Information Processing Letters, pp. 131-136, Volume 56, Number 3, November 1995. [L96] Gavin Lowe, "Breaking and Fixing the Needham Schroeder Public-Key Protocol Using FDR," In Proceedings of TACAS, Lecture Notes in Computer Science, volume 1055, pages 147-166, Springer Verlag, 1996. [NS78] Roger M. Needham and Michael D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, pp. 993-999, volume 21, number 12, December 1978. [WGL98] C. K. Wong, M. Gouda, and S. Lam, "Secure Group Communication using Key Graphs," ACM SIGCOMM '98, pp. 68-79, September 1998.. Authors' Addresses: Brian Coan coan@research.telcordia.com Telcordia Technologies 445 South Street Morristown, NJ 07960 USA Vikram Kaul vkaul@research.telcordia.com Telcordia Technologies 331 Newman Springs Road Red Bank, NJ 07701 USA Sanjai Narain narain@research.telcordia.com Telcordia Technologies 445 South Street Morristown, NJ 07960 USA William Stephens wes@research.telcordia.com Telcordia Technologies 331 Newman Springs Road Red Bank, NJ 07701 USA Coan et al. [Page 41] INTERNET-DRAFT HASM Secure Multicast System November 2001 Intellectual Property Claims None. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Coan et al. [Page 42]