[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SPARTA, Inc.                                        Hugh Harney, Eric Harder
INTERNET-DRAFT                        SPARTA, Inc., National Security Agency
draft-harney-sparta-msmp-sec-00.txt                              March, 1999


   Multicast Security Management Protocol (MSMP) Requirements and Policy




                            Status of this memo


This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

This document is an Internet-Draft.  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 a http://www.ietf.org/shadow.html.

Document expiration:  August 30, 1999


                                  Abstract


     This Internet-Draft describes issues relating to the management of
    cryptographic keys in support of multicast communications.  It
    describes the functional and security requirements of an electronic
    key management system for multicast.



                              Copyright Notice

      Copyright Oc The Internet Society (1999).  All Rights Reserved.


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

Contents

1 INTRODUCTION                                                             3
  1.1 Desirable Features  . . . . . . . . . . . . . . . . . . . . . . . .  4
  1.2 Candidate Applications  . . . . . . . . . . . . . . . . . . . . . .  4
    1.2.1Teleconferencing . . . . . . . . . . . . . . . . . . . . . . . . 5
    1.2.2Broadcast (NNTP, NASA broadcast) . . . . . . . . . . . . . . . . 5
  1.3 Security for Multicast  . . . . . . . . . . . . . . . . . . . . . .  6
    1.3.1Securing Multicast Packets . . . . . . . . . . . . . . . . . . . 6
    1.3.2Managing Secure Groups . . . . . . . . . . . . . . . . . . . . .  7

2 REQUIREMENTS                                                             7
  2.1 Real World Requirements . . . . . . . . . . . . . . . . . . . . . . 8
    2.1.1Performance  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
    2.1.2Flexibility/Modularity . . . . . . . . . . . . . . . . . . . . .  9
    2.1.3Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  2.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 11
    2.2.1Algorithm Definition . . . . . . . . . . . . . . . . . . . . . . 11
    2.2.2Key Generation Definition  . . . . . . . . . . . . . . . . . . . 11
  2.3 Authorization Definition  . . . . . . . . . . . . . . . . . . . . . 12
    2.3.1Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 12
    2.3.2Key Dissemination Architectures  . . . . . . . . . . . . . . . . 13
    2.3.3Trust  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    2.3.4Authorization  . . . . . . . . . . . . . . . . . . . . . . . . . 15
    2.3.5Rekey Approach . . . . . . . . . . . . . . . . . . . . . . . . . 15
    2.3.6Compromise . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  2.4 Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 17
    2.4.1Self Defined . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    2.4.2Communications Protocol Independent  . . . . . . . . . . . . . . 18
    2.4.3Architecture Independent . . . . . . . . . . . . . . . . . . . . 19
3 POLICY COMPONENTS                                                      19
  3.1 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  3.2 Architecture  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
    3.2.1Operational Policy . . . . . . . . . . . . . . . . . . . . . . . 20
    3.2.2Key Dissemination Policy . . . . . . . . . . . . . . . . . . . . 20
    3.2.3Access Control Policy  . . . . . . . . . . . . . . . . . . . . . 21
    3.2.4Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    3.2.5Compromise Policy  . . . . . . . . . . . . . . . . . . . . . . . 21

4 DESIGN RECOMMENDATIONS                                                  22
  4.1 Global Policy Mechanism . . . . . . . . . . . . . . . . . . . . . . 22
  4.2 Limited Group of Security Mechanisms  . . . . . . . . . . . . . . . 22
  4.3 Policy Decomposition Of Multicast Protocols . . . . . . . . . . . . 23
5 Addresses of Authors                                                    26









Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 2]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

1 INTRODUCTION


Multicasting technology has been a promise for many years now.  A
blend between unicast (point to point) and broadcast (on sender, many,
unidentifiable receivers), multicasting allows a group of participants to
communicate efficiently between themselves using public networks.  Security
has been a key area holding back widespread adoption of multicast.

Group communications can be obtained using unicast methods (e.g., send
an e-mail to each participant), but this has an impact on the network
infrastructure, requiring sufficient resources to send each message from
the sender to each recipient uniquely (an e-mail to 100 addresses requires
the sender to actually send 100 messages).  Using multicast, information is
sent only once into the multicast infrastructure and the infrastructure only
creates new messages/packets when needed.  Depending upon the networking
technologies in use, multicast can be performed with a single message.

Multicasting, in general, provides the capability for information to
be disseminated to an identified group of participants efficiently.
Multicasting is typically performed by creating a group where participants
place information destined for all other participants.  This group can be in
the form of a newsgroup, IP address, or ATM address.

The security challenge for multicasting is in providing an effective
method of controlling access to the group (and it's information) that is as
efficient as the underlying multicast.  A primary method of limiting access
to information is through encryption and selective distribution of the keys
used to encrypt group information.  Control of the key distribution process
provides effective control of the group.  The controlling policy for key
distribution may differ among groups.  For instance, organizations may wish
to distribute keys to particular individuals or units based on location or
permissions; banks may wish to limit key distribution to particular trusted
individuals; or individuals may wish to limit distribution to particular
family members.  The range of options is limitless.

Establishing this cryptographic group on an internet is not a trivial task.
The entire group must converge on a single suite of security mechanisms
for data protection.  The single cryptographic key must be created and
distributed to all members of the group in a secure manner.  Some type
of access control policy must be enforced as part of the key distribution
mechanism.  These policies must be created and disseminated to the groups in
a manner that can be trusted.

The decision to create a cryptographic group on the internet is a based
on the data that is going to be passed across the network and the needs
of the communicating group.  If the data passed across the network is
extremely important and not time sensitive, the security policy for
creation, dissemination, and access control may be stringent.  Alternately,
if the data is not very sensitive, the security policies of the group
may be more relaxed.  This is an important distinction because there is


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 3]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

a trade-off between security (assurance that the policy is in effect) and
performance (time and resources necessary to implement the policy).  The job
of coordinating that trade-off falls to a management protocol.

This paper identifies and discusses the security and key management
requirements for cryptographic groups.  This includes group creation, group
key creation, key distribution, policy creation, policy distribution, access
control and group behaviors (management, rekey and compromise recovery).
The goal is to craft the specific requirements for a Multicast Security
Management Protocol (MSMP).



1.1 Desirable Features


The desirable features for a MSMP include:


 -  The security management protocol shall operate in a heterogeneous
    communications protocol environment

 -  The security management protocol shall provide and utilize all
    reasonable security mechanisms to provide high assurance to
    security-relevant management events.

 -  The security management protocol shall protect the group from all known
    security attacks pertaining to security management.


1.2 Candidate Applications


In looking to the internet, the Inter-Domain Routing Protocol (IDRP) and
the Distance Vector Multicast Routing Protocol (DVMRP) use multicast as
a mechanism for parties to relay common information to their peers.  Each
party both sends and receives information in the multicast channel.  As
appropriate, a party may choose to leave or join the communication without
the express permission of any of the other parties.  More interestingly, the
multicast internet protocol (IP) model has the receiver telling the network
to add it to the distribution for a particular multicast address, whether it
exists yet or not, and the sender is not consulted as to the addition of the
receiver.

Other applications of multicast communications in the internet (e.g., NASA
select broadcasts) can be viewed as implementing the sender model because
the sender selects the broadcast time, channel, and content, though not the
destinations.





Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 4]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

1.2.1 Teleconferencing


Video or audio teleconferencing is one model of multicast communications.
Widespread use of the video or audio teleconferencing applications will
result in many small groups existing at one time.  These groups will
be highly dynamic.  Individual users may have several applications, or
instances of applications, running simultaneously with different keys.
Individuals will gain access to groups based on their network address and
on personal characteristics (e.g., name, organization, physical location,
authorizations) that may be contained in cryptographic certificates.  There
may even be a secondary mechanism for finer grained access management
controlled locally.


1.2.2 Broadcast (NNTP, NASA broadcast)


Another scenario for group keys is a large single keyed group.  There
are some interesting environmental constraints on key management imposed
by the characteristics of extremely large groups (e.g., network news and
broadcast).  Network news transmissions represent the case of extremely
large groups where each recipient receives the same data package.  The
keying of a secure network news group is complicated by the unidirectional
characteristic of the communications.  The sheer size of network newsgroups
precludes any sort of standard reply from each recipient, as these
acknowledgments would easily consume all available network bandwidth for
popular groups.

cooperative enforcement of the group security policies would require that
all entities enforcing the access control policy were trusted to do so.
This requirement may seem difficult to manage.  Yet, the group with access
to the data decryption key are trusted to protect that data.  It seems
logical that those same members should be trusted, by default, to protect
the key that is protecting the data.  Essentially, the group members trusted
to protect the data being encrypted are available, and trusted, to enforce
the groups' access control policy.  The problem devolves to how do we use
those members to speed group establishment.

The security of the key is inversely proportional to the number of holders
of that key.  This observation leads to some potential alternatives
for controlling the keys protecting information in such a group.  One
alternative for large groups is to compose it of smaller groups connected by
``cryptographic gateways''.  (1)  In principle, if any single endpoint goes

------------------------------
 1. Cryptographic gateway refers to a device that is trusted to decrypt and
re-encrypt
traffic from one ``enclave'' to another.  Such a device may be a specialized
multicasting gateway, providing security translation service between a local
network and the multicast backbone.  Also, such a device may be


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 5]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

bad, the compromise is confined to that communication group.  In effect, the
compromised cryptographic key would have limited utility.  The geographical
location of that communication net bounds the utility of the key.  Systems
that require actual broadcast of secure packets (e.g.  satellite downfeeds
and some cable architectures) could not use the meshed large cryptographic
group.



1.3 Security for Multicast


The issue of secure multicast communications for multicast groups has two
parts.  The first part consists of the mechanisms used to secure the data
while it is in transit between the multicast group members.  The second part
is the management of the security groups.  Management in this case, refers
to:


 -  Creation and distribution of keys,

 -  Enforcement of access control policies, and

 -  Operational control (e.g., compromise recovery, rekey, identity
    infrastructure issues).


1.3.1 Securing Multicast Packets


When a group of entities share a cryptographic key, for encryption of data
traffic over a multicast address, they all share use of that key.  Multicast
communications allow any member of the group to encrypt a message and
have it decrypted by multiple destinations.  The sender ID is included
in an IP packet but any member of the group can create a packet with any
sender ID making it impossible to unambiguously distinguish the source
of the transmission based on the key used to decrypt the transmission.
This implies that a separate mechanism must authenticate the source for
transmission in a cryptographic group.

Several mechanisms exist that can authenticate individual sources of
transmission in a cryptographic group.  The most obvious and widely used
mechanism is the digital signature.  Digital signatures have the advantage
of being received by a wide audience and being created by a very narrow
audience.  They have the disadvantage of taking a long time (as compared
to encryption) either to sign or to verify.  Depending on the type of
communication going on, the time required to use a digital signature may

------------------------------
employed where there are issues of cryptographic releasability, allowing for
groups to be created, that use several cryptographic algorithms.


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 6]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

make it impractical.(2)  For communications that are not time sensitive,
it may be reasonable to apply a digital signature.  Network news maybe
appropriate for digital signatures.


1.3.2 Managing Secure Groups


The MSMP encompasses all the issues of a cryptographic group.  The
management of multicast secure groups is most likely an application layer
protocol.  Each group of members needs an instance of the management
application layer protocol.  Those protocol instances need to cooperate
to successfully enforce the group's policies and provide keys and group
management information.

There are many management issues associated with the securing of a multicast
group, including:


 -  Key generation procedures,

 -  Key distribution to all group members,

 -  Commonly understood group mechanisms, and

 -  Orchestrated group actions.


The next section outlines the details of the target requirements for such a
group management protocol.



2 REQUIREMENTS


A clear collection and definition of the multicast security and key
managment requirements will help in the definition of the MSMP. Many people
have an idea of how to solve multicast key management problems for specific
systems.  The requirements presented in this paper were collected from the
requirements for multicast key and security management from different types
of systems.  Several multicast security proposals were also reviewed to
include their stated requirements.[1, 2, 3, 4, 5, 8]

------------------------------
 2. The use of digital signatures for streaming applications may
be impractical on a ``packet-by-packet'' basis, though it may be possible to
perform a digital signature verification on a periodic basis over ``chunks''
of the previously transmitted stream.  Also, the use
of a running cryptographic checksum, initialized by an authenticated message
(signed precursor), may also serve this purpose.


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 7]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

2.1 Real World Requirements


There are two broad requirements of the real world:  efficiency and utility.
MSMP must present a useful functionality set for most applications.  It must
contain enough options to allow it to operate across heterogeneous systems
and configurations.  Unfortunately, the desire to provide a functional tool
set for the widest range of applications conflicts with other concerns,
namely efficient use of resources and performance.


2.1.1 Performance


 -  MSMP shall establish small groups in a few seconds.

 -  MSMP shall support large groups that never converge.

 -  MSMP shall support confirmation of group convergence (merge) in large
    groups, where required by group policy.

 -  The MSMP should be able to accommodate a variety of convergence states.



2.1.1.0.1 Resource Utilization


It is desirable to perform managment operations when they have the least
operational impact.  It may be useful to describe a performance curve
for multicast security management over the life span of a secure group.
The set-up phase of the group is where a majority of the management
functions should occur.  Interactions that would interrupt the group (rekey,
compromise recovery, leave, join) should be localized to members of the
group requiring the service.  These interactions should also be streamlined
to minimize the impact on the legitimate group members.

In the group communications of a multicast group, the security management
set-up takes place coincident with the group set-up.  During normal group
communication, the security managment of the group is merely a watchdog
effort ensuring the group is operating correctly.  During a re-key, leave,
or join, security management occurs, but it is minimal and localized, if
possible.  The group communications processing increases if there is a
compromise of a group member.  If compromise recovery is possible for a
group, the security management protocol will become active in keying the
compromised individual out of the group.  In most instances, a new group
is created that excludes the compromised entity.  The security managment
protocol would also support documentation of information for a forensic
review of the compromise.

In summary, the MSMP must:


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 8]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

 -  Front load processing requirements (set-up) and

 -  Provide audit mechanisms.


2.1.2 Flexibility/Modularity


MSMP must be flexible enough to apply to many different environments.
It must be modular to easily allow users to adapt the protocol to their
environment.  One mechanism to create an efficient and highly flexible
protocol is to provide a single architecture that supports multiple
specialized sub-protocols.  To some degree, it may make sense to make
protocol "objects" optimized for a particular need.

In summary, the MSMP must:


 -  Support multiple environments and

 -  Provide mechanisms for the expansion and optimization for special
    environments.


2.1.3 Scalability


Scalability refers to the protocols' ability to do two things -- support
groups with large numbers of users and support large numbers of individual
groups.  Unfortunately, these two architectures can be at odds with each
other.


2.1.3.1 Many Group Members


Some multicast groups have an extremely high number of sites.  Usually, most
group members are receive-only and very few are transmit.  There are some
interesting requirements associated with this type of group.  The security
protocol may need to operate "out of band" and each individual site will
need to correlate keys to the appropriate group address.

There are architectural issues with whether a group like this should even
share a single key.  Today's architecture relays a single message around
the globe.  This may not be desirable in the case of a secure group.  A key
shared by many people really will not protect much information.  Of course,
it is also true that if a key holder cannot be trusted to protect the key,
nor can they be trusted with the information protected by the key.

An alternative architecture to the single key per group is the large
group built up of smaller groups connected by cryptographic gateways.


Harney/Harder          draft-harney-sparta-msmp-sec-00.txt          [Page 9]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

                                 <Internet>
                                     |
                  ___________________|___________________
                  |                  |                  |
           <CryptoGateway>    <CryptoGateway>    <CryptoGateway>
                Key=1             Key=1/2            Key=2/3
             _____|_____        _____|_____        _____|_____
             |         |        |         |        |         |
          <Member>  <Member> <Member>  <Member> <Member>  <Member>
           Key=1     Key=1    Key=2     Key=2    Key=3     Key=3

      Figure 1:  Use of Cryptographic Gateways to Reduce Key Exposure


Figure 1 presents this type of large group.  These composite groups have
the advantage of limiting the utility of any single cryptographic key
and tighter control can be placed on access control by specifying local
trusted controllers.  The MSMP need do very little to support this type
of group.  Each local group is feasibly a normal cryptographic group.  The
cryptographic gateway can either be a local decision or it could be stated
in the policy.  See Figure 1

In summary, the MSMP must:


 -  Enforce communications policy defined by group and

 -  Link single key(s) to individual groups.


2.1.3.2 Large Numbers of Small Groups


Another scalability issue is that the protocol must support a large number
of groups each with a fairly small number of members.  It seems reasonable
to predict that the internet will probably have many IP video or audio
teleconferences occurring at any one time.

The scalabilty issues with this scenario deal with availability of
resources.  An approach that relies on a central server in establishing
groups would likely experience problems as the number of groups increases
and, given the dynamic nature of groups, the group's lifespan decreases.
That central server would become very busy and a potential single point of
failure.

In summary, the MSMP must Support small group proliferation without creating
communication or processing overloads.






Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 10]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

2.2 Security Requirements


There are security requirements inherently tied to a protocol that
manages keys [3,4,5].  The following sections attempt to identify all of
these possible requirements.  Protocols designed to service a particular
environment will have a tailored subset of requirements.  However, a generic
MSMP must be flexible enough to satisfy these broad requirements.

The use of cryptography to protect data shifts the burden of security to
the management of the cryptographic key.  In essence, control of the key is
equivalent to control of the data, and key management becomes the pivotal
point for cryptographic-based security.


2.2.1 Algorithm Definition


Due to the nature of groups, negotiation of cryptographic algorithms is
difficult, if not impossible.  MSMP must define a common algorithm policy.
This could be optimized to the environment.

Alternatively, the Internet Secure Association Key Management Protocol
(ISAKMP now IKE) could negotiate the algorithm suite.  If ISAKMP was able
to completely cover the domain of the potential user base of the MSMP, then
ISAKMP would be an adequate solution.  The problem arises when a user tries
to utilize MSMP without having benefit of a pre-negotiation by ISAKMP. MSMP
would have to either negotiate the algorithm suite itself or cause ISAKMP to
do so.

In summary, the MSMP should:


 -  Select cryptographic algorithms based on negotiated group policy, and

 -  Provide an interface for ISAKMP to establish the cryptographic
    environment.


2.2.2 Key Generation Definition


Two general mechanisms exist for the generation of cryptographic keys.  A
cooperative peer exchange [8] of key information can create a cryptographic
key.  Alternatively, a single entity can use a key generation technology to
generate a key by itself.

The choice of which mechanism to use is determined by the security
requirements of the group and the communication resources available to the
MSMP. For each environment, a policy decision will have to be made.  The
MSMP must support both mechanisms as directed by a policy decision.


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 11]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

In summary, the MSMP must enforce key generation policy.



2.3 Authorization Definition


The definition of authorization mechanisms, and infrastructure, must be
consistent across a MSMP domain.  Due to the potential use of authorization
tokens and certificates [ 9,10] for identity within the MSMP, the only
way to make correct access control decisions would be to have a common
authorization definition.  It may be possible to define a mapping
between authorization mechanisms to allow heterogeneous authorization
infrastructures to interact.  However, this mapping mechanism currently
falls outside the scope of this security protocol.

In summary, the MSMP must:


 -  Enforce authorization policy, and

 -  Support a common authorization definition, and/or

 -  Support a common mapping of definition between authorization
    infrastructures.


2.3.1 Access Control


Access control, as it relates to security and key management, denies the key
from entities without permission to hold the key.  Historically, asymmetric
key management protocols have implemented a policy of peer review.  Peers
cooperate to create the key.  They "know" each others' identity based upon
information passed.  This identity information was previously certified by
a trusted third party.  Each peer "knew" that it wanted (or was allowed) to
create a secure session with the other entity.

In the case of a multicast group, the peer-to-peer relationship for access
control is impossible to implement.  The number of messages required for
every member in a group to identify, verify and perform access control
for every other member group is prohibitive in terms of processing and
bandwidth.  Hence, the access control mechanisms must be different for
multicast groups.  In a multicast group, it is reasonable for the group
owner to define the access control policy.

To summarize, the MSMP must:


 -  Support configuration of the access control policy,

 -  Distribute the access control policy to group, and

Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 12]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

 -  Verify access control.


Since the MSMP has to control access to the key, it performs the access
control decisions.  These access control decisions lay the very foundation
for group security.  There are two different philosophies:  rules-based and
identity-based access control.


2.3.1.1 Identity-Based


Identity-based access control decisions lend themselves to groups where all
participants of the group are known in advance.  These decisions are very
clean and provide a high degree of assurance that only those group members
listed have access to the data.  This assumes, of course, that the mechanism
for identifying group members is a strong one.  Identity in this case can
mean individual identities as defined by individual's certificates or it can
refer to an IP address of a host machine.

Any identity-based access control policy requires that all access control
decision makers have of the list of approved identities.  The MSMP must
provide a mechanism to disseminate not only the policy, but also the actual
list of approved group members to all access control decision points.


2.3.1.2 Rule-Based


Rule-based access control [9,10] relies on some set of preestablished
parameters known about each potential member of the group.  A certificate
architecture infrastructure provides a framework to make rule-based access
control decisions.  The asymmetrical signed certificates, signed by a
trusted entity, provide information about each individual.

An issue with rule-based access control is that the rule enforcement must be
consistent across the entire group.  This is easily accomplished if a single
point is making all the access control decisions.  However, with multiple
access control decisions being made by multiple members of the group, the
MSMP must provide a mechanism to disseminate the access control rules and
access control policy.


2.3.2 Key Dissemination Architectures


Just as there are different levels of data, there are different levels of
security (trust in the access control) that apply to a group.  There is
a natural trade-off between how fast the group can be established and the
degree of assurance of the group.  These two factors tend to oppose each
other in secure group management.


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 13]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

In a small highly secure group, it may be desirable to have a single trusted
authority or a small subset of trusted authorities to control access to
the group key.  This architecture leads to a very tightly controlled group.
Such groups have a very difficult time scaling for a large group.

Access control requirements and control of the group, may be relaxed to
allow some or all group members to disseminate the key based on the passing
of some rudimentary access control rules.  This would result in an increase
in the speed of establishing an extremely large group.

In either instance, the host making access control decisions to the
cryptographic key needs to be trusted to make those decisions.  The
definition of trust is up to the owners of the data.  It could take the form
of formal computer security trust levels or it could be defined locally.

In summary, the MSMP must:


 -  Support configurable key dissemination architectures and protocols, and

 -  Conform to computer security trust requirements imposed by the
    architecture.


2.3.3 Trust


The mechanisms used to support and implement a MSMP must be ``trusted''
which means that the mechanisms are responsible for enforcing security and
the level of security enforced by the system is dependent on the flawless
execution of these resources.  If the MSMP must enforce trust policies,
it needs to be cognizant of the trust topology of its resources.  If a
sub-group of routers has the necessary trust mechanisms to protect keys, it
is a candidate for a key dissemination protocol.  However, this would impose
a trust topology on the multicast internet.  Use of these trusted routers
would need management.  The trust levels need monitoring (to verify the
trusted state is exists), and the list of trusted routers must be available
to all entities that desire to create groups.

To summarize, the MSMP must:


 -  Enforce policy concerning data protection and computer security trust
    level;

 -  Maintain verification of the trusted state of "trusted" entities, in
    accordance with data protection accreditation; and

 -  Maintain state information for its domain in order to know ``who'' to
    trust.



Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 14]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

2.3.4 Authorization


Multicast groups require authorization of all important security actions.
The multicast protocols must provide a mechanism where each group member can
verify the identity of the entity asking it to perform important actions and
check this identity against a pre-stored list of permissions.

In peer security protocols, the authorization mechanism is relatively
simple.  Each peer [6, 7] will make the decision to create a secure
session with another peer based upon the IP address or user ID of the
peer.  Since there is direct communication between peers during secure
association establishment, there is perfect knowledge of the identity of the
communication partner.

In the case of MSMP, there is a requirement for a different authorization
mechanism.  Group members, in many instances, accept a key as valid without
participating in the key's creation.  There is a degree of trust on the
part of the group member that the key is valid and does indeed belong to the
group claimed.

A MSMP could fail if it does not have a full set of authorization
mechanisms.  The SMKD protocol [8] is designed for core base trees
(CBT). The security protocol utilizes CBT routers to disseminate group
keys.  The CBT routers all undergo a mutual suspicious exchange verifying
identities and authorization to receive the key.  The group members strongly
authenticate themselves to the CBT routers when they request a group key.
However, the CBT routers do not strongly identify themselves to the group
members.  Nor do the new members have information from a trusted source
authorizing the router to distribute the group key.  In this protocol it
is conceivable that a CBT router could become a rogue router.  When the
group member makes a request to join a group, the rouge router could give
it a bogus key for that group and create an entire sub-group with this bogus
key.  It could trick members of the false group into communicating sensitive
information on the bad key.  In short, not having a robust authorization
mechanism and utilizing the mechanism, could lead to masquerade attacks.

In summary, the MSMP must enforce authorization policy concerning group
establishment, key dissemination, rekey and compromise recovery.


2.3.5 Rekey Approach


Traditionally, a cryptographic key was treated as if it had a shelf life.
More accurately, a cryptographic key is changed when too much data was
protected by that single key.  The most straightforward mechanism to achieve
this changeover is to cancel the old group and create new group in its place
containing all the old members.  However, the creation of a cryptographic
group, especially a large one, is an arduous task requiring a great deal of
access control decisions, messages, processing and processing resources.


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 15]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

This is a time consuming process.  In many cases, it is preferable to
minimize the disruption of the communication group by sending out a single
message that will change the group's key.  This process is called rekeying a
group.

When the rekey occurs, the single secure message containing the new group
key is created.  That message is transmitted to the group.  Included in
that message is some sort of cryptographic changeover time.  This time
is far enough into the future that most, if not all, of the group members
are sure to receive the rekey message prior to changeover time.  At that
cryptographic changeover time, all group members will switch to the new
cryptographic key for the group.

To allow for graceful transition between old and new group keys, there is
usually a short period of time when either key decrypts messages.  This
allows messages that were in transmission, encrypted under the old group
key, to be received at their destinations and decoded immediately after
the cryptographic changeover time.  However, all messages being sent after
crypto-changeover time use the new key for encryption.

Usually, only large groups securing critical communications use rekey.  The
MSMP should support the concept of rekey particularly for critical groups
that cannot withstand an interruption in service.


2.3.6 Compromise


For the purpose of this discussion:



 -  A compromise is the loss of trust in an entity with access to keys.
    This loss of trust (implies an assumption that the key has been
    exposed) invalidates the key.

 -  A compromise is not an administrative decision to remove or replace an
    entity with access to key.  A loss of trust in that entity is not
    assumed.  Administrative decisions do not necessarily imply that the
    key held by an entity is invalid.


The compromise of a secure group member is a more serious problem than the
discovery of a compromised member for pairwise secure communication.  In
the case of pairwise communication, the secure association is deleted and
no further action need take place.

If a group member is compromised, the compromised member needs deletion
from the group, but at the same time the other group members need to be
able to continue their communications without a disruption of service.
The seriousness associated with disruption of service and the urgency of
removing a compromised member is a trade-off.

Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 16]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

There are several issues dealing with the handling of a compromised group
member that could lead to many requirements on the MSMP. The general goal
of dealing with a compromised group member is to return the group to a
secure state.  This compromised entity is denied access to future group
information.  Normally, one creates a separate group that includes all
members of the original group minus the compromised member.

This imposes several management requirements on the security management
protocol.  The security management protocol must be able to either recognize
the compromise of a group member or accept a report that a group member is
compromised.

There are at least two separate means for dealing with compromises.  One
mechanism recently put forth [10] replaces the compromise recovery keys
within the group.  These keys split the group in such a manner that it
would be easy to send a single message to multiple group members to get
them on a new secure group transmission key.  This mechanism would reduce
the amount of time needed to reconstitute the secure group, after discovery
of a compromise.  However, this mechanism also requires management of these
compromised recovery keys and the storage of compromise recovery by all the
group members.  Such a compromise recovery mechanism would be extremely
valuable in the case of long-term static groups.  This is especially true
if the communications are critically important.

Another compromise recovery mechanism is simply to cancel the compromised
group and create a new group that is exactly equal to the old, minus
the compromised member.  This mechanism has simplicity on its side, but
certainly is slower and causes more disruption to the group communications.

In short, the MSMP must enforce compromise recovery policy as defined at
group establishment.



2.4 Protocol Requirements


The multicast security protocol has requirements levied upon it based more
in the good design of a protocol rather than focused on the security aspects
of the protocol.  The following sections attempt to catalog these design
goals.


2.4.1 Self Defined


The MSMP should provide a complete tool set for the management of keys and
security for cryptographic groups.  It should generate and contain all the
information the protocol needs to function.  The one possible exception
could be the certificate's infrastructure, if one is needed.  In the case of
the certificate infrastructure, a very good case exists for the utilization
of existing infrastructures rather than trying to reinvent it.  The MSMP

Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 17]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

must:


 -  Provide mechanisms to allow group-wide enforcement of group policy, and

 -  Support existing certificate infrastructures.


2.4.2 Communications Protocol Independent


The MSMP should be independent of the communication system it is being
transmitted over and any protocol that it might be servicing.  A majority of
the work done in this area has been under the auspices of the IPSEC Working
Group.  However, the MSMP not only services IP layer security, but will also
serve session and application layer security.  The MSMP will also reside on
hosts serviced by heterogeneous communication protocols.  As an application
protocol itself, MSMP should be completely divorced from the nature of the
communication.

The MSMP should not target a specific communication protocol.  However,
that does not mean that an option under the MSMP cannot target a specific
communication environment.  For example, the general protocol could offer
an option for those systems that operate solely over ATM or CBT networks.
These homogeneous networks offer distinct advantages for a security
management protocol.  A security management protocol could utilize a trusted
backbone of routers [8] to either set groups up more quickly or to ease the
recovery from a compromise.  The MSMP should offer mechanisms that allow
customized protocols.

It is also important to realize that different cryptographic groups,
depending on their utilization, have different requirements and natures.
For instance, a large IP network may have the luxury to limit the number of
endpoints with identical keys, thereby limiting the scope of a compromise.
In other systems (e.g.  cable system or especially those utilizing satellite
downfeeds), there is no capability to limit the scope of compromised keys by
limiting the size of key groups.  The MSMP must:


 -  Remain independent of any specific communication protocol or
    infrastructure;

 -  Support operation as a source to destination protocol; and

 -  Support homogeneous systems with optimized solutions.








Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 18]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

2.4.3 Architecture Independent


The MSMP should provide multicast security management regardless of the
environment it is serving.  This protocol should satisfy at least 95 percent
of the security architectures that require secure keys.

For example, the MSMP should be able to support networks that push a group
key onto the end points and where the end points pull the group.  A large
group could be built up of multiple cooperatives or it could simply be a
large commonly held group of symmetrical keys.  Again, the MSMP should be
able to satisfy both cases.  The MSMP should be configurable to support
extremely high security groups, even though they incur a degradation in
terms of speed.  Conversely, it should be configurable to support groups
that trade high security for speed and ease of group establishment.

Obviously, a single scheme for creating secure groups and distributing
keys to those end points will not be adequate to satisfy all the different
architectures and environments the MSMP will be supporting.  A single,
universally accepted, protocol construct is required that allows access to
sub-protocols optimized for different environments.



3 POLICY COMPONENTS


Security mechanisms and security protocols all enforce some policy or
policies within their domain.  A clear definition of the enforced policies
is critical to the successful design and implementation of a security
protocol.  The following section attempts to define policies that are being
enforced by the MSMP.


3.1 Security Policy


Security policy is a statement of the rules enforced by security mechanisms.
There are multiple rules the MSMP will be able to enforce.  In a dynamic
system, groups define these policies based on the data that particular group
will protect.

The security policy can be static, and therefore assumed, or it can be
dynamic and tailored to the requirements of the group.  A dynamic security
policy would allow the group owner to identify one or several key locations
as well as authorizing new group members as needed.  If MSMP has a dynamic
security policy, a mechanism must define and disseminate this policy across
the group.  The MSMP must understand the policy and verify the authorization
of that policy.

A group security policy will make statements about the key the group will


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 19]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

share.  For example, it is reasonable to see a policy that identifies a key
for financial data.  The MSMP must implement this policy across the group
uniformly.



3.2 Architecture


The more interesting policies MSMP will enforce involve the structure of
the group itself.  The MSMP will enforce policy roles, key distribution
behaviors, access control, rekey, and compromise recovery.


3.2.1 Operational Policy


All of the proposed multicast security protocols [1, 2, 8] assumed a
structure of the key management protocol itself.  A single entity creates
the key and makes it available for dissemination to group members.  The
various proposals disagree about key dissemination, if routers are used to
make access control decisions, and how access control decisions are decided.

There is no reason that the MSMP need operate the exact same way as it
creates keys for different groups in different environments.  A mechanism
that conveys to the MSMP the operational policies will facilitate a more
dynamic protocol.


3.2.2 Key Dissemination Policy


Another group policy is key dissemination.  A single entity may create
the keys, but the key can be disseminated to the group members in several
manners.  One key dissemination policy could be that a single trusted entity
performs all key dissemination and associated access control decisions.
This single point to dissemination policy is not performance oriented and
may not be acceptable for larger groups.  Another policy is to delegate
responsibility for key dissemination to a subset of routers.  This policy
assumes trusted routers.  The trusted routers must protect the key and make
access control decisions in accordance with the sensitivity of the data
been protected.  Yet another policy, is that any group member disseminates
the group key to any potential group member that meets a certain set of
criteria.

The particular policy for key dissemination is highly dependent on
the sensitivity of the data to be protected.  Depending on the data
being protected, the same application could have a very different trust
requirement placed on the dissemination of key.  The MSMP could change its
dissemination mechanisms or indeed its utilization of sub-protocols based on
a policy statement about key dissemination and trust requirements.


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 20]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

3.2.3 Access Control Policy


Perhaps the most critical policy definition of the group is that of access
control.  The access control policy defines the user or host that have
access to the cryptographic key.  This policy can be identity- or rule-based
or a mixture of both.  In any case, the access control policy must be
unambiguously stated so that only authorized group members receive the key.

There are several ways to define access control policy.  It can be based
on a human identity, IP address, permission parameters, job title, or
company name.  The requirement is that the parameter be unambiguous and
verifiable.  The most common mechanism is a certificate.  The information
in a certificate supports an access control decision because a trusted third
party verifies the accuracy of that information.

The MSMP could operate between multiple certificate infrastructures
providing there is a policy that clearly stated the acceptable certificate
parameters in each infrastructure.  In short, the access control policy
states who should have access to the keys and the mechanisms used to prove
that.


3.2.4 Rekey Policy


As described in earlier sections, a rekey is a useful action when a
cryptographic key is of long duration or is protecting a great amount of
data.  The decision to rekey is appropriate for any particular group and the
mechanism that rekey will utilize is the rekey policy.

Rekey involves the creation of the new group key and the creation of a
globally acceptable message to disseminate that key to all the current group
members.  A single group entity needs to coordinate this process.  After all
there can only be one valid group key at a time.  The rekey policy would
need to state clearly the individual authorized to perform the rekey, the
time of the rekey, and the time allotted for graceful key changeover.


3.2.5 Compromise Policy


Compromise recovery policy involves several decisions.  There is the
decision whether to pre-place a compromise recovery key hierarchy or to
delete and rebuild the group.  Another decision, is who has the authority
to declare the group compromised and how was that decision communicated to
the group.

Perhaps the most difficult part about compromise recovery is discovering
the compromise.  The rules for discovering a compromise and reporting it are
beyond the scope of this security protocol.  However, the MSMP will need to


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 21]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

have the capability to accept notification that the group is compromised.
How that notification is communicated or utilized by the MSMP is a policy
decision.  Compromise recovery key structures can be pre-placed in a secure
group along with the normal group encryption keys.  However, the MSMP must
define the nature of the key structures' needs and pass it to the group at
the time of group establishment.



4 DESIGN RECOMMENDATIONS


The analysis and review of the MSMP requirements and policies have resulted
in two recommendations regarding the direction of the multicast security
effort.  The first recommendation is to create a globally acceptable policy
mechanism that is accepted across the environments and would completely
define the cryptographic group.  The second recommendation deals with the
design and implementation of the MSMP.


4.1 Global Policy Mechanism


One thing that became clear during the analysis of multicast group
requirements is that there are many policy decisions involved with
group establishment.  The multicast environment, unlike the pairwise
environment where a peer-to-peer negotiation is uncomplicated, requires
more coordination between the group members.  Certainly, a single group
member can make the cryptographic key.  There are multiple ways the MSMP
could disseminate cryptographic key to the group.  There is the issue of
whether or not the group needs a rekey and, if it does, how to orchestrate
the rekey.  There is the whole issue of compromise recovery orchestration.
Many of these decisions are highly dependent upon the sensitivity of the
data, the duration of the group, and the criticality of the communication.

There is a strong argument for each of these options.  The MSMP should be
capable of being configured to satisfy most environmental requirements.
Because the entire group needs a common policy and group definition, it
makes sense for a single mechanism to provide this information.  It would
be best if this policy definition mechanism performed all MSMP configuration
actions.  Hence, one recommended goal for the MSMP is that a single
mechanism is defined that will inform the MSMP of the group policy.


4.2 Limited Group of Security Mechanisms


The following recommendation deals with the protocol design and
implementation.  A small subset of security protocols should be designed and
optimized for specific practical environments.  These specialized protocols
come from a generally accepted group specification message.


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 22]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

This recommendation suggests a highly modularized MSMP with a small, fully
optimized, sub-protocol.  There are benefits to doing this, including having
a universally accepted definition of multicast groups.  The end points could
then either participate in a group (providing possession of the optimized
sub-protocol), go get the appropriate sub-protocol, or not join the group.
End systems could load those modules that are relevant to them and ignore
all the others.  This leads to a protocol structure that works efficiently
for specific environments, provides universal protocol recognition, and
allows conservation of user resources.

From the point of view of developing an international standard, the
modularized approach leads to a highly useful and efficient standard and
protocol.  A high degree of interoperability exists due to the universally
accepted group definition.  Each environment could have a the MSMP targeted
for that environment.  Homogeneous environments could use CBT routers or
intermediate routers to distribute to key.  Heterogeneous environments
could have the end systems generate group keys without the knowledge
of the routers.  Extremely large unicast networks could utilize unique
communication infrastructures like group set-up servers.  Extremely high
security systems could include a compromise recovery key structure.



4.3 Policy Decomposition Of Multicast Protocols


The following table illustrates how some multicast protocols would decompose
into the policy components previously identified.  Each protocol makes
different assumptions of it's environment and those assumptions lead to
different policies.  Yet, these policies can be represented using the same
decomposition format.

GKMP

Operational - Certificate Infrastructure ID, Group Controller IP address:
a.b.c, Group 1st member IP address:  a.b.c.d, Group Owner Common Name:  X,

Dissemination - Group Controller only (push or pull) or any member

Access Control - Mutual suspicious, IP address list or Rules:  IP a.b.*,
Common Name:  *.acme.com

Rekey - Token required, uses GKEK sent during group establishment

Compromise Recovery - Destroy group, create new, with certificate revocation
capability during establishment

SMKD

Operational - CBT routers relays key, routers undergo rigorous
authentication


Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 23]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

Dissemination - Download from responding CBT router

Access Control - Host sends signature to router

Rekey - NA

Compromise Recovery - Destroy group, create new














































Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 24]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

The following documents were used in the preparation of this document:



References


 [1] [RFC 2093] Harney H., Muckenhirn C., and Rivers T., Group Key,
     Management Protocol Specification, RFC 2093, Experimental, July 1997.

 [2] [RFC 2094] Harney H., Muckenhirn C., and Rivers T., Group Key
     Management Protocol Architecture, RFC 2094, Experimental, July 1997.

 [3] [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J.,
     Internet Security Association and Key Management Protocol (ISAKMP),
     RFC 2408, Proposed Standard, November 1998.

 [4] [RFC 2412] Orman H. K., The OAKLEY Key Determination Protocol, RFC
     2412, Informational, November 1998.

 [5] [RFC 2409] Harkins D., and Carrel D., The Internet Key Exchange (IKE),
     RFC 2409, Proposed Standard, November 1998.

 [6] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure
     Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating
     Families, SDN.301.1, Rev. 1.2, 1988-07-12.

 [7] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure
     Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5,
     1989-05-15.

 [8] [RFC 1949] Ballardie, A., Scalable Multicast Key Distribution, RFC
     1949, Experimental, May 1996.

 [9] [RFC 2459] Housley R., Ford W., Polk T., and Solo D., Internet X.509
     Public Key Infrastructure Certificate and CRL Profile, RFC 2450,
     Proposed Standard, January 1999.

[10] Wallner, D., Harder E., and Agee R., Key Management for Multicast:
     Issues and Architectures, Internet Draft, Informational, September
     1998.












Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 25]


INTERNET-DRAFT            MSMP Requirements and Policy           March, 1999

5 Addresses of Authors

Hugh Harney (point-of-contact)
SPARTA, Inc.
Secure Systems Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United States
telephone:        +1 410 381 9400 (ext.  203)
electronic mail:  hh@columbia.sparta.com




Eric J. Harder
R231 National Security Agency
9800 Savage Road
Suite 6534
Fort Meade, MD 20755
United States
telephone:        +1 301 688 0847
electronic mail:  ejh@tycho.ncsc.mil


Document expiration:  August 30, 1999




























Harney/Harder         draft-harney-sparta-msmp-sec-00.txt          [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/