INTERNET DRAFT O. Paridaens
<draft-paridaens-xcast-sec-framework-02.txt> D. Ooms
B. Sales
Alcatel
June, 2002
Expires December, 2002
Security Framework for Explicit Multicast
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 describes the general issues related to securing
explicit multicast traffic. Explicit multicast is a mechanism aiming
at providing multicast services for small groups of users. The
distinctive characteristics of explicit multicast is that the sender
specifies the list of receivers. This document reviews and discusses
security issues related to the explicit IP multicast model, hence
providing a general framework for securing explicit multicast IP
traffic as described in [1].
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 [2].
1 Introduction
Paridaens, et al Expires December 2002 [Page 1]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
Explicit multicast [1] is a mechanism providing multicast services
for small groups of users. One major particularity of explicit
multicast is that the sender normally explicitly specifies the list
of recipients (how this is exactly achieved is further specified in
[1]). Such a multicast model is already used for electronic
messaging but the idea here is to apply it at the IP level.
As it is well-known, "traditional" multicast brings complex issues in
terms of applying security services to such traffic. This has been a
subject of research for several years and is now being more
specifically studied within the IETF msec and IRTF gsec groups.
Explicit multicast distinguishes from traditional multicast at least
in terms of scalability issues and membership control. Indeed, an
explicit multicast session is made of few members, which
significantly reduces scalability issues being dealt with in msec and
gsec. Also, the receivers are known by the sender(s), which plays a
role in membership management issues (e.g. access control,
anonymity).
Explicit multicast brings specificities compared to traditional
multicast, specificities which have consequences on security aspects.
Based on the work being done in gsec, this document discusses those
security matters related to explicit IP multicast, hence providing a
general framework for securing explicit multicast IP traffic.
The first section reviews security services usually considered in
multicast environments. For each such service, we determine whether
the solution(s) being developed for traditional multicast solely
apply, or whether simpler or better solution(s) can apply, taking
benefit of the explicit multicast specificities. The following
section covers aspects linked to the existing IPsec technology [2].
It reviews issues in the use of IPsec for multicast traffic and
discusses possible scenarios that might be applied for securing
explicit IP multicast traffic [1] with IPsec AH and/or ESP. The last
section is devoted to the important problem of Security Association
(SA) and key management, identifying issues and suggesting possible
solutions in a generic way.
2 Security Services
This section discusses basic security services that can be required
in the context of explicit IP multicast. Problems may seem similar
to those arising in "traditional" multicast environments but the
explicit aspect leads to specificities which we have considered
throughout this document.
For each identified security aspect, we discuss whether solutions
Paridaens, et al Expires December 2002 [Page 2]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
being developed for traditional multicast apply or whether simpler,
better solutions can apply by taking benefit of the explicit
multicast model characteristics. Because the explicit multicast
model being considered applies at the IP level, our discussions focus
on security aspects at the IP level.
2.1 Membership Management
This section covers the various aspects linked to the group
membership that influence or are directly related to the provision of
security services in an explicit multicast environment, main
characteristic of which is that the list of recipient IP addresses
explicitly appears in the IP datagram.
2.1.1 Access Control
2.1.1.1 Membership Control
Controlling the membership of the session is obviously a (possible)
security requirement. Such a control can be achieved merely to
identify who is part of the session without applying any restriction
or to control access to the session (hence applying yes/no decisions
on join requests). Control can also be achieved thanks to "invite"
requests whereby receivers are invited to join the multicast session.
The entity responsible for controlling the membership is termed the
group controller (GC). As further discussed in section 4, in
traditional multicast, the work of the GC is not so obvious. Current
proposed multicast routing schemes do not enable a central GC to
always know which IP entities are joining the multicast group (as the
entity's IP address is lost on the way). In any case, a scalable
solution for traditional multicast will probably require the use of a
distributed GC model.
With explicit multicast, control of the group membership is
eventually under the sole authority of the sender since it specifies
the list of destination IP addresses.
If there is a single sender, it can easily act as the GC. In a
"join" model, a membership management protocol (possibly located
within the application itself) could be used to enable members to
join and leave the group by sending requests to the GC (ie. the
sender). In an "invite" model, the GC (ie. the sender) issues
invitations to receivers, thereby controlling membership.
If there are multiple senders, the solution becomes more complex
since membership updates must be distributed amongst all senders. A
typical solution would be to use a central GC (either one of the
senders or a third-party entity) tasked with managing the group.
Paridaens, et al Expires December 2002 [Page 3]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
Membership updates could then be reported to all senders thanks to
some management protocol (a simple unicast protocol can be designed
to achieve this given the small number of senders and that each
sender is known).
2.1.1.2 Senders Control
Access control also covers "who is allowed to send traffic to the
group". Because we focus on IP multicast, access control is
discussed here in terms of IP entities, not end-users. Several
strategies can be envisaged to control the sending entities.
In traditional multicast, it does not seem easy to control senders in
an efficient way (ie. detect and drop IP traffic from unauthorized
senders as soon as possible). In multicast routing schemes where the
IP traffic passes through a root entity, this can be used as a
filtering point. Even with such schemes however, it is still usually
possible to bypass the root entity (for routing efficiency reasons).
Senders control policy should then be distributed to routers located
upfront multicast members. Those routers could then be tasked with
the job of filtering on senders to the group (ie. IP datagrams from
unauthorized senders are discarded). This would however require that
those routers keep track of such policies attached to multicast
groups they are aware of. Such filtering could anyway be achieved by
members themselves, which has the obvious disadvantage of potentially
wasting bandwidth on the network infrastructure but members can set
up individual policies on whom they want to receive from (in addition
to the group policy itself which may have been received when joining
the group).
In explicit multicast , there is normally no central point through
which the IP traffic passes. In addition, because the purpose itself
of explicit multicast is to avoid keeping state in routers, routers
cannot be tasked with the job of filtering on senders to the group
(i.e. IP datagrams from unauthorized senders are discarded when
detected). This would indeed require that (at least some) routers
keep track of explicit multicast sessions and their authorized
senders. Receivers will therefore have to filter by themselves
(although some basic policy can be distributed to members by the GC).
In any case, filtering on senders requires that the sender be
correctly authenticated. Otherwise, valid senders could easily be
spoofed. Some individual authentication must therefore be provided
as further discussed in section 2.2.4.
2.1.2 Anonymity
In certain environments, members' anonymity can be a requirement.
Paridaens, et al Expires December 2002 [Page 4]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
Because we talk about IP multicast issues, we focus here on anonymity
at the IP level, hence in terms of IP addresses.
Group membership anonymity can be provided in various flavors.
A first type of anonymity can be required amongst members : no member
is aware of the other members.
Within traditional multicast , this can somewhat be achieved because
member IP addresses are "hidden" behind the multicast group address
and the IP addresses of the entities joining the routing tree are not
widely distributed. A sender's anonymity is obviously less obvious
to keep since it is the source of datagrams. An entity located
"near" a member can determine its membership by looking at its "join"
or "invite" operations but this is still rather limited.
In explicit multicast this is clearly not possible for the sender(s).
By the very nature of explicit multicast, each sender is aware of the
group membership. Regarding pure receivers, anonymity amongst them
can only be achieved if other receiver IP addresses are removed
before the IP datagram is relayed to the final destination. The
receiver still knows the sender and some routers "on the path" can
determine (at least partially) the list of other recipients.
Anonymity towards the external world (i.e. non-members) can also be
required.
Within traditional multicast, this can somewhat be achieved for the
same reasons as given above.
In explicit multicast, this seems difficult to achieve. Third-party
entities located on the IP traffic paths can determine at least
partially the receivers (as long as their IP addresses remain in the
IP datagrams). Membership, join, leave and invite operations can
also be seen by third-parties located on such traffic paths between
the GC and the members. The use of unicast IPsec/IKE tunnel
connections between the GC and the members can provide some level of
confidentiality and hence anonymity at that level.
2.1.3 Group Dynamics
The dynamics of the group membership can have an important impact on
the security mechanisms put in place. The fact that members can
dynamically join and leave the group has consequences on the scheme
used to provide data privacy for example, as discussed in section
2.2.6 below. The rate at which members join and/or leave is also an
important factor in the design of a solution.
Paridaens, et al Expires December 2002 [Page 5]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
The policy regarding the access control to the multicast data
exchanged on the group is a factor that can be combined with the
group dynamics. This will lead to different strategies as to how
keying material is distributed to members and how often this is done.
The policy may indeed require that a new member not be able to read
previously exchanged data. It may also require that a member leaving
(forcibly or not) the group not be able to read future traffic. In
both cases, new keying material must be distributed to members so
that new traffic is protected (i.e. encrypted) using this new keying
material.
Clearly, a static group in which members have been predefined or have
pre-joined the group (in the sense that they know in advance all the
keying material necessary in order to receive and send traffic) is
much simpler to manage from a security point of view.
In traditional multicast, this is a very complex problem to solve
efficiently in a scalable way. In explicit multicast, it is possible
to design simple solutions as the complex scalability issue vanishes.
Section 4 discusses in more detail the group dynamics aspects since
these heavily influence key management strategies.
2.1.4 Group Density
The distribution and size of the membership over the network greatly
influence any solution that can be developed to provide security
services, especially with regards to key management schemes. The
problem becomes more complex as the group is widely dispersed and
made of many members, since the solution must scale. This is
therefore a major problem for traditional multicast. The
characteristics of explicit multicast (in terms of size at least)
greatly reduce the problem of designing a key management scheme for
explicit multicast traffic.
2.1.5 Non-repudiation
Membership management policy might require that join, leave or invite
operations cannot be later on denied by a member or the GC (whether a
central controller or the sender itself). The basis for such a non-
repudiation service is the use of digital signatures with timestamps
on join/leave/invite operations.
Such a security service is not linked to the multicast scheme itself
(whether traditional or explicit).
2.1.6 Membership Verification
Paridaens, et al Expires December 2002 [Page 6]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
An additional service may be provided to members to enable these to
query and obtain the membership of the multicast group.
In traditional multicast, this can become practically unfeasible as
the group size increases, spreads and the exact detailed membership
is no longer known by any single entity.
In explicit multicast, such a service can be automatically provided
if the list of receivers is left untouched in each IP datagram
delivered to final destinations. If this is not the case, it would
still be easy to design a simple solution whereby the GC is queried
about membership.
2.2 Data Handling
This section deals with security aspects linked to the explicit
multicast traffic itself, between sender(s) and receiver(s) in the
group.
2.2.1 Anti-replay
Depending on the type of application data carried within multicast IP
datagrams, a third-party may try and replay old IP traffic (hence
mounting a replay attack). Anti-replay would normally be achieved by
sequentially numbering every IP datagram (such as in IPsec) and
protecting this sequence number with some data integrity mechanism
(see 2.2.2 below).
Section 3.1.2 below discusses issues with the use of IPsec to provide
anti-replay. It also suggests solutions applicable to explicit
multicast scenarios.
2.2.2 Data Integrity
Data integrity is normally combined with authentication and is
therefore discussed in the context of group and individual
authentication in the following sections.
2.2.3 Group Authentication
Group authentication means that receivers can ensure that the traffic
comes from another group member, without necessarily being able to
determine exactly which one (a mere check of the source IP address is
not sufficient since this can be spoofed). One possible solution is
to have a secret key shared between all members and the sender(s)
that can be used to compute a MAC (Message Authentication Code) for
each packet sent by the sender(s). Aspects linked to the
distribution of such keying material are discussed in section 4.
Paridaens, et al Expires December 2002 [Page 7]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
IPsec can be used as is to provide group authentication in
traditional or explicit multicast models (apart from the problem of
keying material distribution as discussed in section 4).
Group authentication could be achieved via confidentiality since the
ability to correctly decrypt received data indirectly shows that it
was encrypted by an entity knowing the correct encryption key, hence
a group member. This is however only possible if the data format is
such that individual encrypted blocks cannot be successfully replaced
by an attacker so that decrypted data looks correct. In such
situations, separate authentication/integrity would still be required
(and this is the recommended strategy).
2.2.4 Individual Authentication
Individual authentication enables the receivers to ensure that the
traffic comes from a particular entity (sender). This is therefore
more fine-grained than the above group authentication but is much
more difficult to provide since a simple shared secret is not enough.
This is typically a hard problem to solve for secure multicasting in
general.
A solution based on digital signatures would theoretically make it
but at the expense of decreased performance. In most multicast
applications, such a mechanism would not stand.
Considering explicit multicast, it would be practically feasible to
set up a different IPsec SA (Security Association) for each sender
(as discussed in section 3). Each sender would then use its own
"personal" SA when sending IPsec traffic to other session members.
Receivers can then determine that the traffic comes from a given
sender. However, because IPsec authentication is based on shared
secret key and because these are actually distributed to all
receivers (to enable verification on reception), this does not
guarantee individual authentication.
2.2.5 Anonymity
As already mentioned in section 2.1.2 above, anonymity in explicit
multicast traffic can only be provided in a limited way during the
data traffic exchange. Senders know the receivers and vice-versa.
Receivers would not know each other only if there is a mechanism by
which other receiver addresses are removed prior to datagram relay to
the final destination (such a mechanism would still need to be
compatible with other security mechanisms such as data integrity
covering the IP datagram).
2.2.6 Data Confidentiality
Paridaens, et al Expires December 2002 [Page 8]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
Data confidentiality requires that the sender and the receivers
commonly agree on a shared secret key used for traffic encryption.
Issues linked to the distribution of the shared secret are further
discussed in section 4 below.
The major problems linked to data confidentiality are when members
join or leave the group.
When a new member joins the group, two situations may arise. First,
the member may be allowed to see the traffic that was exchanged prior
to its joining. In such a case, it is sufficient to give a copy of
the current group encryption key to that new member. On the
contrary, the member may be prevented from seeing the traffic
previously exchanged. In that case, a new encryption key must be
generated and distributed to all members for use.
When a member leaves the group, the leaving member may be prevented
from seeing the future traffic. It is therefore necessary to change
the shared secret key used for data encryption between the remaining
members.
2.2.7 Denial of Service
Some forms of denial of service attacks can take advantage of the
multicast characteristics to increase their "effects". Such an
attack is the smurf attack whereby an ICMP Echo request (ping) is
sent to a multicast address with a source address which is the target
of the attack. Measures have been taken in traditional multicast
schemes to forbid replies on such ICMP requests : a router or host
can be configured so as to reply or not to ICMP requests with a
multicast address, the Reverse Path Forwarding check is inherent
traditional multicast architectures also helps in preventing such
attacks. However, in explicit multicast, it can be more difficult to
simply forbid it because the destination may not recognize that this
is an explicit multicast IP datagram (if all other receiver IP
addresses have been removed). The effect is however greatly
diminished because of the small number of members.
Obviously, the use of IPsec to provide confidentiality and/or
authentication can diminish those risks.
3 Use of IPsec
This section focuses on the possibility to use IPsec for securing
explicit multicast traffic. The discussion relates to the xcast
encoding methods described in [1].
3.1 IPsec Issues
Paridaens, et al Expires December 2002 [Page 9]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
3.1.1 SPI Generation
The SPI value , which is used by the IP datagram receiver to uniquely
identify the SA, is chosen by the recipient itself when setting up
the SA. In a multicast environment, this becomes unfeasible.
If left to the sender, the choice of the SPI value should be done so
by the sender that it cannot possibly conflict with SPI values chosen
by other entities sending IPsec traffic to any of the receivers
(given that from the receiver's point of view, the SPI value in the
received IP datagram solely identifies which SA to use for processing
the datagram). To overpass this problem, the rule could be that the
SPI value chosen by the sender is based on unique information such as
its IP address. However, this does not solve the problem if several
senders exist for the multicast group : no single sender can generate
the unique SPI value usable by other senders (the unique SPI value
should then be distributed to other senders so that they can use it
as if they were the SPI creator).
Generation of the SPI value (together with the shared keying
material) can be left to some designated server which then
distributes this SPI value to all members for use. The set up of the
multicast SA would then be under the control of this central entity
rather than the sender(s), using some key distribution protocol as
discussed in section 4.
Another possibility is to let each sender generate and distribute the
SPI value (together with the shared secret material) to every
receiver. Each sender therefore creates and makes use of its own
IPsec SA. This avoids problems linked to sharing an IPsec SA between
several senders. This is further discussed in section 4 below.
3.1.2 Anti-replay Protection
The anti-replay mechanism provided by IPsec (AH and ESP) is based on
the use of a sequence number which is always set (and incremented) by
the sender and may optionally be verified by the receiver.
Such a mechanism does not scale when several senders would make use
of the same Security Association previously set up to protect the
multicast traffic. Each sender would indeed handle its own counter
out of synchronization with other senders. Receivers would
consequently detect duplicates by examining the sequence number in
incoming IP datagrams although these would actually have been
generated by different entities.
A possible solution to this problem is to have the receivers take
account of the couple (SPI, source IP address) when checking for
Paridaens, et al Expires December 2002 [Page 10]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
duplicates, hence maintaining a separate window for each potential
sender. Because explicit multicast groups are not large, this is
achievable.
Another possible solution would be to set up different SA's per
sender. Each SPI would therefore be implicitly related to the
corresponding sender. This is further discussed in section 4.2 below
on key management.
3.2 AH
We hereby assume that the sender makes use of a single SA (hence SPI)
for all receivers. Issues and solutions to achieve this are further
discussed in sections 3.1.1 and 4.2. In case several senders co-
exist, it is suggested as discussed in section 4 that each sender has
its own SA.
The AH payload is inserted between the IP header and the IP data
being carried (e.g. TCP, UDP, ICMP, ...). Its integrity protection
basically covers the header source and destination IP addresses and
any header option defined to be protected (whether, and how, the
option is covered, is specified within the specification defining
that option, together with the setting of a "mutability flag" in the
context of IPv6 header options).
3.2.1 Xcast4
If AH is applied after the Xcast4 header has been placed in the IPv4
datagram, which corresponds to the common understanding of applying
IPsec on the whole IP datagram once it has been built, the whole
Xcast4 header is covered by AH. This gives the following resulting
construction.
[IP] [AH] [Xcast4] [app payload]
As such, no modification can be brought to the Xcast4 fields by
intermediate routers.
IPsec defines the possibility to define IPv4 header options as
mutable, hence providing a way to avoid calculating AH over such
options. However, this only applies to header options, not to
payloads carried within the IP datagram. Consequently, current IPsec
implementations would be incompatible with the Xcast4 encoding
described in [16]. It is also worth noting that intermediate Xcast-
enabled routers must be able to skip the AH payload before getting to
the routing information.
Another scenario would be to apply Xcast4 after IPsec as described in
Paridaens, et al Expires December 2002 [Page 11]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
the following construction.
[IP] [Xcast4] [AH] [app payload]
This would break the IP implementation model and would anyway not
really make sense: the destination addresses must be provided before
IPsec can be applied since the IPsec SA applied depends on the
destination addresses. It would also require modifications to the
IPsec implementation module itself (to ensure that the preceding
Xcast4 payload does not bring trouble to the IPsec module).
It can be noted that a solution to the above problem would be to
separate the bitmap field from the Xcast4 payload and place the
bitmap into a (mutable) IPv4 option.
Whatever solution is finally adopted, it appears that anonymity
cannot be provided if AH is being applied to the IP datagram. It
would indeed require to also leave the list of addresses out of the
AH coverage, which would leave no useful information in the Xcast4
payload to be covered by AH. Hence, if anonymity is required, AH
should not be used (or at least AH should not protect the Xcast4
payload at all).
3.2.2 Xcast6
In the context of IPv6, [1] defines two new header extensions: the
Routing extension and the Destination extension.
The Routing extension must be flagged as mutable since the bitmap
field in it changes on the way. It is worth noting that the
extension option type and length subfields are covered by AH: only
the option data subfield is considered as a stream of '00'H bytes.
This implies that the use of AH does not enable anonymity (as the
latter would require removing the list of destinations and therefore
change the actual extension length, or even removing the whole
extension although its presence is covered by AH).
The Destination extension can be flagged non-mutable and covered by
AH. In case of anonymity, the list of port numbers does not bring
relevant information on destinations, except for the number of
destinations.
As in the case of Xcast4, it would be better to separate the bitmap
field and make it a (mutable) separate extension. This would enable
to use AH to cover the (non-mutable) Routing extension containing the
list of destination addresses.
3.3 ESP
Paridaens, et al Expires December 2002 [Page 12]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
We hereby assume that the sender makes use of a single SA (hence SPI)
for all receivers. Issues and solutions to achieve this are further
discussed in sections 3.1.1 and 4.2. In case several senders co-
exist, it is suggested as discussed in section 4 that each sender has
its own SA.
3.3.1 Xcast4
In the commonly understood IPsec model, the ESP payload is added
after the IP header and "wraps" the IP data (e.g. TCP, UDP, ICMP,
...) being covered with ESP. The following construction illustrates
this scenario.
[IP] [ESP [Xcast4] [app payload] ]
Hence, the IP header and any payload placed in front of the ESP
payload is left unprotected (by ESP). Such a construction is not a
valid solution. Because the list of destination IP addresses must be
accessed by routers, the Xcast4 payload cannot logically be placed
into the ESP "wrapped" data part (routers would need to go into the
ESP payload to find routing information). Moreover, the Xcast4
payload may be simply unreadable to routers if ESP provides
encryption.
Another scenario would be to apply IPsec before Xcast4. The ESP
payload would therefore not interact with the field (whether option
or payload) containing the explicit multicast information since this
latter would appear before the ESP payload, as illustrated in the
schema below.
[IP] [Xcast4] [ESP [app payload] ]
However, this would somewhat break the IP implementation model for
the same reasons given in 3.2.1.
3.3.2 Xcast6
In the context of IPv6, [1] defines two new header extensions: the
HBHorRouting extension and the Destination extension. Since ESP does
not cover the IPv6 header, there is no interaction betwen ESP and
Xcast6 (which hence remains unprotected if authentication is provided
by means of ESP only).
4 Key Management
One important aspect in secure multicast communications is the
distribution (and renewal) of the keying material to all partners
There are several aspects to be considered in multicast key
Paridaens, et al Expires December 2002 [Page 13]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
management. However, because we are here focusing on explicit
multicast, some simple solutions can probably be considered to
resolve the problems in a practical way. We first discuss three
problem aspects and we then suggest solutions for key management. in
an explicit multicast context.
4.1 Key Management Issues
4.1.1 Key Distribution
Key distribution mechanisms where each group member contributes to
the generation of the shared secret keying material do not scale very
well. A scheme whereby some designated entity (a central entity or
the sender) distributes the keying material to every member is
therefore a better path towards a solution. Within the model under
development in msec/gsec, such an entity (KS - Key Server) is
combined with the GC and is hence termed GCKS. A scheme whereby a
single GCKS is responsible for generating the keying material and
distributing it to members is probably the best way. However, this
requires that members fully trust the GCKS for this task. Depending
on the application, the role of the GCKS (and in particular the KS
aspect) can be better left to a third-party entity and not a
participant such as a sender.
If there are several senders however (i.e. in a n-m multicast
context), the problem remains of coordinating the key generation and
distribution between all the senders. One possibility is therefore
to have each sender to generate and distribute its own secret
material to all other potential receivers (including other senders).
Because explicit multicast is dedicated to very sparse groups (up to
the order of 10 members), this is practically feasible as we avoid
scalability problems.
If access control or confidentiality are required (one could indeed
imagine a group to which anyone can subscribe but still requires
subscription to read the multicast traffic), key distribution must be
combined with strong member authentication (iow. keys must be
distributed to authenticated members only). This is also better
achieved by some designated entity. Moreover, one can benefit from
the protocol used to control the access (which would usually be
unicast) to authenticate and distribute the keying material.
4.1.2 Membership Dynamics
Traffic confidentiality also severely impacts on the key distribution
scheme when non-current members are not allowed to read the traffic.
This indeed means that the keying material must be changed each time
a member joins or leaves the group so as to prevent it from reading
Paridaens, et al Expires December 2002 [Page 14]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
past or future traffic.
4.1.3 Security Association Negotiation
Key management (initial keying material distribution, updates)
naturally apply within the context of SA management (as achieved with
IKE for unicast IPsec connections). Key management is however not
the sole aspect of SA management, which also includes negotiating
cryptographic algorithms, use of AH and/or ESP is IPsec is used, SA
lifetime, ...
In a 1-1 unicast context, this is "readily" achieved with a protocol
such as IKE which enables two entities to negotiate services and
algorithms based on their respective capabilities. In a multicast
context, this becomes somewhat unfeasible and the negotiation is
limited to accept or reject what the sender or GCKS imposes.
In an explicit multicast context, the capabilities and policy of the
(few) members could be made available in a directory (DNS, LDAP) so
that sender(s) and GCKS can try and take account of everyone's
desiderata as much as possible before making a final choice.
4.2 Possible Solutions
4.2.1 Manual Configuration
Given the small number of members in an explicit multicast session,
it is possible to manually configure each member. However, this is
not very practical when the configuration needs to be updated because
a member joins or leaves or because rekeying must occur after some
period.
4.2.2 IPsec-based Configuration Protocol
IKE is defined to provide key management for IPsec in a 1-1 unicast
context. There is currently no key management protocol for n-m
multicast environments. One possibility is to take advantage of the
very low membership which characterizes explicit multicast together
with the fact that each sender knows all the receivers.
Considering each sender separately, it sets up a different IPsec
connection with each receiver (this IPsec connection is built as
usual using IKE since this is a 1-1 unicast "connection"). The
sender then generates, on its own, the Security Association (all the
necessary keying material, crypto algorithms, unique SPI value, ...).
The sender distributes that material (SA parameters) to each other
member safely over the individual IPsec connections (using some
simple protocol). The whole keying material is therefore generated
Paridaens, et al Expires December 2002 [Page 15]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
under the sole responsibility of the sender.
All in all, this results in the set up of maximum nxm (unicast) IPsec
connections (this number can be reduced if some senders are also
receivers).
4.2.3 SIP-based Management
This solution is applicable when SIP is used to create the explicit
multicast session itself. SIP contains provision for carrying
encrypted material using an S/MIME data blob for example. This
functionality can be used to distribute SA parameters amongst members
at the same time as the member is being invited using SIP. With this
method, a single SA can be created (under the control of a SIP
server) and made known to all members. It also becomes difficult to
update the SA since SIP is normally used once at the beginning (and
once when leaving the session but the remaining members are not
contacted then).
4.2.4 New IKE Phase 2 Exchange Type
This is a variant of the scenario described in 4.2.2 above.
Considering each sender separately, it sets up a unicast IKE
connection (IKE phase 1) with each other member. A new exchange type
for phase 2 is defined that enables the sender to distribute ("push")
the SA parameters to the other side (ie. other members). Each sender
generates a single SA that will be distributed to all other members.
5 Security Considerations
This whole memo is about security considerations.
References
[1] Ooms et al, "Explicit Multicast (Xcast) Basic Specification",
draft-ooms-xcast-basic-spec-03.txt, June 2002.
[2] Kent et al, "Security Architecture for the Internet Protocol",
RFC 2401, November 1998.
[3] Kent et al, "IP Authentication Header", RFC 2402, November 1998.
Paridaens, et al Expires December 2002 [Page 16]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
Authors' Addresses
Olivier Paridaens
Alcatel
Fr. Wellensplein, 1
B-2018 Antwerpen
Belgium
Phone : +32 (0)3 2409320
E-mail : Olivier.Paridaens@alcatel.be
Dirk Ooms
Alcatel
Fr. Wellensplein, 1
B-2018 Antwerpen
Belgium
Phone : +32 (0)3 2404732
E-mail : Dirk.Ooms@alcatel.be
Bernard Sales
Alcatel
Fr. Wellensplein, 1
B-2018 Antwerpen
Belgium
Phone :
E-mail : Bernard.Sales@alcatel.be
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Paridaens, et al Expires December 2002 [Page 17]
Internet Draft draft-paridaens-xcast-sec-framework-02.txt June 2002
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Paridaens, et al Expires December 2002 [Page 18]