Internet Engineering Task Force Ashar Aziz INTERNET-DRAFT Sun Microsystems, Inc. October 25, 1994 Simple Key-Management For Internet Protocols (SKIP) Abstract There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key-management schemes. However, many of the commonly used network layer protocols (e.g IP and IPv6) are session-less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IP or IPv6. We also describe a simple extension of this protocol to provide scalable group key-management for Internet multicasting protocols. SKIP is designed to be plugged into the IP Security Protocol (IPSP) or IPv6. This draft describes how to use SKIP in the context of the IPSP. Status of this Memo 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. This Internet Draft expires on April 25, 1995. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. 1.0 Overview Any key-management scheme that needs to scale to the number of nodes draft-aziz-skip-00.txt [Page 1] INTERNET-DRAFT Simple Key-Management for IP October 1994 possible in the Internet must be based on an underlying public-key certificate based infrastructure. This is the technology that, e.g, the key-management scheme for secure Internet e-mail, Privacy Enhanced Mail or PEM [1], is using. The certificates used by PEM are RSA public key certificates. Use of RSA public key certificates also enable the establishment of an authenticated session key [2,3]. (By an RSA public key certificate, we mean that the key being certified is an RSA public key.) (In the following description we use the term IP, although IP is replaceable by IPv6 in this context). There are two ways RSA certificates can be used to provide authenticity and privacy for a datagram protocol, such as IP. The first is to use out-of-band establishment of an authenticated session key, using one of several session key establishment protocols prior to communication. This session key is then used to encrypt/authenticate IP data traffic. Such a scheme has the disadvantage of establishing and maintaining a pseudo session state underneath a session-less protocol. The IP source would need to first communicate with the IP destination in order to acquire this session key. Also, as and when the session key needs to be changed, the IP source and the IP destination need to communicate again in order to make this happen. Each such communication involves the use of a computationally expensive public-key operation. The second way an RSA certificate can be used is through in-band signalling of the packet encryption key, where the packet encryption key is encrypted in the recipient's public key. This is the way, e.g, PEM and other public-key based secure e-mail systems do message encryption. Although this avoids the session state establishment requirement and prior out-of-band communication in order to set up and change packet encryption keys this scheme has the disadvantage of having to carry the packet encryption key encrypted in the recipient's public key in every packet. Since an RSA encrypted key would minimally need to be 64 bytes, and can be 128 bytes, this scheme incurs the overhead of 64 to 128 bytes of keying information in every packet. (As time progresses, the RSA block size would need to be closer to 128 bytes simply for security reasons.) Also, when the packet encryption key changes a public key operation would need to be performed in order to recover the new packet encryption key. Thus both the protocol and computational overhead of such a scheme is very high. Use of certified Diffie-Hellman (DH) [4] public-keys can avoid the draft-aziz-skip-00.txt [Page 2] INTERNET-DRAFT Simple Key-Management for IP October 1994 pseudo session state establishment and the prior communications requirement between the two ends in order to acquire and change packet encrypting keys. Furthermore, this scheme does not incur the overhead of carrying 64 to 128 bytes of keying information in every packet. This kind of key-management scheme is well suited to protocols like IP, because it doesn't require the remote side to be up in order to establish and change packet encryption keys. This scheme is described in more detail below. 2.0 Simple Key-Management for Internet Procotols (SKIP) We stipulate that each IP based source and destination shall have a certified Diffie-Hellman public key. This public-key is distributed in the form of a certificate. The certificate can be signed using either an RSA or DSA signature algorithm. How the certificates are managed is described in detail later. Thus each IP source or destination I has a secret value i, and a public value g**i mod p. Similarly, IP node J has a secret value j and a public value g**j mod p. Once n certificates are assigned to n IP nodes, O(n**2) authenticated pair-wise keys arise, simply as a result of the certification process. This is because each pair of IP source and destination I and J can acquire a shared secret g**ij mod p. The keys derivable from these shared secrets require no set-up overhead, except for the certification process itself. All that is required is for each party to compute the pair-wise key is to know the other party's certificate. Since a certificate is public information, one natural way to discover the relevant certificate is to distribute these certificates using a directory service. This computable shared secret is used as the basis for a key- encrypting-key to provide IP packet based authentication and encryption. Thus we call g**ij mod p the long-term secret, and derive from it a key Kij. Kij is used as the key for a block Shared-Key CryptoSystem (SKCS) like DES or RC2. Kij is derived from g**ij mod p by taking the high order key-size bits of g**ij mod p. Since g**ij mod p is minimally going to be 512 bits and for greater security is going to be 1024 bits or higher, we can always derive enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are typically in the range of 40-256 bits. The important point here is that Kij is an implicit pair-wise shared draft-aziz-skip-00.txt [Page 3] INTERNET-DRAFT Simple Key-Management for IP October 1994 key. It does not need to be sent in every packet or negotiated out-of- band. Simply by examining the source of an IP packet, the destination IP node can compute this shared key Kij. Because this key is implicit, and is used as a master key, its length can be made as long as desired, without any additional protocol overhead. Increasing the length of Kij in combination with a good cryptosystem, can make cryptanalysis of Kij arbitrarily difficult. We use Kij to encrypt a transient key, which we call Kp (for packet key). Kp is then used to encrypt/authenticate an IP packet or collection of packets. This is done in order to limit the actual amount of data encrypted in the long-term key Kij. Since we would like to keep the long-term key for a relatively long period of time, say one or two years, we don't encrypt the actual IP data traffic in key Kij. Instead we only encrypt transient keys in this long-term key, and use the transient keys (Kp) to encrypt/authenticate IP data traffic. This limits the amount of data encrypted in the long-term key to a relatively small amount even over a long period of time. The first time a source I, which has a secret value i, needs to communicate with destination J, which has a secret value j, it computes the shared secret g**ij mod p. It then derives from this shared secret the long-term key Kij. The source I then generates a random key Kp and encrypts this key using Kij. It encrypts the relevant portion of the data in key Kp (which may be the entire IP packet or just the payload of the IP packet depending on the next-protocol field in IPSP protected data portion). SKIP uses the IPSP header to identify the algorithm and key information that was used to protect the payload. The value of the SAID field is used to indicate the mode of processing. Typical modes of processing are encryption, authentication, sequencing and compression. The mode of processing is identified by 6 bits within the SAID field. The meaning of these bits is specified in section 2.6 below on SAID derived processing modes. The remaining 22 bits of the SAID field are zero. If the next protocol field is IP, i.e IPSP is operating in encrypted- encapsulated mode, source I sends the encrypted IP packet, the encrypted key Kp, encapsulated in a clear outer IP Header. The packet looks as follows. Fields are transmitted left to right. Encrypted-encapsulated mode packet draft-aziz-skip-00.txt [Page 4] INTERNET-DRAFT Simple Key-Management for IP October 1994 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 = IPSP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+ | Ver. |1|0|0|0|0|0| SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij alg. | Kp alg. | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kij... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Indicator (e.g IV)... (typically 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Begin Protected IPSP Payload (next protocol = IP)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In order to prepare this packet for transmission to node J, no communication was necessary with node J. When node J receives this packet, it also computes the shared secret Kij and caches it for later use. (In order to do this, if it didn't already possess I's certificate, it may have to obtain this from the local directory service.) Using Kij it obtains Kp, and using Kp it obtains the original IP packet, which it then delivers to the appropriate place which is either a local transport entity or another outbound interface. The two 1 byte fields, Kij alg and Kp alg in the header identify the encryption algorithms used for encrypting the packet key and the IP packet respectively. The Message Indicator (MI) is a field that is needed to preserve the statelessness of the protocol. If a single key is used in order to encrypt multiple packets, (which is highly desirable since changing the key on a per packet basis constitutes too much overhead) then the packets need to be decryptable regardless of lost or out-of-order packets. The message indicator field serves this purpose. The actual content of the MI field is dependent on the choice of SKCS used for Kp and its operating mode. If Kp refers to a block cipher (e.g DES) operating in Cipher-Block- Chaining (CBC) mode, then the MI for the first packet encrypted in key Kp is the Initialization Vector (IV). For subsequent packets, the MI is the last blocksize-bits of ciphertext of the last (in transmit order) packet. For DES or RC2 this would be last 64 bits of the last packet. For stream ciphers like RC4, the MI is simply the count of bytes that have already been encrypted in key Kp (and is 64 bits long also). draft-aziz-skip-00.txt [Page 5] INTERNET-DRAFT Simple Key-Management for IP October 1994 If the source node (I in this case) changes the packet encryption key Kp, the receiving IP node J can discover this fact without having to perform a public-key operation. It uses the cached value Kij to decrypt the encrypted packet key Kp. Thus, without requiring communication between transmitting and receiving ends, and without necessitating the use of a public-key operation, the packet encrypting key can be changed by the transmitting side and discovered by the receiving side. Since the public keys in the certificates are DH public keys, the nodes themselves have no public-key signature algorithm. This is not a problem, since signing on a per-packet basis using a public-key cryptosystem is too cumbersome. The integrity of the packets is determined in a pairwise fashion using a shared-key cryptosystem. 2.1 SKIP for Packet Authentication In order to achieve authentication in the absence of privacy, SKIP compliant implementations use the encrypted packet key Kp to encrypt a message-digest of the packet, instead of the packet itself. Alternatively, the packet key Kp can be used to compute a Message Authentication Code (MAC) using, e.g a block cipher like DES in CBC mode. The encrypted digest or the MAC is appended at the end of the packet as an Integrity Check Value (ICV). As before, Kij alg and Kp alg identify the two encryption algorithms for keys Kij and Kp. ICV alg is a 1 byte identifier for the algorithm used to compute the ICV. This mode of operation is indicated by the SAID value which is further specified in Section 2.6. 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 = IPSP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | Ver. |0|1|0|0|0|0| SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij alg. | Kp alg. | ICV alg. | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kij... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Begin Protected IPSP Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV computed using Kp... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-aziz-skip-00.txt [Page 6] INTERNET-DRAFT Simple Key-Management for IP October 1994 2.2 SKIP for Packet Encryption and Authentication Packets may be both encrypted and authenticated, by combining the previous two modes of encryption and authentication. The packet would contain both a MI field and an ICV. Indication of this mode will be specified by setting the appropriate processing mode bits in the SAID field, which is specified in Section 2.6. 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 = IPSP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | Ver. |1|1|0|0|0|0| SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij alg. | Kp alg. | ICV alg. | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kij... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Indicator (e.g IV)... (typically 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Begin Protected IPSP Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV computed using Kp... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are circumstances which sometimes require short key-lengths for encryption purposes. In such cases, it is advantageous to separate the packet encryption key from the packet authentication key. The encryption key can be made small (possibly to satisfy export laws) while keeping the authentication key as large as deemed necessary. The length of the encrypted Kp shall be derived from the maximum of that indicated by the Kp algorithm ID and the ICV algorithm ID. The full length of Kp shall be used to compute the ICV, while the upper n bits of Kp shall be used to encrypt the packet, where n is the size of the encryption key. If intruders can recover the packet encryption key (which may be required to be short) they still have to cryptanalyse a much stronger key (by virtue of its length combined with a cryptographically strong algorithm) to be able to send forged traffic without detection. 2.3 Intruder in the Middle Attacks draft-aziz-skip-00.txt [Page 7] INTERNET-DRAFT Simple Key-Management for IP October 1994 Unauthenticated Diffie-Hellman is susceptible to an intruder in the middle attack. To overcome this, authenticated Diffie-Hellman schemes have been proposed, that include a signature operation with the parties' private signature keys. SKIP is not susceptible to intruder in the middle types of attacks. This is because the Diffie-Hellman public parameters are long-term and certified. Intruder in the middle attacks on Diffie-Hellman assume that the parties cannot determine who the public Diffie-Hellman keys belong to. Certified Diffie-Hellman public keys eliminate this possibility, without requiring any exchange of messages between the two parties or incurring the computational overhead of large exponent exponentiations (e.g RSA signatures). 2.4 Storage of Cryptographic Keys Since the Kij values need to be cached for efficiency, reasonable safeguards need to be taken to protect these keys. One possible way to do this is to utilize a hardware device to compute, store and perform operations using these keys. This device can ensure that there are no interfaces to extract the keys from the device. A full discussion of system-level protection of cryptographic keys, while an important issue, is beyond the scope of this document. 2.5 Manual Keying As an interim measure, in the absence of certification hierarchies, nodes may wish to employ manually exchanged keying information. To handle such cases, the pair key Kij shall be the key that would be manually set up. Since manual re-keying is a slow and awkward process, it still makes sense to use the two level keying structure, and encrypt the packet encryption keys Kp using the manually setup pair keys Kij. This has the same benefit as before, namely it avoids over-exposing the pair key which is advantageous to maintain over relatively long periods of time. This is particularly true for high-speed network links, where it is easy to encrypt large amounts of data over a short period of time. Because of the separation of interchange keys (the pair keys Kij) and traffic encryption keys (packet encryption keys Kp), the SKIP structure makes it possible to easily change traffic encryption keys even when relying on manual key distribution. 2.6 Processing Modes and SAID values draft-aziz-skip-00.txt [Page 8] INTERNET-DRAFT Simple Key-Management for IP October 1994 A total of 6 bits of the SAID field are used to indicate the processing mode. The processing modes defined so far are, encryption, authentication, compression, and packet sequencing (for playback protection). Since none of these modes is mutually exclusive, multiple bits being on indicate the employment of all the relevant processing modes. SAID bits 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver. |E|A|C|S|R|R| zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field values: Ver.: protocol version E: 1 if packet is encrypted, 0 otherwise A: 1 if packet is authenticated, 0 otherwise C: 1 if packet is compressed before encryption, 0 otherwise S: 1 if packet is sequenced, 0 otherwise R: reserved for future use (must be 0 until specified) For example, to indicate that a packet is encrypted and authenticated, E and A should be 1, the remaining bits should be zero. When packets are sequenced, they contain a 64-bit sequence number in the protected payload, following the next-protocol field in the IPSP payload portion. When packets are compressed prior to encryption, the compression algorithm is indicated by the fourth byte in the algorithm identfiers field. After decryption, the packet must be decompressed before it can be passed on for protocol processing. The following is an example of a packet that has all the processing modes defined so far, namely encryption, authentication, compression and sequencing, turned on. 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 = IPSP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | Ver. |1|1|1|1|0|0| SAID | draft-aziz-skip-00.txt [Page 9] INTERNET-DRAFT Simple Key-Management for IP October 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij alg. | Kp alg. | ICV alg. | Comp alg. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kij... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Indicator (e.g IV)... (typically 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | next protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low 32-bits of 64-bit packet sequence number | Protected +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Portion | High 32-bits of 64-bit packet sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Begin Protected IPSP data (compressed and then encrypted)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | ICV computed using Kp... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All 32-bit quantities are transmitted in network order. If the sequencing bit is zero, the 64-bit sequence number is absent. If the authentication bit is zero, the ICV is absent. If the compression bit is zero, the output of decryption does not need to be decompressed. 3.0 SKIP for Multicast IP A simple extrapolation of SKIP for unicast IP gives a scalable key- management scheme for IP multicast applications. In order to achieve secure multicast, 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. 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 pair keys Kij are used in SKIP for unicast IP. draft-aziz-skip-00.txt [Page 10] INTERNET-DRAFT Simple Key-Management for IP October 1994 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 polict in an encrypted packet, using the pairwise secure protocol described in Section 2 above. 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 enchanced 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 # 2000. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vesion = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Multicast Address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first field specifies the version of this protocol, which is 1. 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 IPSP enchancement of source-origin authentication. It may optionally be encrypted and/or have playback protection by use of the sequence number field. The group owners response is an encrypted packet containing the GIK Kg. The response is sent to TCP/UDP port # 2001 at the requestor's unicast IP address. The packet format is as follows, and as before, it defines the data-portion of a TCP or UDP packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vesion = 1 | Kg alg. id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Multicast Address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry time (low 32-bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry time (high 32-bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recommended Key Change Interval (in secs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-aziz-skip-00.txt [Page 11] INTERNET-DRAFT Simple Key-Management for IP October 1994 | Recommended Key Change Interval (in bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kg .... (length dependent on Kg alg id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 64-bit expiry time specifies when the multicast key is considered to have expired. This is in terms of seconds since, Jan 1, 1994, expressed in GMT. 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 secs)" 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 will 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. Transmitting nodes to group address M will randomly generate packet encryption keys Kp, and encrypt these keys using Kg. 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 pair- wise keys Kij, but instead are encrypted using the GIK Kg. An example encrypted multicast packet is shown below. 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 = IPSP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+ | Ver. |1|0|0|0|0|0| SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved. | Kp alg | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | Kp encrypted in GIK Kg... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Indicator (e.g IV)... (typically 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Begin Protected IPSP Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The destination IP address will be used by the receiver to determine draft-aziz-skip-00.txt [Page 12] INTERNET-DRAFT Simple Key-Management for IP October 1994 whether to use unicast of multicast key-processing procedures on a received IP packet. In case the destination address is an IP multicast address, it will use the GIK Kg to decrypt the packet encryption key Kp. An implementation of this protocol will use the destination IP multicast address to look-up the GIK Kg. There are two distinct advantages of this scheme. First, every member of the multicast group can change packet encryption keys as often as it needs (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, even once every few seconds with very large multicast groups, because there is no extra communication overhead for changing 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. 4.0 Management of DH certificates Since the nodes' public DH values are communicated in the form of certificates, the same sort of multi-tier certification structure that is being deployed for PEM [6] can be used. Namely, there can be a Top Level Certifying Authority (TLCA) which may well be the same the Internet Policy Registration Authority (IPRA), Policy Certifying Authorities (PCAs) at the second tier and organizational CAs below that. In addition to the identity certificates, which are what are part of PEM certificate infrastructure, we also need additional authorization certificates, in order to properly track the ownership of IP addresses. Since we would like to directly use IP addresses in the DH certificates, we cannot use name subordination principles alone (as e.g used by PEM) in order to determine if a particular CA has the authority to bind a particular IP address to a DH public value. We can still use the X.509/PEM certificate format, since the subject Distinguished Name (DN) in the certificate can be the numeric string representation of a list of IP addresses. Since the nodes only have DH public keys, which have no signature capability, the nodes themselves are unable to issue certificates. This means that there is an algorithmic termination of a certificate path in a leaf node, unlike the certificate hierarchy employed in, e.g PEM, draft-aziz-skip-00.txt [Page 13] INTERNET-DRAFT Simple Key-Management for IP October 1994 where every leaf node is potentially a rogue CA. The node certificates are issued by organizational CAs which have jurisdiction over the range of IP addresses that are being certified. The PCAs will have to perform suitable checks (in line with the advertised policy of that PCA) to confirm that the organization which has jurisdiction over a range of addresses is issued a certificate giving it the authority to certify the DH values of individual nodes with those addresses. This authority will be delegated in the form of a authorization certificate signed by the PCA. For the purposes of authorization, the CA's Distinguished Name (DN) will be bound to the range of IP addresses over which it has jurisdiction. The CA has either an RSA or DSA certificate issued by the PCA. The range of IP addresses are identified in the authorization certificate in the form of a list of IP address prefix, length pairs. The exact format of the certificates is described in detail in Section 5. 5.0 X.509 Encoding of SKIP DH certificates 5.1 Encoding of DH public values The encoding of a DH Public value in an X.509 certificate will be in the form of an INTEGER. The algorithm identifier will be as defined in PKCS #3 [7]. Thus DHPublicKey ::= INTEGER and from PKCS #3, AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER SEQUENCE { prime INTEGER, --- p base INTEGER, --- g privateValueLength INTEGER OPTIONAL } } with the OBJECT IDENTIFIER value being, dhKeyAgreement OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 1} which is also taken from PKCS #3. The DHPublicKey gets encapsulated as the BIT STRING in draft-aziz-skip-00.txt [Page 14] INTERNET-DRAFT Simple Key-Management for IP October 1994 SubjectPublicKeyInfo of an X.509 certificate in the obvious manner. The certificate and CRL encoding is the same as in RFC 1422. CRLs will be used with SKIP in the usual manner, in line with each site's certificate/CRL management policies. 5.2 Encoding of the Distinguished Name (DN) The certificate is allowed to bind multiple IP addresses to a single public value to accommodate cases where a single IP node has multiple IP addresses. The SEQUENCE-OF construct in a DN readily allows for this. What is needed is an ASN.1 OBJECT IDENTIFIER for an AttributeType specifying an IP address. This is defined here as, ipAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE(1..ub-ipAddress)) ::= {ipsec-oid 1} -- ipsec-oid needs to be registered The DN in the certificate can contain multiple of these by iterating on the SEQUENCE-OF construct of the Relative Distinguished Name Sequence. The PrintableString contains either the hexadecimal representation or standard dot notation representation of an IP address. 5.3 Encoding of an Authorization Certificate An authorization certificate is associated with each CA below the PCA level. The authorization certificate in effect entitles a CA to bind IP addresses to DH public keys. The encoding of an authorization certificate is as follows; CA_AuthorizationCert ::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, issuer Name, subject Name, signature AlgorithmIdentifier, SEQUENCE-OF { prefix-mask BIT-STRING, length INTEGER }} Version ::= INTEGER { v1 (1) } The authorization certificate in effect entitles a CA at the third tier (in the IPRA/PCA model [6]) and below to bind public keys to IP nodes whose addresses are contained in the ranges defined in the SEQUENCE-OF draft-aziz-skip-00.txt [Page 15] INTERNET-DRAFT Simple Key-Management for IP October 1994 construct as a list of {IP address prefix, length} pairs. This is much the same way that an OSPF routing area is identified. If an IP nodes' address qualifies as following in this set of IP address ranges, then the CA identified in the subject field has been delegated authority by the superior CA identified in the issuer field to bind that IP nodes' IP address with its DH public key. If the superior CA is not a PCA, then that superior CA itself needs to have jurisdiction over a super-set of the range being delegated. If the superior CA is a PCA, then it needs to perform checks in line with the advertised policy of the PCA to make sure that the CA to which it is delegating authority over a range of IP addresses indeed has administrative control over that range of IP addresses. Revocation and expiry of the CA's public key certificate constitutes revocation and expiry of the CA's authorization certificate. The authorization certificate performs the same role that name subordination plays in the PEM certificate hierarchy model. Name subordination can clearly not be employed if the certificates directly contain the nodes' IP addresses, which is desirable in the IPSP framework. 6.0 Conclusions We have described a scheme, Simple Key-Management for Internet Protocols (SKIP) that is particularly well suited to connectionless datagram protocols like IP and its replacement candidate IPv6. Both the protocol and computational overheads of this scheme are relatively low. In-band signalled keys incur only the length overhead of the block size of a shared-key cipher. Also, setting and changing packet encrypting keys involves only a shared-key cipher operation, yet the scheme has the scalability and robustness of a public- key certificate based infrastructure. A major advantage of this scheme is that establishing and changing packet encrypting keys requires no prior communication between sending and receiving nodes. In addition, no establishment of a pseudo-session state between the two sides is required. We have also described how this scheme may be used in conjunction with datagram multicast protocols, allowing a single encrypted datagram to be multicast to all the receiving nodes. The SKIP multicast key-management scheme allows extreme flexibility in terms of changing multicast traffic encryption keys even for very large multicast groups. It also allows all possible traffic encryption algorithms for multicast data, including all stream ciphers. Acknowledgements draft-aziz-skip-00.txt [Page 16] INTERNET-DRAFT Simple Key-Management for IP October 1994 I would like to thank Whitfield Diffie for many helpful discussions on this subject. I would also like to thank Geoff Mulligan for reviewing this draft and providing constructive suggestions. References [1] RFCs 1421-1424, Privacy Enchaned Mail [2] A Aziz, W Diffie, "Privacy and Authentication for Wireless LANs", IEEE Personal Communications, Feb 1994. [3] W. Diffie, M. Wiener, P. Oorschot, "Authentication and Authenticated Key Exchanges.", in Designs Codes and Cryptography, Kluwer Academic Publishers, 1991. [4] W. Diffie, M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol IT-22, Nov 1976, pp. 644-654 [5] S. E. Deering, "Host extensions for IP multicasting", RFC 1112 [6] S. Kent, "Certificate Based Key Management," RFC 1422 for PEM [7] "Public Key Cryptography Standards" 1-10 from RSA Data Security Inc., Redwood City, CA draft-aziz-skip-00.txt [Page 17]