IPSEC Working Group Ashar Aziz
INTERNET-DRAFT Tom Markson
Hemma Prafullchandra
Sun Microsystems, Inc.
Expires in six months December 21, 1995
SKIP Extensions for IP Multicast
<draft-ietf-ipsec-skip-mc-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed to
to the working group mailing list (ipsec@ans.net) or to the authors.
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 draft documents are 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
draft-ietf-ipsec-skip-mc-00.txt [Page 1]
INTERNET-DRAFT SKIP-MC December 21, 1995
Abstract
This document describes extensions to the base SKIP [1] protocol to
allow encrypted/authenticated multicast communications.
draft-ietf-ipsec-skip-mc-00.txt [Page 2]
CONTENTS
Status of this Memo................................. 1
Abstract............................................ 2
1. SKIP Extensions for Multicast IP.................... 3
1.1 Transient Multicast Groups..................... 3
1.2 Broadcast/Permanent Multicast Groups........... 8
1.2.1 SKIP and RIPv2 8
2. Security Considerations............................. 9
3. Assigned Numbers.................................... 10
3.1 SKIP Multicast GIK request port................ 10
References.......................................... 10
Author's Address(es)................................ 10
- i -
INTERNET-DRAFT SKIP-MC December 21, 1995
1. SKIP Extensions for Multicast IP
This document discusses extensions to SKIP for use with multicast
protocols. The reader is expected to be familiar with the concepts and
formats discussed in the base SKIP document [1].
We describe multicast key distribution in two specific contexts. The
first is in the context of a transient multicast group, where an
application, such as video/audio conferencing, dynamically allocates a
multicast address or addresses, uses it for a period of time, and then
relinquishes the multicast address.
The second is in the context of permanent multicast groups, where a
fixed set of well known multicast addresses is used by participants of
the protocol. Examples of this are routing protocols that use well known
multicast addresses in order to propagate routing information in the
network.
Broadcast IP may be considered a special case of the second context,
where a set of well known IP addresses serve as broadcast addresses for
a subnetwork.
A goal of this protocol is the smooth integration of multicast SKIP with
unicast SKIP. Every attempt has been made to correspond fields in
Multicast SKIP packets to the corresponding fields in unicast SKIP
packets.
1.1 Transient Multicast Groups
A simple extrapolation of SKIP for unicast IP gives a scalable key-
management scheme for IP multicast applications. In order to achieve
secure transient multicast groups, key-management awareness needs to
exist in the multicast group-join process.
Furthermore, in order to distribute multicast keying material, the
notion of a group owner needs to exist. How the identity of the group
owner is established and communicated to the participating nodes is left
to the application layer. However, this also needs to be done in a
secure fashion, otherwise the underlying key-management can be defeated.
When secure multicasting to multicast address M is required, a group
membership creation primitive will establish the group key Kg and the
membership list of addresses that are allowed to transmit and receive
encrypted multicast datagrams to and from group address M. This action
will be taken by the group owner.
draft-ietf-ipsec-skip-mc-00.txt [Page 3]
INTERNET-DRAFT SKIP-MC December 21, 1995
An important point is that the group key Kg is not used as a packet
encryption key, but rather as the Group Interchange Key (GIK). Namely,
Kg is used as a key-encrypting-key, similar to way the master keys Kij
are used in SKIP for unicast IP.
Nodes wishing to transmit/receive encrypted datagrams to multicast
address M need to acquire the GIK Kg. This is done by sending an
encrypted/authenticated request-to-join primitive to the group owner. If
the requesting node's address is part of the group's authorized
membership list, then the group owner will send the GIK Kg, algorithm
identifier, associated lifetime information and key-change policy in an
encrypted packet, using the unicast SKIP protocol described in [1].
The packet formats for the GIK request/response is given below. This
describes the payload portion of either a TCP or UDP packet, which has
been enhanced using SKIP unicast procedures. If using UDP, multiple
requests may need to be sent, in case of packet losses of earlier
requests/response messages. The request is sent to TCP/UDP port #
skip-mc-gikreq (which is specified in Section 3). It is sent to the
group owner's unicast IP address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first field specifies the version of this protocol, which is 1. The
RESERVED field is reserved for future use. It MUST be set to 0 by the
sender and ignored by the receiver. It is followed by the actual IP
multicast address for which the GIK is being requested. The request
packet that is sent must have the minimal enhancement of source-origin
authentication, which is accomplished using the AH protocol. The group
owner's response is an encrypted packet containing the GIK Kg. The
response is sent to the requestor's ephemeral TCP/UDP port at the
requester's unicast IP address. The packet format is as follows, and as
before, it defines the data-portion of a TCP or UDP packet.
draft-ietf-ipsec-skip-mc-00.txt [Page 4]
INTERNET-DRAFT SKIP-MC December 21, 1995
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recommended Key Change Interval (in seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recommended Key Change Interval (in bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kg Alg | Crypt Alg | MAC Alg | Comp Alg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kg .... (length dependent on Kg Alg)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IP multicast address is the address for which the gik was requested.
The RESERVED field is reserved for future use. It MUST be set to 0 by
the sender and ignored by the receiver.
The 32-bit expiry time specifies when the multicast key is considered to
have expired. This is an unsigned count of the number of seconds since,
Jan 1, 1995 00:00:00 UT. The Recommended Key-Change interval is what
every source of encrypted traffic to the multicast group uses to
determine the key-change policy. There are two ways of specifying key-
change policy. One is in terms of elapsed time since last key-change.
This is specified by the "Recommended Key Change Interval (in seconds)"
field, which specifies the number of seconds to wait before changing
keys. The other is in terms of the amount of data encrypted in a given
packet encryption key. This is specified using the "Recommended Key
Change Interval (in bytes)" field. Each source of encrypted traffic MUST
use whichever of these determines the more frequent key-change policy,
whether this is in terms of amount of traffic encrypted in a given key,
or in terms of elapsed time (in seconds) since the last key change.
Kg Alg refers to the algorithm used for multicast traffic key
encryption. Crypt Alg, MAC Alg and Comp Alg refer to the multicast
traffic encryption, authentication and compression algorithms,
respectively. These are the algorithms that sources of protected traffic
to the multicast group MUST use for multicast traffic.
draft-ietf-ipsec-skip-mc-00.txt [Page 5]
INTERNET-DRAFT SKIP-MC December 21, 1995
The key Kg is updated using the zero-message master key update procedure
described in the base SKIP document [1]. Instead of using Kij as the
input to generating the n'th master key Kijn, the multicast key Kg shall
be used to generate the n'th level GIK, labeled Kgn.
Symbolically:
Kgn = h(Kg | n | 01H) | h(Kg | n | 00H)
where h() is a pseudo-random, one-way hash function such as MD5. For
this version of SKIP, the one-way function MUST be MD5. The "|"
represents concatenation. The low order bits of the output of this
operation are used for Kgn. Kgn is then used to encrypt packet keys,
analogous to how packet keys are protected for unicast IP using Kijn.
The n value is an unsigned 32 bit value. This n is present in the SKIP
multicast packet defined in the next section. It is identical to the n
value defined in the base SKIP document [1].
When using public key agreement or manual key agreement to establish Kg,
Kg MUST be 256 bits long. This means that if Kg is derived from g^ij mod
p, then the low order 256 bits are used as the input to the Kgn
calculation. When manually establishing Kg, the Kg length MUST be 256
bits.
Transmitting nodes to group address M will randomly generate packet
encryption keys Kp, and encrypt these keys using Kgn. The packet
structure is similar to the structure used for encrypted unicast SKIP
packets, except that the packet keys Kp are not encrypted in the
pairwise keys Kijn, but instead are encrypted using the GIK Kgn. An
example encrypted multicast packet using ESP [4] for packet encryption,
is shown below. For Complete information on SKIP with ESP, see the base
SKIP document [1].
draft-ietf-ipsec-skip-mc-00.txt [Page 6]
INTERNET-DRAFT SKIP-MC December 21, 1995
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clear IP Header protocol = SKIP... (typically 20-bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Ver | RSVD | Source NSID | Dest NSID |NEXT HEADER | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Counter n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
| Reserved | Crypt Alg | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Kp encrypted in GIK Kgn... (typically 8-16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| SPI=SKIP_SPI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
| Opaque Transform Data, variable Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
The destination IP address will be used by the receiver to determine
whether to use unicast or multicast key-processing procedures on a
received IP packet. In case the destination address is an IP multicast
address, it will use the GIK Kgn to decrypt the packet encryption key
Kp. An implementation of this protocol MUST use the destination IP
multicast address to lookup the GIK Kgn. (In this case the Destination
NSID MUST be zero).
There are two distinct advantages of this scheme. First, every member
of the multicast group can update packet encryption keys as often as
they need (in line with the policy set by the group owner), without
involving key-setup communications overhead involving every member of
the group. This can be extremely frequent, e.g. once every few seconds
even with very large multicast groups, because there is no extra
communications overhead for updating packet encryption keys.
Second, since all the packet encryption keys are randomly generated, and
hence different, there is no problem in using stream-ciphers with
multicast. This is because each source of encrypted traffic when using a
stream cipher would use a different key-stream and thus there is no
key-stream reuse problem. If all members of the multicast group used the
same packet encryption key, then certain stream ciphers could not be
used with multicast IP, because of problems related to key-stream reuse.
draft-ietf-ipsec-skip-mc-00.txt [Page 7]
INTERNET-DRAFT SKIP-MC December 21, 1995
1.2 Broadcast/Permanent Multicast Groups
For broadcast and permanent multicast groups, the key distribution
scheme is similar to the one described above for transient multicast
groups, except that Kg is permanent and has no expiry date and may be
manually distributed between authorized members of the group (multicast
or broadcast).
As for the case of transient multicast groups, the GIK Kgn is updated
using the procedure described above for transient multicast groups. This
allows for a simple, automated and scalable way of updating the master
key used for the permanent group, which further frustrates cryptanalysis
of the master key. Since n is a 32-bit number, the time it will take to
overflow this counter, based on hourly updates of the master key, is
sufficiently long to be a non-issue.
Even when relying on manual key distribution to initialize a protected
multicast/broadcast group, both the master and the traffic protection
keys are automatically updated using the procedures described above.
1.2.1 SKIP and RIPv2
As an example of both how SKIP can be used in the context of permanent
multicast groups, we describe SKIP for RIPv2 [RFC 1388]. The RIP
protocol specifies a field for authentication type and how to compute
and distribute a MAC for authenticated RIP information.
The authentication type of the first RIP entry would be set to a value
which we will assign the symbolic name SKIP. The Authentication field
would contain the MAC. The scope of authentication is identical to that
of AH [3].
Since RIP is a broadcast protocol, keying semantics are different than
with unicast.
draft-ietf-ipsec-skip-mc-00.txt [Page 8]
INTERNET-DRAFT SKIP-MC December 21, 1995
The following is an example of SKIP combined with RIP V2. For more
information on the fields in the SKIP header, please see the base SKIP
document [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clear IP Header protocol = SKIP... (typically 20-bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=RIP| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Counter n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
| Kij Alg | RESERVED | MAC Alg | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Kp encrypted in Kgn ... (typically 8-16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Command | Version | Routing Domain | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Address Family=0xFFFF | Authentication Type=SKIP_AUTH| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RIP Hdr
| AUTHENTICATION (MAC) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ....Authenticated RIP Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Here the packet authentication keys are encrypted using Kgn. Kgn is
computed using procedures described in section 1.1 above.
Other protocols can similarly be used with SKIP, either in the context
of unicast, or transient/permanent multicast and broadcast group
communications.
2. Security Considerations
The topic of this memo is security in multicast. For a complete
discussion of SKIP security considerations, see the base SKIP document
[1].
draft-ietf-ipsec-skip-mc-00.txt [Page 9]
INTERNET-DRAFT SKIP-MC December 21, 1995
3. Assigned Numbers
3.1 SKIP Multicast GIK request port
The SKIP multicast security protocol uses this port for sending the
request for the multicast GIK. This has been assigned the the value 1660
(skip-mc-gikreq) by the Internet Assigned Numbers Authority (IANA).
References
[1] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management
for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work in
Progress
[2] Deering, S. E., "Host extensions for IP multicasting", RFC 1112
[3] Atkinson, R., "IP Authentication Header", RFC 1826
[4] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827
Author's Address(es)
draft-ietf-ipsec-skip-mc-00.txt [Page 10]
INTERNET-DRAFT SKIP-MC December 21, 1995
Ashar Aziz
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: ashar.aziz@eng.sun.com
Alternate email address: ashar@incog.com
Tom Markson
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: markson@incog.com
Alternate email address: markson@eng.sun.com
Hemma Prafullchandra
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: hemma@eng.sun.com
Alternate email address: hemma@incog.com
draft-ietf-ipsec-skip-mc-00.txt [Page 11]
