One document matched: draft-ietf-rmt-pi-track-security-00.txt

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




                 Security Requirements For TRACK

            <draft-ietf-rmt-pi-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 the TRee-based 
ACKnowledgement (TRACK) reliable multicast protocol instantiation, and 
identifies some constraints and requirements for security provisions for 
this protocol.  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 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, because of the requirement that the interior control nodes only 
OPTIONALLY have access to the data packet payload.

Specifically, the current work RECOMMENDS 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, because of its use of interior control 
nodes (Repair Heads, or RHs) 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. Conventions Used in this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
this document are to be interpreted as described in RFC-2119 [ ].


3. 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.


4. TRACK Overview

TRACK arranges Receivers (R) into local regions, where each region is 
assigned to a Repair Head (RH).  These groups are arranged 
hierarchically as a tree rooted at a Sender (SD), with the RHs 
representing the nodes of the tree, and the Receivers as the leaves.  
The Receivers send periodic control messages (called ACKs or NACKs) to 
their parent RH, selectively acknowledging the packets they have 
received, and requesting the ones they have missed.  Retransmission is 
then performed by the parent RH.  Each RH sends their control messages 
to the RH at the next level up the hierarchy.  This process is repeated 
until the messages reach the sender, informing it of the status of the 
group, and notifying it when it is allowed to advance its transmission 
window.  The RHs aggregate the selective positive acknowledgements from 
the receivers, and suppress the redundant negative acknowledgements, in 
order to solve the ACK/NACK implosion problem.

A RH maintains a local multicast group to just its children, and 
subscribes to the local multicast group of its parent.  A RH uses this 
local multicast group for retransmissions to its children, which also 
provides suppression of other negative retransmission requests for that 
packet at other children. 
 
TRACK 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 
TRACK region MUST join the multicast group (i.e. the data channel).  The 
RH of that region MUST join every multicast group that its descendants 
have joined.  Note that the RHs 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 a TRACK tree with multiple control nodes.

                       -------> SD (Sender node)----->|
                      ^^^                             |
        TRACKs      /  |  \    Control                |
         and      /    |    \    Tree                 |
        NACKs   /      |      \                       |
              /        |        \     (Repair         |
            /          |          \    Head           |
          /            |            \  nodes)         v
        RH             RH            RH  <------------|
        ^^            ^^^            ^^               | Data    
       / |           / | \           | \              | Channel
      /  |          /  |  \          |  \             |
     /   |         /   |   \         |   \            v
    R    R        R    R    R        R    R  <---------
               (Receiver Nodes)



5. TRACK Protocol Security Issues and Requirements

This section details the security requirements for TRACK.  These 
requirements include general multicast transport requirements, as well 
as some requirements specific to TRACK.

5.1 Background

In addressing the security issues specific to TRACK, 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.


5.2 Authentication of Control Messages

As stated above, the directly relevant security concern for TRACK 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 RHs and the Sender within a given TRACK hierarchy.  The key is 
independent of any data stream, and is used to authenticate control 
packets exchanged among the RHs/Senders.  


5.3 Non-Decipherability of Data Packets by RHs

TRACK requires that a Repair Head Node (RH) join all of the multicast 
groups that its descendants have joined.  For TRACK 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 has a further requirement, namely that the RHs be 
OPTIONALLY prevented from reading the multicast data.  More 
specifically, we perceive that RHs 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 SHOULD 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 RHs and the need for fast 
authentication, we propose:

- Data stream confidentiality, using either a symmetric or asymmetric 
key, SHOULD be separated from data authentication, using a symmetric 
key (i.e. explicit group-authentication).

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

- Since the RHs MAY be prevented from reading the multicast data, two 
(2) different keys SHOULD be deployed corresponding to the needs of 
data stream confidentiality and data group-authentication.


5.4 Authentication of Data Retransmissions

In TRACK, retransmissions of data packets always come from a child's 
parent, which may be either the original source or a RH 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 RH can simply replay the data 
(i.e. payload) unmodified to the querying receivers via local 
multicast.

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

Since the retransmission is via multicast to a subgroup, then the 
RH can either use the existing group-shared symmetric key or use a 
separate symmetric key only for the subgroup of its children.  We 
propose the later approach be OPTIONALLY supported, which means 
that a RH and its children (Receivers and in some cases other 
Repair Heads) could have to share a separate symmetric key for 
explicit group authentication at the IP layer.


5.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 
RHs 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, we propose, where feasible, 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 (RHs), the Sender and the Receivers.


5.6 Authenticity of NACK and other Control Packets

In TRACK, a RH 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 RH, causing a local multicast to all children 
of the RH.  In itself this is a waste of bandwidth and may result in a 
denial of resource to the group members.  Other control packets such as 
group membership requests, could directly impact the state of the group, 
and could also be used in denial of service attacks.

To counter these types of attack, the control messages themselves SHOULD 
be authenticated by the RH.  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 RH.

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


5.7 Fault Recovery

If a child's connection to a RH or Sender fails, TRACK provides 
automatic mechanisms for failing-over to another RH or to the Sender.  
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 RH or Sender, 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.

TRACK entities are expected to usually have the addresses of one or more 
backup nodes.  When implementing security features, each child SHOULD 
keep the key for its primary backup parent.  Optionally, it MAY need to 
keep the keys for each of the backup parents it is using.


5.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 for the near 
future are expected to operate in the application level of the OS, 
running on top of UDP. 
- Kernel.  As TRACK becomes 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 SHOULD 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.  TRACK SHOULD be able 
to OPTIONALLY 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 SHOULD be able to use a kernel 
level security system (such as IPsec) for its transport level 
security needs.


5.9 Separate Regional Protection

TRACK is 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 have proposed, a TRACK protocol MAY provide separate regional keys 
for the group-authentication of control packets sent from the receivers 
of different RHs.  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 a 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. 


5.10 Piracy of Pay-Per-Use Data

A common scenario for TRACK 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 that 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.



6. Architecture Recommendations

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


6.1 Separation of Security Responsibilities

As detailed above, TRACK is primarily concerned with protection of the 
network infrastructure, rather than with issues such as data 
confidentiality and source-authentication.  Therefore, we RECOMMEND that 
TRACK SHOULD provide:
   (a) group authentication of control packets, and
   (b) OPTIONAL group authentication of data packets
TRACK MAY choose to provide:
   (c) OPTIONAL privacy of data and of control packet headers.  
To accomplish this, we RECOMMEND that, where feasible, TRACK 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 that in some deployments, its control entities 
(RHs) be unable to decipher the data packet.  Thus, the GroupDataKey 
for data encryption and GroupAuthKey for group-authentication SHOULD 
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 SHOULD 
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.


6.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)
------------------------------------
- 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 data and control headers 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 
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 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


For example, 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 Repair Head Node (RH) 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 RH 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 RH will be 
authenticated using a SubgroupAuthKey (see below) which is a symmetric 
key shared by a RH 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.


6.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 RHs, 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 application 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 RH and its 
children (consisting of one or more Receivers, and possibly one 
child RH). 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 via local 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 RH happens to be a child within a region and at the 
same time a parent within its own region, then that RH will hold two 
distinct SubgroupAuthKeys corresponding to the two regions.

 -  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 RHs.  Should a child-RH request a 
retransmission of a lost data packet from its parent-RH, then the 
parent-RH will deliver the (encrypted) lost packet to the child-RH, 
authenticated using the InteriorNodeKey.

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


7. 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 RH, and the receivers served by that RH.

(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.

(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].


8. Summary

In summary, in the current work we have proposed for TRACK 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 SHOULD be conducted at the 
application layer, while data authentication using a symmetric key 
SHOULD be conducted at the network layer.  Since the RHs MAY be 
prevented from reading the multicast data, two (2) different symmetric 
keys SHOULD 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.  The use of group-authentication at the network layer 
is:
   - for protection of the transport and IP headers.
   - to allow a RH 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 RHs 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 RH 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 (RH 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. 


9. 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.

   Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997