Subject: Security Considerations for TRACK Protocols

From: Brian Whetten <[email-masked]>
Date: Wed, 09 Feb 2000 08:58:01 -0800

Someone reported that the file was corrupted, so it is attached below.
Sorry to add to everyone's mailbox!
Brian

Internet Engineering Task Force                             T. Hardjono
INTERNET-DRAFT                                          Nortel Networks
draft-ietf-rmt-track-security-00.txt                         B. Whetten
January 12, 2000                                               Talarian

             Security Requirements For TRACK Protocols

              <draft-ietf-rmt-track-security-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

This document discusses the security issues within TRee-based 
ACKnowledgement (TRACK) reliable multicast protocols, and identifies 
some constraints and requirements for security provisions for these 
protocols.  Based on the constraints and requirements, the document 
proposes a separation of data packet confidentiality and authentication, 
from transport layer protection.  It proposes that TRACK protocols be 
primarily concerned with group authentication of control and data 
packets, to protect against attacks on the transport infrastructure.  It 
proposes that data confidentiality and source authentication be provided 
separately from this low level group authentication, ideally at the 
application level.  We show that this is particularly important for 
TRACK protocols, because of the requirement that the interior control 
nodes only optionally have access to the data packet payload.

Specifically, the current work proposes that data and control packet 
authentication be provided using IPsec-based authentication at the 
network layer.  This approach allows an interior control node to 
authentically retransmit a lost data packet (which remains encrypted 
under the separate data-encryption key) to its own children (a set of 
Receivers), while making use of the IPsec features, such as protection 
against replay attacks.  

This document then provides a specific proposal for how group keys 
should be divided up among group members, for control and data packet 
authentication.  While providing some rationale for divorcing this 
proposal from that of source authentication and data confidentiality, it 
does not provide a specific proposal for those pieces.

1. Background: The Multicast Security Problem

The problem of multicast security can be divided into three general 
areas of concern:
- Data Encryption and Source Authentication.  The method used to 
encipher or scramble the multicast data, and verify the identity of 
the sender of this data.
- Key Distribution.  The method used to securely distribute group 
keys and keying material to the members of a group, for use in 
decrypting or authenticating the data or control packets.
- Infrastructure protection.  Mechanisms used to protect the 
multicast infrastructure itself, and to minimize the ability of an 
intruder to deny service to legitimate users.

The security of reliable multicast protocols falls primarily into the 
third category of problems.  Complete denial of service protection must 
start at the network level (i.e. IP Multicast), with controls placed on 
senders from overloading the network with brute force "spamming", as 
well as with authentication of control packets, to keep users from 
corrupting the state of the IP Multicast protocols.  A transport 
protocol needs to address the same issues, checking to make sure that 
senders are not sending more data than they are allowed (such as with 
enforceable congestion control), and authenticating control packets, to 
protect the protocol state.  Control packet authentication is 
particularly important in TRACK protocols, because of their use of 
interior control nodes (for example, in RMTP-II, DRs and TNs) to 
increase scalability.

An optional extension to the requirement of infrastructure protection is 
that of infrastructure privacy.  Some applications require that the 
headers of the network packets be encrypted, to provide protection from 
network analysis attacks.

2. Independence of RM Security

The security of reliable multicast (RM) protocols is part of the larger 
problem of the security of the multicast infrastructure, which also 
consists of the security of the multicast routing protocols.

Since RM protocols and multicast routing protocols exist at different 
layers in the protocol stack, and since different RM protocols may be 
employed with different multicast routing protocols, it is useful from a 
security perspective to treat these two security problems separately.  
In addition, although in many instances the topology of RM 
infrastructure may coincide with that of the multicast routing protocol, 
such symmetry cannot be assumed for all cases.

Similarly, from a design perspective, the problem of securing the data 
stream (e.g. through content encryption) should be separated from the 
issue of securing reliable multicast protocols.

Although we treat RM-security as an independent problem from other 
multicast security problems, this does not preclude using the solutions 
in other areas in order to solve the security needs of RM. For example, 
the use of IPsec technology at the IP layer to authenticate multicast 
routing protocol control-packets can also be used to authenticate RM 
control-messages.  However, the instance of deploying IPsec in both 
cases must be distinguished and treated separately.

3. RMTP-II Overview

While not necessarily typical of all TRACK protocols (such as TRAM 
[KCWP00]), we use the RMTP-II protocol as an example for analysis and 
discussion.  The RMTP-II protocol features a number of entities which 
participate in a logical tree or hierarchy and which exchange control-
messages with each other.  The entities are the Top Node (TN), the 
Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver 
Nodes (RN).  

RMTP-II places receivers into local regions, where each region is 
assigned to a DR.  These groups are arranged hierarchically as a tree 
rooted at the TN, with the DRs representing the nodes of the tree, and 
the receivers as the leaves.  The senders connect directly to the top 
node, at the top layer of the hierarchy.  The receivers send their 
control-messages (ACKs, NACKs, etc.) to the DR of their region.  
Retransmission of lost packets may be done locally by the DR of a 
domain, or globally from the sender.  Each DR sends their control 
messages to the DR at the next level up the hierarchy.  This process is 
repeated until the TN, who then forwards the control messages to the 
appropriate sender.  The DRs and TN aggregate the positive 
acknowledgements from the receivers, and suppress the redundant negative 
acknowledgements, in order to solve the ACK/NACK implosion problem.

A DR maintains a local multicast group to just its children, and 
subscribes to the local multicast group of its parent.  A DR uses this 
local multicast group for retransmissions to its children.  While RMTP-
II uses multicast for retransmission from a DR, other TRACK protocols 
may choose to optionally use unicast.

RMTP-II distinguishes between a data channel and a control channel.  A 
data channel is a global multicast group created using the underlying 
multicast routing protocol.  A control channel is the interconnected 
topology of control nodes, for handling error recovery and positive 
packet acknowledgements.

In order to obtain data packets from the Sender, a Receiver in a given 
RMTP-II region must join the multicast group (i.e. the data channel).  
The DR of that region must join every multicast group that its 
descendants have joined.  Note that the DRs are not responsible for 
forwarding the data packets multicast by the Sender, since that data 
stream is propagated by the underlying multicast routing protocol.

The figure below illustrates an RMTP-II tree with multiple control 
nodes.

                                          HACKs
              -----------> (Top Node)----------------->(Sender node)
             ^                ^^^                             |
             |              /  |  \                           |
       HACKs |            /    |    \                         |
             |          /      |      \                       |
             |        /        |        \     (Designated     |
                    /          |          \    Receiver       |
                  /            |            \   node)         v
      Control   D R           D R           D R  <------------|
      Channel   ^^            ^^^            ^^               | Data
               / |           / | \           | \              | Channel
              /  |          /  |  \          |  \             |
             /   |         /   |   \         |   \            v
           RN   RN       RN   RN   RN        RN   RN   <------
                       (Receiver Nodes)

4. TRACK Protocol Security Issues and Requirements

This section details the security requirements for TRACK protocols which 
are similar to RMTP-II.  These requirements include general multicast 
transport requirements, as well as some requirements specific to TRACK 
protocols.

4.1 Background

In addressing the security issues specific to TRACK protocols, it is 
useful to consider the general aspects of security relating to reliable 
multicast.

 - Layer in which security is applied:
The two layers in which security mechanisms are deployed are 
typically the network layer and the application layer.  In the 
network layer the protocol that is the most commonly used is the 
IPsec protocol, which provides authentication and/or encryption.  In 
either case, with IPsec the transport headers (and IP headers) are 
protected.  When authentication and/or encryption is applied at the 
application layer, neither the transport headers nor the IP headers 
are protected.

 - Types of authentication:
  - Source-authentication: If public key (asymmetric) cryptography is 
deployed, where only the sender knows the secret-half of the 
public key pair, then unique "source-authentication" can be 
established.
  - Group-authentication: If shared key (symmetric) cryptography is 
deployed and the key is shared by more than two parties, then 
only "group-authentication" can be established. This means that a 
receiver in a group is only certain that the entity that sent the 
message is in possession of the symmetric-key, and is thus 
assumed to be a member of the group sharing the key.

In the following, the TRACK specific requirements are further 
elaborated.

4.2 Authentication of Control-Messages

As stated above, the directly relevant security concern for TRACK 
protocols is protection of the multicast infrastructure, particularly of 
the control tree, in order to provide protection against replay or other 
attacks which seek to corrupt the state of the transport protocol.  The 
authentication of control messages exchanged among TRACK protocol 
entities represents the minimal security mechanisms necessary to do so.

Two types of authentication mechanisms can be adopted, corresponding to 
the two basic types of cryptosystems.  In the context of reliable 
multicast, throughput and latency is typically of high importance, and 
group-authentication based on symmetric cryptography appears to be 
preferable.  

Given this, the efficiencies of symmetric key based authentication 
appear to outweigh the benefits of public key based authentication. 
There are potentially cryptographic schemes that can provide the unique 
source-authentication of public key cryptography while providing the 
performance characteristics of symmetric key based authentication (e.g. 
efficient digital signing of the hash-value of several data packets).  
However, at the present time, for the general case of infrastructure 
protection, the complexities of these options appear to outweigh the 
benefits.

Thus, in summary, for TRACK protocol control-messages, explicit group-
authentication at the IP layer should be deployed using symmetric 
cryptography.  Although a number of technologies are available, we 
propose specifically IPsec-based authentication using a keyed-hash 
function [KA98b,MG98a,MG98b] due to its growing use and availability.

We denote the symmetric key used for control message authentication as 
the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by 
all DRs and the TN within a given RMTP-II or TRACK hierarchy.  The key 
is independent of any data stream, and is used to authenticate control 
packets exchanged among the DRs/TN.  

4.3 Non-Decipherability of Data Packets by DRs

RMTP-II requires that a Designated Receiver Node (DR) join all of the 
multicast groups that its descendants have joined.  This is also true of 
the Top Node (TN).

For TRACK protocols it is preferable that authentication methods based 
on a symmetric key be deployed due to performance reasons.  This may be 
achieved explicitly, such as by using a keyed hash function, or 
implicitly using encryption (where a successful decryption implies the 
ciphertext is both unmodified in transit and was generated by a holder 
of the symmetric key).

However, TRACK protocols have a further requirement, namely that their 
repair nodes (i.e. DR and TN) be (optionally) prevented from reading the 
multicast data. More specifically, we perceive that DRs may be 
administered as part of a reliability service offered by third parties 
such as ISPs.  These third parties may refuse the ability to decipher 
data packets in order to avoid the legal ramifications of having access 
to the data contents.  Thus, from the ISP perspective, TRACK protocols 
must allow them to prove to the content-owner that they do not posses 
the means to alter the contents transmitted through the multicast 
groups.

Given the above requirement of the DRs/TN and the need for fast 
authentication, we propose:

- the separation of data stream confidentiality using either a symmetric 
or asymmetric key from data authentication using a symmetric key (i.e. 
explicit group-authentication).

- data stream confidentiality will be conducted at the application 
layer, while data authentication using a symmetric key will be 
conducted at the network layer.

- since the DRs/TN may be (optionally) prevented from reading the 
multicast data, two (2) different keys must be deployed corresponding 
to the needs of data stream confidentiality and data group-
authentication.

4.4 Authentication of Data Retransmissions

In TRACK protocols, retransmissions of data packets may come from the 
original source, or from a different (DR) node.  This local recovery is 
an important tool for increasing the scalability and latency of a 
protocol.  In the context of security, it raises the question as to what 
authentication methods should be used on these packets.

(a) If source authentication (using public key cryptography) and data 
confidentiality (including implicit group authentication) is 
applied at the application layer, the DR can simply replay the data 
(i.e. payload) unmodified to the querying receivers, either via 
unicast or local multicast.

(b) If, however, explicit group authentication (using a symmetric key) 
was applied at the network layer (e.g. using IPsec), then the DR 
cannot simply replay the packet due to restrictions at the IP 
layer.  Thus, in this case the DR must re-apply the group-
authentication.

Taking case (b) further, there are two options corresponding to 
whether retransmission by the DR is performed via unicast to a 
receiver or via multicast.

(i) If the retransmission is unicast to a given receiver, then it 
is preferred if the DR and the receiver share a separate 
symmetric key for this purpose.

(ii) If the retransmission is via multicast to a subgroup (as is 
the case in RMTP-II), then the DR can either use the existing 
group-shared symmetric key or use a separate symmetric key only 
for the subgroup under the DR.  We propose to use the later 
approach, which means that a DR and its children (receivers) 
must share a separate symmetric key for explicit group 
authentication at the IP layer.

4.5 Keys for Data Confidentiality and for Authentication

As mentioned above, we propose the separation of data stream 
confidentiality using a symmetric key encryption (effecting an implicit 
group-authentication) from data authentication using a symmetric key and 
a keyed hash function (i.e. explicit group-authentication).

We now denote the symmetric key for data stream confidentiality at the 
application layer as the GroupDataKey. Only the source and valid 
receivers will have a copy of the GroupDataKey, which is delivered to 
them through the appropriate Group Key Management (GKM) protocol that 
identifies and verifies the members individually.  In the case where the 
DRs and the TN are not permitted to read the multicast data, they must 
be prevented by the GKM protocol from obtaining the GroupDataKey.

We denote the symmetric key for explicit group-authentication at the 
network layer as the GroupAuthKey. The GroupAuthKey is distinct from the 
GroupDataKey. For TRACK protocols, we propose the use of IPsec with 
keyed hashing at the network layer to provide explicit group-
authentication using the GroupAuthKey.  Unlike the GroupDataKey, the 
GroupAuthKey is known by all entities involved in the multicast.  This 
includes all interior node entities (e.g. TN, DR), the Sender/Source and 
the Receivers.

4.6 Authenticity of NACK and other Control Packets

In TRACK protocols, a DR responds to a NACK from one its children 
(typically a receiver) by re-transmitting the lost packet via local 
multicast.  This basic behavior can be open to abuse by an attacker who 
injects spurious NACK messages towards the DR, effecting a local 
multicast to all children of the DR.  In itself this is a waste of 
bandwidth and may result in a denial of resource to the group members.  
Other control packets directly impact the state of the group, such as 
the group membership, and could also be used in denial of service 
attacks.

To counter these types of attack, the control messages themselves must 
be authenticated by the DR.  Digital signatures using public key 
cryptography could be applied to the control messages.  However, this 
approach would be inefficient due to the high CPU cost of public key 
encryption.  Also, it would require creating a separate security 
association with each child of the DR.

Instead, we propose that NACK and other control messages from a child 
(receiver) to its DR be protected using symmetric IPsec based 
authentication.  This requires the two parties to first establish a 
Security Association (SA) and a shared symmetric key.  The symmetric key 
can be unique per child, or be uniform over a subgroup of receivers 
(i.e. those under the DR).

4.7 Fault Recovery

In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II 
provides automatic mechanisms for failing-over to another DR or backup 
TN.  This reconnection needs to happen quickly, so that the child can 
rejoin the data stream before too much data has been missed to recover 
from.  If a child needs to get a new key for that DR/TN, this can be a 
bottleneck.  Given that the key distribution infrastructure may be 
centralized, and a majority of receivers may need to fail over at the 
same time, this presents a major opportunity for network congestion.

The RMTP-II entities are given the address of their backup control node 
at startup time.  While these addresses can change, they are expected to 
always have the addresses of one or more backup nodes.  When 
implementing security features, each child should be required to keep 
the key for its primary backup DR/TN.  Optionally, it may need to keep 
the keys for each of the backup control nodes it is using.

4.8 Implementation with Different Levels of OS Protection

A TRACK protocol can be implemented in (at least) one of three ways.
- Application level.  Most implementations of TRACK protocols for the 
near future are expected to operate in the application level of the 
OS, running on top of UDP. 
- Kernel.  As TRACK protocols become bundled with standard operating 
systems, it is expected to become a kernel module, and run directly 
over IP.
- Virtual machine.  Some TRACK entities (particularly senders and 
receivers) will be run in virtual machines, such as when implemented 
as a Java applet.

TRACK protocol security must accommodate all three of these options.  
This raises the following issues.
- Application Level.  One advantage of application level 
implementations is their flexibility.  These implementations could 
use either IPsec routines, the application layer security functions, 
or both.
- Virtual Machines.  There are issues trying to use IPsec with 
virtual machines such as Java, which have to date hindered the 
support of IPsec through native Java applets.  This makes it 
important for a TRACK protocol to optionally be able to use only 
application level security.
- Kernel Implementations.  As a TRACK protocol becomes bundled with 
operating systems, it is expected that IPsec will also become bundled 
with the OS.  To avoid having to use less trusted software in the 
application level, the TRACK protocol will have to be able to use a 
kernel level security system (such as IPsec) for its transport level 
security needs.

4.9 Separate Regional Protection

TRACK protocols are expected to be used for content distribution from a 
few senders to many receivers.  In the case of applications that 
distribute critical data to many different organizations, it is not 
enough to trust all receivers.  For example, a market data feed provider 
could be using a TRACK protocol to distribute live market data feeds to 
competing financial institutions.  In this situation, the data feed 
provider needs to be able to protect individual companies from corrupted 
control packets from other customers (which could be generated either 
intentionally, or more likely, unintentionally) which would cause denial 
of service.

As we propose in the next section, a TRACK protocol must provide 
separate regional keys for the group-authentication of control packets 
sent from the receivers of different DRs.  This allows the 
authentication of control-messages for each set of receivers (part of 
one customer) to be done separately (from another set of receivers, as 
part of different customer). Since for each set of receivers a different 
key is used, this limits the ability of a customer to perpetrate denial 
of service attacks against other customers. 

4.10 Piracy of Pay-Per-Use Data

A common scenario for TRACK protocols involves pay-per-use data 
distribution, such as live market data, pay-per-view video signals, or 
paid subscriptions to software updates.  In this scenario, a receiver 
cannot be trusted to not give its group keys to outside entities, who 
are trying to get free service.  We mention this requirement since it is 
different than point-to-point security.  However, this requirement is 
the responsibility of the application level security.

5. Architecture Recommendations

The previous section detailed some of the specific requirements and 
issues for TRACK protocol security, along with some individual 
recommendation on handling each one.  Given those requirements, we 
propose the following architecture recommendations for implementing 
security with TRACK protocols.  

5.1 Separation of Security Responsibilities

As detailed above, TRACK protocols are primarily concerned with 
protection of the network infrastructure, rather than with issues such 
as data confidentiality and source-authentication.  Therefore, we 
recommend that TRACK protocols SHOULD provide:
   (a) group authentication of control packets, and
   (b) optional group authentication of data packets
Optionally, TRACK protocols MAY choose to provide:
   (c) optional privacy of data and of control packet headers.  
To accomplish this, we recommend that TRACK protocols use IPsec 
technology at the network layer, while letting application level 
security perform additional functions as needed.  For implementations 
that do not have access to IPsec, and are not implemented as part of the 
OS, application level security can be used instead--although this of 
course risks incompatibility with other implementations.

The separation of group-authentication of data from both data source-
authentication and data-confidentiality is tightly coupled to the choice 
of recommending IPsec for the group authentication.  These two choices 
are motivated by the following:

(a) Non-Decipherability of data by interior control nodes: it is a 
requirement of TRACK protocols that in some deployments, its control 
entities (e.g. TN, DR) be unable to decipher the data packet.  Thus, 
the GroupDataKey for data encryption and GroupAuthKey for group-
authentication must be distinct.  It is not sufficient to simply use 
an identical key (for the GroupDataKey and GroupAuthKey) and to 
instruct the TRACK protocol entities to avoid deciphering the data 
packets.  It must be provably shown that the interior control nodes 
do not have the ability to decipher the data packets (even if they 
wish to do so).

(b) Use of IPsec technologies: considerable effort has been invested in 
developing the IPsec architecture and protocols [KA98a, KA98b], and 
a growing number of vendors are supporting IPsec.  The IPsec suite 
offers a number of features, including some protection against 
replay attacks.

(c) Multicast IPsec: the IPsec architecture has intentionally allowed 
the use of IPsec for IP multicast without changes to the basic 
constructs within the IPsec suite.  Currently, work is proceeding 
towards the establishment of a standard mechanism to select the 
Group Security Association (Group SA or GSA) for multicast and a 
method to disseminate the GSA to the valid members of the group 
[HCM98,HH99a].

(d) Appropriate Level:  since the primary purpose of transport level 
security is to secure the infrastructure at a transport level, using 
a network or transport level security protocol allows each to be 
implemented together--either in the OS, or in the application layer.

5.2 Division of Responsibilities

Given this fundamental division between application and transport 
responsibilities, we divide the security responsibilities in to four 
parts.

Network Responsibilities (IP and IP Multicast)
----------------------------------------------

- Admission controls on senders--to protect against "brute 
  force" spamming attacks.
- Authentication of routing control packets--to protect 
  the routing infrastructure from denial of service attacks.

Transport Responsibilities (TRACK Protocols)
------------------------------------
- Protection of the control messages from replay attacks
  and other denial-of-service attacks.
- Optional: protection of data packets from replay attacks.
- Optional: encryption of control messages to minimize
  network analysis by attackers.

End to End Responsibilities (Application)
-----------------------------------------
- Source authentication--to verify the authenticity of data,
  and provide optional non-repudiation of data.
- Data encryption--to provide data confidentiality.

Key Management Infrastructure
-------------------------------
- Distribution of transport and network layer keys: authentication
  of individual hosts, and distribution of keys to those hosts
- Application level key distribution: authentication of
  individual processes, and distribution of keys to those processes
- Optional: periodic rekeying--group keys periodically need
  to be changed, both after a certain time limit has expired,
  and/or after the group membership changes.

The figure below shows how these components relate to each other.  TRACK 
protocols can be used without any additional security at the IP/IP 
Multicast level, although this will not provide full protection from 
denial of service attacks.  TRACK protocols will be able to be used on 
top of UDP or raw IP/IP Multicast.  A TRACK protocol can use either 
IPsec or application level security for its network security 
requirements, although we recommend using IPsec wherever possible.
                       +--------------------+       +----------+
+--------------+<----->|    Application     |<----->|  App Sec |
|              |       +--------------------+   |==>|          |
|              |       |       TRACK        |<--|   +----------+
|     Key      |<----->+          +---------+   |-->|          |
|  Management  |       |          |   UDP   |       |   IPsec  |
|              |       +--------------------+       |          |
|              |<=====>|  IP, IP Multicast  |<=====>|          |
+--------------+       +--------------------+       +----------|

  <===> Optional

When a data packet is to be sent to the multicast group, the 
Sender/Source first (optionally) enciphers the data packet using the 
GroupDataKey above the RM/transport layer.  It is then passed to the 
RM/transport layer, which attaches the necessary RM headers.  The result 
is then passed down to the IP layer where IPsec authentication is 
established (using the GroupAuthKey).

A Receiver in the multicast group would be in possession of both the 
GroupDataKey and the GroupAuthKey, and thus will be able to first 
authenticate the data packet using the GroupAuthKey, and then continue 
to decipher the data packet using the GroupDataKey.

A Designated Receiver Node (DR) will possess the GroupAuthKey (but not 
the GroupDataKey), and thus will only be able to authenticate the packet 
using the GroupAuthKey using IPsec.  After verifying the authenticity of 
a received data packet, a DR will be able to retransmit the (enciphered) 
data packet to its children, either via unicast or region-based local 
multicast.  A retransmission of a lost data packet from a DR will be 
authenticated using a SubgroupAuthKey (see below) which is a symmetric 
key shared by a DR and all its children Receivers only.

Again, although the current work proposes the use of unicast IPsec and 
multicast IPsec at the network layer, it does not preclude the use of 
other authentication technologies at the network layer or at the 
RM/transport layer.  Such technologies, however, will have to address 
much of the same issues faced by IPsec, including prevention of replays, 
the creation and maintenance of state (i.e. "Security Associations") 
associated with the GroupAuthKey, the Sender and Receiver(s), and other 
features and supporting mechanisms.  It is precisely the growing 
availability of IPsec that motivates the current work to choose IPsec 
for network layer authentication for both data and control packets.

5.3 TRACK Keys

In general, each node in the hierarchy must be able to authenticate 
itself to the key management entity/server, before it will be allowed to 
receive any of the below keys.  We assume the implementation of a key 
management infrastructure, which interfaces with the DRs and TNs, as 
well as the senders and receivers.  

We propose that this key management system be responsible for 
distributing the following TRACK protocol keys:

 -  GroupDataKey: 
The GroupDataKey is the unique symmetric key for data encryption 
shared by all members of a multicast group, excluding the interior 
tree entities.  Typically, one GroupDataKey is associated with one 
multicast group.  The GroupDataKey is used to provide access control 
to the data packet by way of the Sender/Source enciphering the data 
packet.  Since only the Receivers hold the copy of the GroupDataKey, 
only the Receivers will be able to decipher the data packets.  This 
is an optional key, which does not directly concern the TRACK 
transport.

 -  GroupAuthKey: 
The GroupAuthKey is the unique symmetric key shared by all members 
of a multicast group, including the interior control nodes.  One 
GroupAuthKey is associated with one multicast group.  The purpose of 
the GroupAuthKey is to provide authentication of the (possibly 
enciphered) data packets.  In the context of IPsec authentication, 
this can be achieved using a keyed hash function, such as HMAC-MD5-
96 [MG98a] and HMAC-SHA-1-96 [MG98b].

 -  SubgroupAuthKey: 
The SubgroupAuthKey is the unique symmetric key shared only by 
entities within a given local region, consisting of a DR and its 
children (consisting of one or more Receivers, and possibly one 
child DR). The SubgroupAuthKey is used by the parent in a local 
region to provide group-authentication for the (lost) data packets 
(still enciphered under the GroupDataKey) which are retransmitted to 
the Receivers in the region, either via unicast or via subtree-
multicast.  The SubgroupAuthKey is also used by the entities in a 
region to group-authenticate control messages that are exchanged 
with each other. Similar to the GroupAuthKey, we propose the use of 
IPsec based authentication via keyed hash function.

Note that for region-based retransmission of lost packets and for 
control-packet authentication, the SubgroupAuthKey is used instead 
of the GroupAuthKey (not both).

Note that if a DR happens to be a child within a region and at the 
same time a parent within its own region, then that DR will hold two 
distinct SubgroupAuthKeys corresponding to the two regions.

In the future, RMTP-II hopes to take advantage of subtree-multicast, 
where a packet can be sent to a constrained piece of the multicast 
tree.  Ideally, a subtree-multicast only goes to the pieces of the 
tree that have lost a packet.  In this case, additional region keys 
would have to be distributed, that spanned multiple levels of the 
hierarchy.  We will leave this consideration for a future time, 
however, since subtree-multicast does not yet exist in a deployable 
form.

 -  InteriorNodeKey: 
The InteriorNodeKey is a symmetric key shared by all interior 
control nodes within a given TRACK hierarchy.  The key is 
independent of any data stream, and is used to authenticate control 
packets exchanged among the DRs/TN.  Should a child-DR request a 
retransmission of a lost data packet from its parent-DR, then the 
parent-DR will deliver the (encrypted) lost packet to the child-DR, 
authenticated using the InteriorNodeKey.

Before the child-DR retransmits this lost data packet to its own 
region, it must first authenticate the packet from the parent-DR 
using the InteriorNodeKey.  It must then use its own SubgroupAuthKey 
of the region headed/parented by that child-DR to provide 
authentication for the retransmitted data packet.  

6. Limitations

The proposed security architecture has certain limitations.  These 
include:

(a) Brute Force Attacks.  At the transport level, no admission controls 
can be put in place to throttle a sender which is generating lots of 
spurious packets to a multicast address.  This is the requirement of 
the network level.  At the present time, no accepted standard exists 
for doing so at the IP Multicast level.

(b) Key Corruption.  The recommended group key architecture makes a 
careful tradeoff between the need to distribute many keys, and the 
need to localize the effects of a node which is compromised. This 
proposal allows a local receiver to perpetrate denial of service 
attacks to its local DR, and the receivers served by that DR.

(c) Privacy.  In order to prevent network traffic analysis attacks, the 
group keys can be used with IPsec to encrypt the packets sent to the 
group, in addition to doing packet authentication.  However, it must 
be recognized that this is not a general solution for data privacy.  
In particular, the group keys can easily be passed from a valid 
receiver to an unauthorized receiver, to enable piracy of pay-per-
use services.  This is reasonable, as data privacy is not considered 
part of the scope of TRACK protocols.

(d) Multicast IPsec.  Although currently IPsec is generally implemented 
for pair-wise (one-to-one) communications between one sender and one 
receiver, the design of IPsec itself allows for usage in IP 
multicast.  Currently the Security Association (SA) definition 
requires the Security Parameter Index (SPI) to be selected by the 
receiver [KA98a].  However, since in IP multicast a group address 
may be associated with multiple receivers, the existing method of 
selecting the SPI must be re-interpreted.  Hence, in the context of 
"Multicast IPsec", a pre-defined entity (e.g. the source, or the key 
server/manager) must first create the Group-SA (including selecting 
the SPI) and deliver the Group-SA to all the members of the group 
(by either the "push" or "pull" paradigm).  Thus rather than being a 
modification to the IPsec specification, this requirement simply 
means that additional protocols are needed to establish a shared 
Group-SA.  One possible approach for the Group Key Management (GKM) 
protocol is to also deliver the Group-SA (and other keying material) 
to the receiver at the same time it delivers the GroupDataKey 
[HCM98].

7. Summary

In summary, in the current work we have proposed for TRACK protocols the 
separation of data stream confidentiality using a symmetric key (i.e. 
implicit group-authentication) from data authentication using a 
symmetric key (i.e. explicit group-authentication). Data stream 
confidentiality using a symmetric key will be conducted at the 
application layer, while data authentication using a symmetric key will 
be conducted at the network layer.  Since the DRs/TN may be (optionally) 
prevented from reading the multicast data, two (2) different symmetric 
keys must be deployed corresponding to the needs of data stream 
confidentiality and data group-authentication.

This proposal follows a number of requirements, some of which are 
specific to TRACK protocols.  The use of group-authentication at the 
network layer is:
   - for protection of the transport and IP headers.
   - to allow a DR to authentically retransmit lost packets to 
     a destination address (unicast or local multicast) different 
     from the original multicast group address.
   - to allow a separate symmetric key encryption to be applied 
     (at the application layer) in order prevent the DRs/TN from
     reading the data.

We assume encryption for confidentiality (using the GroupDataKey) has 
been applied above the transport layer by the sender/source, in order to 
prevent a DR/TN from decrypting the data.  The GroupDataKey is only 
available to the group members, excluding the interior control nodes.

We propose the use of another key (GroupAuthKey) to provide group-
authentication from the source/sender at the network layer using 
symmetric key cryptography.  The GroupAuthKey is known by the members of 
the group, as well as the interior control nodes.

For the retransmission of lost packets to regions within a group, either 
via unicast or local multicast, we propose the use of a SubgroupAuthKey 
(instead of the GroupAuthKey) which is known only to entities within a 
region (DR and its children). The SubgroupAuthKey is also used by the 
entities in a region to group-authenticate control messages that are 
exchanged with each other. 

8. References

[HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key 
Management Protocol", work in progress, draft-ietf-ipsec-intragkm-
00.txt, Nov 1998.

[HH99a] H. Harney and E. Harder, "Group Security Association Key 
Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec-
00.txt, May 1999.

[KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino.  "Tree-based 
Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram-
02.txt, January 2000.

[KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet 
Protocol", IETF, RFC 1825, 1998.

[KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in 
progress, Internet Draft, July 1998.

[MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", 
work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998

[MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH", 
work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998.

[R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992.

[RSA93]  RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, 
No. 1993.

[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II 
Specification".  Work in progress, draft-whetten-rmtp-ii-00.txt, April 
8, 1998.