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
<draft-coan-hasm-00.txt>
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]