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