Internet Engineering Task Force Ashar Aziz INTERNET-DRAFT Sun Microsystems, Inc. Expires in six months September 28, 1995 Simple Key-Management For Internet Protocols (SKIP) Status of this Memo 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. Future revisions of this document are intended to become a standards track RFC in the area of key-management for Internet protocols and applications. Comments should be sent to the IP Security WG mailing list (ipsec@ans.net) or directly to the author. 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-02.txt [Page 1] INTERNET-DRAFT SKIP September 28, 1995 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 (for example, 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. The SKIP protocol has been designed to work with the IP Security Protocols AH and ESP [8,9,10] which are specified for both IPv4 and IPv6. draft-ietf-ipsec-skip-02.txt [Page 2] CONTENTS Status of this Memo................................. 1 Abstract............................................ 2 1. Overview............................................ 3 1.1 Simple Key-Management for Internet Protocols..................................... 5 1.2 Manual distribution of Kij.................... 8 1.3 Zero-Message Master Key Update Algorithm...... 8 1.3.1 Zero Message Master key Update with Diffie-Hellman 9 1.3.2 Zero Message Master Key update with Manual Keying 9 1.4 Independence from Cryptographic Algorithms.................................... 9 1.5 Storage of Cryptographic Keys................. 10 1.6 SKIP for High Availability and Load Balancing..................................... 11 1.7 Attacks that the protocol guards against...... 11 1.7.1 Intruder in the Middle Attacks 12 1.7.2 Known Key Attacks 12 1.7.3 Anti-Clogging Defense 12 1.7.4 Non-Goal: Perfect Forward Secrecy 13 1.8 Naming, Name Spaces and Master Key-IDs........ 13 1.8.1 The SKIP Header 16 - i - 1.8.2 The relative order of compression, encryption and authentication 18 1.9 SKIP for Authentication....................... 19 1.9.1 SKIP with AH 19 1.9.2 Scope of MAC computation 20 1.10 SKIP for Encryption........................... 21 1.10.1 SKIP with ESP 21 1.11 SKIP for Packet Encryption and Authentication................................ 22 1.11.1 SKIP with AH and ESP 24 1.11.2 SKIP with combined ESP transforms 25 1.12 Generic use of SKIP header.................... 26 2. SKIP for Multicast IP............................... 26 2.1 Transient Multicast Groups.................... 27 2.2 SKIP for Broadcast/Permanent Multicast Groups........................................ 30 2.2.1 SKIP and RIPv2 31 3. Algorithm Discovery................................. 32 4. Distribution of authenticated public keys........... 35 4.1 X.509 encoding of DH public values............ 35 4.2 Encoding of the Distinguished Name (DN)....... 37 4.3 Certificate Discovery Protocol................ 38 4.4 Algorithm to determine which Diffie-Hellman public value to use........................... 40 5. Assigned Numbers.................................... 40 - ii - 5.1 SKIP protocol number.......................... 40 5.2 SKIP SPI value................................ 41 5.3 Name Space Identifier (NSID) Assignments...... 41 5.4 Assigned Algorithm Numbers.................... 41 5.5 SKIP ICMP message (SKIP_ICMP)................. 43 5.6 SKIP Certificate Discovery Protocol........... 43 6. Recommended Parameters and Implementation Notes..... 43 6.1 Generating Random Keys........................ 43 6.2 Key Update.................................... 45 6.3 n Update Frequency............................ 45 6.4 Recommended G & P values...................... 46 6.4.1 Parameters for 1024 bits Modulus: 46 6.4.2 Parameters for 512 bits Modulus: 47 7. Conclusions......................................... 47 Acknowledgements.................................... 48 References.......................................... 49 - iii - INTERNET-DRAFT SKIP September 28, 1995 1. Overview Any key-management scheme that can scale to the number of nodes possible in the Internet must be based on an underlying authenticated public key based infrastructure. These authenticated public keys may be distributed using a variety of mechanisms, such as public key certificates, a secure directory server and so on. ITU standard X.509 provides an example of distributing authenticated public keys using certificates. Secure DNS [11] provides an example of distributing authenticated public keys (and other resources) using a secure directory service. Still another example of distributing authenticated public keys is the web-of-trust "introducer" model, best exemplified in the PGP secure e-mail software package. All of these mechanisms essentially provide a secure binding between an entity's name (or identifier) and its public key. Most of the existing applications assume that the key being authenticated is a key for a public key cryptosystem, such as RSA [7]. There are two ways authenticated RSA public keys 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 [2,3]. This session key is then used to encrypt/authenticate IP data traffic. Such a scheme has the disadvantage of having to establish and (securely) manage a pseudo session layer underneath IP, which is 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 could involve the use of a computationally expensive public key operation. This secure management of the pseudo session state is further complicated by crash recovery considerations. If one side crashes, and loses all session state, then mechanisms need to exist to securely remove the half-open session state on the side that did not crash. These mechanisms need to be secure because insecure (unauthenticated) removal of half-open sessions would open the door to a trivial denial of service attack. Performing session oriented key-management at the IP layer has another drawback. An important feature of the IP protocol is recovery from draft-ietf-ipsec-skip-02.txt [Page 3] INTERNET-DRAFT SKIP September 28, 1995 intermediate node or link failures, by dynamically re-routing around failed intermediate links and nodes. Indeed, a basic motivation for the design of the IP layer was to help build a network that could repair itself from failure due to destruction of partial network assets under a military attack. In the commercial environment, this same requirement exists for reasons of high availability of network access and services. IP facilitates this failure recovery by not requiring intermediate nodes to maintain any kind of state on a per communications instance basis. Each IP packet is independently routable. This permits simple re-routing of IP traffic around failed routers/links. In addition to re-routing for reasons of router/link failure, IP protocols also perform dynamic routing to better utilize the network's capacity, by performing load balancing of network traffic. For example, if equal cost routes exist to a destination, the OSPF [16] routing protocol will split the traffic among those equal cost routes, thereby load balancing IP traffic among several different routers/links. Performing session oriented key-management for IP defeats these properties of IP. For example, if encryption is being performed between two intermediate points (e.g. encrypting routers) then session oriented key-management makes dynamic re-routing of encrypted IP traffic for reasons of failed or congested nodes/links far more complicated than the straightforward fail-over/re-routing mechanisms that exist for unencrypted IP traffic. This is because, in essence, a stateful connection has been created between two intermediate points. A packet is no longer an independent entity; it now requires information from a security association establishment phase, namely the session key, in order to be properly processed. Rerouting encrypted traffic for decryption by another intermediate point either for fail-over or load- balancing considerations is not practical with session oriented key- management. This is because it is not practical to simply and securely share transient session keys, which exist only on a pairwise basis, with many other intermediate nodes. Without knowledge of the transient session key with which the packets are protected, another intermediate node is not able to decrypt/authenticate re-routed IP traffic. Thus, session oriented key-management implemented underneath the IP layer breaks many of the properties which have made IP successful as an internet protocol. This motivates considering key-management schemes that operate in a session-less and stateless manner. An alternative design could utilize authenticated RSA public keys in a stateless key-management scheme. This might work through in-band draft-ietf-ipsec-skip-02.txt [Page 4] INTERNET-DRAFT SKIP September 28, 1995 signaling of the packet encryption key, where the packet encryption key is encrypted in the recipient's RSA public key. This is the way, for example, PEM and PGP perform 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 each IP 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 or greater than 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 authenticated Diffie-Hellman (DH) [4] public keys can avoid the need for pseudo session state management between two ends in order to acquire and change packet encrypting keys. Authenticated DH public keys serve as the basis for a very simple, efficient and stateless key- management scheme that does not entail any of the drawbacks noted above. Apart from being exceedingly simple to implement, this stateless key- management scheme provides straightforward and scalable solutions to permit dynamic re-routing of protected IP traffic through alternate encrypting intermediate nodes for crash-recovery/fail-over/load- balancing scenarios. 1.1 Simple Key-Management for Internet Protocols We stipulate that each IP based source and destination shall have an authenticated Diffie-Hellman public key. This public key may be distributed in numerous ways. One mechanism (described here) is by the use of X.509/PEM certificate format [6]. Other mechanisms, for example, PGP certificates, secure DNS resource records, and related issues such as various trust models are detailed in an adjunct Internet-Draft. The X.509 certificates can be signed using any signature algorithm, such as RSA or DSA. The subject Distinguished Name (DN) in the X.509 certificate is the numeric string representation of a list of IP addresses or equivalent identifier for principals in the network. Examples of principals in the network are IP nodes, or users. In the discussion below we focus on IP nodes, although a straightforward extrapolation to user oriented keying is possible and is further described later. draft-ietf-ipsec-skip-02.txt [Page 5] INTERNET-DRAFT SKIP September 28, 1995 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) mutually authenticated pairwise keys arise, simply as a result of the authenticated public key distribution process. This is because each pair of IP source and destination I and J can acquire a mutually authenticated shared secret g^ij mod p. The symmetric keys derivable from these shared secrets require no setup overhead, except for the authenticated public key distribution process itself. All that is required for each party to compute the pairwise symmetric key is to know the other party's authenticated public key. Since there is nothing secret about DH public keys, one natural way to discover the relevant authenticated public key is to distribute these 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 Symmetric Key CryptoSystem (SKCS) like DES, RC2, IDEA, and such. Since Kij is used for key- encryption, it is not practical to use a stream cipher for this purpose. Kij is derived from g^ij mod p by taking the low order key-size bits of g^ij mod p. Since g^ij mod p should minimally be 512 bits and for greater security should be 1024 bits or more, 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 pairwise shared key. It does not need to be sent in ANY packet or negotiated out-of-band. The destination IP node can compute this shared key (Kij) by simply knowing the source IP node's authenticated public key. Because this key is implicit, and is used as a MMMMaaaasssstttteeeerrrr kkkkeeeeyyyy,,,, its length can be made as long as desired, without any additional protocol overhead. Increasing the length of Kij in combination with a strong 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 as a key to encrypt/authenticate an IP packet or a collection of packets. This is done in order to limit the actual amount of data encrypted using the long-term key Kij, since we would like to keep it for a relatively long period of time, one or two years, we draft-ietf-ipsec-skip-02.txt [Page 6] INTERNET-DRAFT SKIP September 28, 1995 therefore do not 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 protected using the long-term key to a relatively small amount even over a long period of time, since keys (Kp) represent a relatively small amount of data. Because Kij is used to only encrypt other keys, and not traffic, it is referred to as a master key. The first time a source I, which has a secret value i, needs to communicate with destination J, which has a public value g^j mod p, it computes the shared secret g^ij mod p. It then derives from this shared secret the master key Kij. The source I then generates a random key Kp and encrypts this key using Kij. The Kij and Kp keys are used as keys for a symmetric key algorithm. Note: 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 did not already possess I's authenticated DH public key, 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 handler which is either a local transport entity or another outbound interface. 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/authenticating keys can be changed by the transmitting side and discovered by the receiving side. Since the authenticated public keys are Diffie-Hellman 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 using a symmetrically keyed Message Authentication Code (MAC). draft-ietf-ipsec-skip-02.txt [Page 7] INTERNET-DRAFT SKIP September 28, 1995 1.2 Manual distribution of Kij As an interim measure, in the absence of an authenticated public key distribution infrastructure, nodes may wish to employ manual distribution of keying information. To handle such cases, the master key Kij SHOULD be the key that is manually established. 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 key Kp using the manually established master key Kij. This has the same benefit as before, namely it avoids over-exposing the master key, since it is advantageous to maintain the master key 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 master keys (the key Kij) and traffic encryption keys (packet encryption key Kp), the SKIP scheme makes it possible to automatically update traffic encryption keys even when relying on manual master key distribution. 1.3 Zero-Message Master Key Update Algorithm The implicit pairwise master keys in the previous sections can be used to generate an arbitrary number of implicit master keys, by making the master keys be a function of a counter, which is denoted as "n". The counter value n is only incremented and never decremented. It is used to prevent re-use of compromised traffic authentication keys as well as to provide coarse-grain playback protection of data traffic. In the event that a particular traffic authentication key is compromised (for whatever reason) its re-use is prevented by updating the implicit master key Kij and by never re-using a master key. This counter can easily be constructed in a stateless manner as the number of time-units since an agreed upon start time. The time units can be fairly coarse, such as hours. This only requires loosely synchronized clocks to within an hour. Such coarse grain synchronization is required in any case for any scheme that uses public key certificates, in order to check certificate validity information. Recommended time units/counter update frequency and the agreed upon start time is specified later in the document. Once the counter has moved forward, and after a short grace period to allow traffic in transit to be received, packets encrypted with the help of counter values earlier than n MUST be rejected. draft-ietf-ipsec-skip-02.txt [Page 8] INTERNET-DRAFT SKIP September 28, 1995 This counter value is passed in the field labeled "n" following the version and processing mode bits of the SKIP header described later. 1.3.1 Zero Message Master key Update with Diffie-Hellman The n'th level implicit key (which we denote as Kijn) is derived using the following function: Kijn = g^ijn mod p Implementation note: The n'th value g^ijn mod p is computable from the (n-1)th value as (g^ij(n-1) mod p)*(g^ij mod p) by performing only a single multiplication at each step. This can be significantly faster than performing the exponentiation (g^ij mod p)^n mod p at each step. 1.3.2 Zero Message Master Key update with Manual Keying As before, n can be computed as the difference between an agreed upon start time (specified later in this document) and the current time. Then, the n'th master key is generated using the following function: Kijn = h(Kij, n, 1) | h(Kij, n, 0) where h() is a pseudo-random, one-way hash function, for example, MD5 [13]. For this version of SKIP, the one-way function MUST be MD5. The "|" represents concatenation. The low order bits of this operation are used for Kijn. 1.4 Independence from Cryptographic Algorithms Although the descriptions above have been presented using the cryptographic constructions of classic Diffie-Hellman (exponentiations over a prime field) the protocols are completely generalizable to any public key agreement system. In this context a public key agreement system is defined as a system where one combines another's public and one's own private value to compute a pairwise shared secret. Here we distinguish between a public key agreement system and a public key cryptosystem which has the trapdoor property (for example, RSA). Examples of cryptographic constructions, other than exponentiation over a prime field, that can be used to provide the same public key agreement property are constructions that employ elliptic curves over finite fields and schemes that utilize exponentiation using composite moduli. draft-ietf-ipsec-skip-02.txt [Page 9] INTERNET-DRAFT SKIP September 28, 1995 Essentially, all aspects of the key-management protocol described above can be generalized to public and private values of the public key agreement type. This includes the master key update algorithm described in the previous section. We describe this using an abstract description of a public key agreement system as follows. We define Public_Key_Agree() as a cryptographic function that takes two inputs, one public and one private to generate a mutually shared secret. We let secret_i and public_i refer to the private and public values respectively of principal I, and secret_j and public_j refer to the private and public values respectively of principal J. The pairwise mutually shared secret between I and J is denoted shared_secret_ij. The master key Kij is derived from the shared_secret_ij by taking the low-order keysize bits of shared_secret_ij. A public key agreement function is then defined as: shared_secret_ij = Public_Key_Agree(secret_i, public_j) = Public_Key_Agree(secret_j, public_i) Having described a key agreement algorithm in the abstract form given above, the master key update algorithm described in the specific context of classic Diffie-Hellman above can be specified using the same form in a manner independent of the cryptographic construction as follows, shared_secret_ijn = Public_Key_Agree(n, shared_secret_ij) Kijn is derived from shared_secret_ijn. As before, from an implementation perspective, it may be faster to utilize the (n-1)th value of the shared secret in order to compute the n'th value of the shared secret. The public key agreement algorithm is specified by the algorithm identifier used to identify the public key in the public key certificate or equivalent mechanism (e.g. secure DNS). 1.5 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. Such draft-ietf-ipsec-skip-02.txt [Page 10] INTERNET-DRAFT SKIP September 28, 1995 devices can be in the form of tamper-proof smart cards, PCMCIA devices, and so on. A full discussion of system-level protection of cryptographic keys, while an important issue, is beyond the scope of this document. 1.6 SKIP for High Availability and Load Balancing Since the SKIP protocol as described above is completely stateless, it is straightforward to construct highly-available and load-balanced protected IP configurations. For a redundant configuration, a site configures itself with multiple intermediate nodes that share the same long-term Diffie-Hellman secret (and thereby public) value. These nodes may all have different IP addresses, as long as the receiver master key-ID is the same, since that is what is used to identify the master keys. Note: it is far easier and simpler to configure a set of nodes to share the same long-term secret, than it is to dynamically share transient session keys between a set of nodes. Once a set of nodes share the same long-term secret, they can act naturally in a redundant highly available and load balanced configuration for encrypted/authenticated IP traffic. The standard dynamic IP routing facilities provide for high-availability and load- balancing. No new protocol is required in order to achieve these goals. Should one of these routers (or their associated network links) fail, IP will automatically route packets through the remaining set of nodes, and these re-routed IP packets will remain decryptable by the other members of the redundant set. There is no limit to the number of nodes/links that can be configured in such a redundant configuration. Thus high-availability and load-balancing simply fall out from the basic stateless SKIP design, without requiring an additional (and complex) set of protocols to deal with these issues. 1.7 Attacks that the protocol guards against It is not possible to list all possible attacks on a cryptographic protocol in a short space. Instead we describe a well known category of attacks on cryptographic protocols, and show how SKIP resists those attacks. draft-ietf-ipsec-skip-02.txt [Page 11] INTERNET-DRAFT SKIP September 28, 1995 1.7.1 Intruder in the Middle Attacks 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 authenticated. 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 (for example, RSA signatures). 1.7.2 Known Key Attacks If the in-band traffic keys Kp used for packet authentication are ever compromised, then the master key update algorithm described above precludes the re-use of compromised keys to send forged traffic. This is because even if a particular traffic key Kp is compromised, this does not tell an attacker anything about the current implicit key Kijn, and therefore the attacker would not be able to compute the encryption of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an attacker cannot re-use past compromised keys Kp to any advantage. Also, knowing any number of past keys Kp does not help an attacker learn any other Kp, since knowing any number of Kp keys does not allow an attacker to learn Kijn. Knowing or even choosing Kp keys, and using that to learn Kijn is equivalent to a known or chosen plain-text attack on Kijn, and that should be infeasible even given a very large number of known/chosen Kp keys as long as the key-encryption algorithm is immune to a chosen text attack, which will always be the case. Thus SKIP is immune to known or chosen key attacks of this variety. 1.7.3 Anti-Clogging Defense An attacker may attempt to mount a denial-of-service attack on a node implementing SKIP, by trying to force it to perform an unacceptably high number of computationally expensive operations, e.g. the Diffie-Hellman computation. draft-ietf-ipsec-skip-02.txt [Page 12] INTERNET-DRAFT SKIP September 28, 1995 In order to prevent denial-of-service attacks on the SKIP scheme described above, a recommended solution is to pre-compute and cache master keys Kij, based either on usage patterns of the machine or through administrative action. In case a clogging attack occurs, the IP node will still be able to communicate with the set of machines for which it has pre-computed master keys, it will simply stop computing new master keys. This allows business as usual activities to carry on, even while a clogging attack occurs, since there are no computationally expensive (e.g. public key) operations required to key or re-key with an IP node once the master key Kij has been computed. The keys belonging to administrator's SHOULD always be in the pre- compute cache used to prevent this form of denial-of-service attack. This allows the administrator to securely add more nodes to the pre- compute cache, even during a clogging attack. 1.7.4 Non-Goal: Perfect Forward Secrecy Although perfect forward secrecy as described in [3], is a desirable and appealing goal for a key-distribution protocol, there are no known practical and scalable techniques for achieving perfect forward secrecy for a stateless message based protocol. Here a message based protocol is contrasted with a stateful session based protocol. Common examples of message based protocols include secure e-mail protocols such as PEM and PGP. There are no known techniques for providing perfect forward secrecy of encrypted data for these message based protocols. In support of dynamic IP routing, IP is more accurately modeled as a message based protocol. For these reasons, SKIP does not attempt to provide perfect forward secrecy of encrypted IP traffic. Only a stateful session oriented key distribution protocol can provide perfect forward secrecy, but such a scheme breaks the basic properties of IP as noted above, vastly complicating (or making impossible) highly available and load-balanced protected IP configurations. 1.8 Naming, Name Spaces and Master Key-IDs SKIP uses two bits (S and R) in the SKIP header to indicate that Master Key-IDs will be used for looking up authenticated public keys instead of the source and/or destination IP addresses. Master Key-IDs effectively decouple the identification of a master key for purposes of key lookup and access control from issues of network topology, routing and IP addressing. As one example, this allows IP draft-ietf-ipsec-skip-02.txt [Page 13] INTERNET-DRAFT SKIP September 28, 1995 nodes to use different IP addresses for routing and key lookup purposes. More importantly, it allows non-IP entities, such as individual users etc., to be identified using whatever name space is being used for them. SKIP permits multiple name spaces to be used by using the "N" bit in the SKIP header. The "N" bit is used to identify a name space for a Master Key ID. If the "N" bit is set, the next two bytes in the SKIP header contain two Name Space Identifiers (NSIDs). The first NSID byte refers to the name space of the source Master Key-ID, and the second NSID refers to the name space of the receiver Master Key-ID. The length of the Master Key ID is implicit in the choice of the NSID. There are two possible lengths, 32 bits and 128 bits. A 32 bit name space identifier may be used to identify, e.g., IPv4 addresses. A 128 bit identifier may be used to refer to an IPv6 address. The 128-bit Master Key-ID format also allows many different name spaces (up to 256) to be used with SKIP, by letting the Master Key-ID be the message digest of the name in its native name space. Examples of name or identifier spaces that can be accommodated in this manner are DNS names, ISO Distinguished Names, U.S. Social Security numbers, Credit Card numbers, Bank Account numbers etc. Although some of these name spaces have associated privacy concerns (e.g. social security numbers, credit card numbers etc.), these sensitive values would not actually be disclosed, since message-digests are one-way functions. Commonly used message digests have a 128-bit output, and this provides a compact and private way of carrying this identification information in a packet header. It is also possible for this identifier to be the message digest of the public key of a principal, since some principals may wish to be known by their public keys alone. If the public key is used as an identification mechanism, it simplifies the distribution of authenticated public keys, since there is an algorithmic and cryptographic binding between a name and its public key. This is the same purpose that certificates serve, so this can potentially simplify the distribution of public keys in communities that choose this naming mechanism, because it eliminates the need for a third party (e.g. a Certifying Authority, a secure directory server etc.) to ensure a secure binding between a name and a public key. There is a separate NSID byte for sender and receiver, so it is possible for entities identified using different name spaces to communicate as long as the two parties can understand both name spaces. draft-ietf-ipsec-skip-02.txt [Page 14] INTERNET-DRAFT SKIP September 28, 1995 Principals in the network will need to be able to reverse lookup a certificate (or equivalent information) using the Master Key ID. There are no security issues in the binding between a name in its native name space, and the message digest derived Master Key ID, since there is a cryptographic binding between two. The collision resistance property of a message digest function provides this security. Therefore reverse- lookup is primarily a database issue, and not a secure binding issue. If the "N" bit is zero, i.e. there are no name space identifiers present, the Master Key-ID is a 32 bit identifier for SKIP encapsulated in IPv4 and a 128 bit identifier for SKIP in encapsulated in IPv6. In this case, the Master Key-IDs default to IPv4 and IPv6 addresses respectively. Although a Master Key-ID may be allocated out of the IPv4/v6 address spaces, it is never used for IP routing purposes. Instead, it is used as a semi-permanent identifier for a master key. To illustrate one possible user, this decoupling allows, nodes to move around on the network, and come in from dynamically assigned IP addresses (using, for example, the DHCP protocol) and still have access control and Diffie-Hellman public key lookup occur based on the semi- permanent Master Key-IDs. Still other examples include mobile users, identified in any name space, who can securely access network data and services from many different IP nodes. This is because keys will be looked up based on their native names, and not the IP address of the node from which they are performing the network access. These users may carry around their private keys in smart cards, or alternatively, these private keys may be distributed over the network encrypted in a per-user password. Users may be identified using their DNS names, POSIX/XOPEN user ids, X.500 Distinguished Names etc. Similarly Receiver Master Key-IDs can serve many purposes as well. When the Receiver Master Key-ID refers to an IP address, it can be used to pass end-to-end SKIP packets through an encrypting intermediate node. Without a receiver Master Key-ID, an intermediate node which is encrypting/decrypting SKIP packets for multiple machines would have no way of knowing whether a received packet should be uncompressed/decrypted/authenticated or just forwarded. A receiver Master Key-ID enables an encrypting intermediate node (for example, router or firewall) to determine whether to process a packet or simply forward it. The receiver Master Key-ID is present when the "R" bit is set. draft-ietf-ipsec-skip-02.txt [Page 15] INTERNET-DRAFT SKIP September 28, 1995 On an end node, the Receiver Master Key-ID can be used to distinguish between multiple users on the same IP node, in case the Receiver Master Key-ID is not allocated from the IP address space. If the "S" bit is set, the sender Master Key-ID MUST be used for lookups and the source IP address MUST NOT be used. If the "R" bit is set, the receiver Master Key-ID MUST be used for authenticated public key lookups and the destination IP address MUST NOT be used. Note: a receiving node MUST process a packet if the receiver Master Key-ID in the packet matches a local Master Key-ID, even if the destination IP address does not match. Also, a node MUST NOT process a packet which has a receiver Master Key-ID that does not match a local Master Key-ID even if the destination IP address matches. Some commonly used name spaces have been assigned NSIDs. These are described in the "Assigned Numbers" section below. More name spaces will be registered through IANA. 1.8.1 The SKIP Header A SKIP header communicates the in-band keying, algorithms and next protocol used on the packet. The SKIP header is illustrated below. Fields are transmitted left to right. draft-ietf-ipsec-skip-02.txt [Page 16] INTERNET-DRAFT SKIP September 28, 1995 SKIP Header 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 |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Alg | Kp Alg | MAC Alg | COMP Alg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kijn... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Master Key-ID (If S bit is set.. typically 4/16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Master Key-ID (If R bit is set.. typically 4/16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first field of the SKIP header is the Version (Ver). The protocol described in this document is 1. The C bit is used to indicate that the packet is compressed before encryption. The S bit indicates that a packet contains a sender Master Key-ID. The R bit indicates a packet contains a receiver Master Key-ID. The N bit indicates that a Source and Destination NSID bytes are present. Only if the "N" bit is set to 1 will the Source and Destination NSID bytes be examined. As described above, these identify the sender's and receiver's name spaces respectively. Following the NSID bytes in the SKIP header, the NEXT HEADER field is used to indicate which protocol follows the SKIP header. This field will usually indicate ESP or AH. But the NEXT HEADER may be any protocol which requires keying material. Examples of protocols other than AH/ESP that may use SKIP are given below. The "Counter n" field is a 32 bit field which is used for coarse grain playback protection and to prevent compromised key re-use. The 1 byte field, Kij algorithm identifies the algorithm used to encrypt Kp. This algorithm always takes the low order bits of Kij as the key to encrypt/decrypt Kp. draft-ietf-ipsec-skip-02.txt [Page 17] INTERNET-DRAFT SKIP September 28, 1995 The Kij algorithm MUST be a block cipher algorithm. It is always used in CBC mode to encrypt Kp, which is a variable number of bits. The IV for the CBC mode encryption MUST always be set to all zeros (IV=0). So, e.g., for 64-bit IV algorithms, such as DES-CBC, the IV is 64 bits of zero (0). The input to the key encryption algorithm is padded with a random fill up to a multiple of the block size of the key-encryption algorithm. The length of Kp is derived from knowledge of the encryption/MAC algorithms. The low order key-length bits of the decrypted output are used as Kp. The Kp Alg and MAC Alg specify algorithms used by the interior protocol for encryption and authentication. These algorithms are specific to the protocol which will use them and the transforms it specifies. In general, the MAC Alg specifies the algorithm used to calculate a MAC and the Kp Alg specifies the algorithm used to encrypt the packet. This is not an absolute, however. For instance, it is possible to have a Kp algorithm which provides encryption and MAC computation. This is further described in a later section. The Comp Alg field specifies the algorithm that was used to compress packets prior to encryption/authentication. This field is only used when the "C" bit is set. The values for the algorithm fields will be described later in this document. The field "Kp Encrypted in Kij" is the encrypted Kp which has been encrypted using the Kij algorithm. The sender Master Key-ID field contains the Master Key-ID of the sender. This field is only present if the "S" bit has been set. The receiver Master Key-ID field contains the Key-ID of the intended receiver. This field is only present if the "R" bit has been set. 1.8.2 The relative order of compression, encryption and authentication The protocol allows three potential transforms to be performed, namely compression, encryption and authentication. The order in which these transforms are performed is very important. It is desirable for encryption to follow compression, because encrypted data is not (generally) compressible. Authentication must follow encryption and/or compression because it is unknown whether transforming a MAC using either encryption or compression results in a valid MAC. draft-ietf-ipsec-skip-02.txt [Page 18] INTERNET-DRAFT SKIP September 28, 1995 Therefore SKIP compliant implementations MUST use the following order. For outgoing IP packets, a) IF compression is to be performed then the data is first compressed b) and IF encryption is to be performed, then the output of step a) is encrypted, c) and IF authentication is to be performed, then the output of step b) is authenticated. If, for example, all three transforms are being performed, then first data gets compressed, compressed data gets encrypted, and the compressed-encrypted data is authenticated. Received packets will naturally be transformed using the reverse order. If authentication is being used then the packets will be checked for authenticity first. Only if the packets pass the authentication phase will they be decrypted if encryption was performed, and then decompressed if compression was performed. 1.9 SKIP for Authentication Note: Packet authentication and packet integrity are used interchangeably in this document, since there is no meaningful cryptographic distinction between the two. In order to achieve authentication in the absence of privacy, SKIP compliant implementations use the packet key Kp to compute a Message Authentication Code (MAC) over the packet and invariant clear header fields. The MAC Alg field in the SKIP header MUST be used to lookup a specific transform. The packet key Kp is used as a key to compute a MAC using, for example, Keyed MD5. The MAC is inserted into the encapsulated protocol in whatever way the encapsulated protocol defines. As always, Kij Alg identifies the encryption algorithm used to encrypt Kp. 1.9.1 SKIP with AH The AH Protocol [ RFC 1826 ] is used to provide authentication for IP datagrams. An example of the protocol encoding for SKIP followed by an AH header is shown below. draft-ietf-ipsec-skip-02.txt [Page 19] INTERNET-DRAFT SKIP September 28, 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 |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER=AH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Alg | RESERVED | MAC Alg | COMP Alg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kijn... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SKIP_SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable Length +---------------+---------------+ The SPI field in the AH header is filled with SKIP_SPI to indicate that keying material and algorithm information is present in the preceding SKIP header. The authentication data and location of the computed MAC is defined by the specific transforms. See, e.g., RFC 1828 [14], as an example of an authentication transform. 1.9.2 Scope of MAC computation The scope of the MAC computation is the entire packet, including the outer clear 20-byte IP header with all of the variant fields treated as zero for the purposes of the computation, followed by the SKIP header, followed by AH header, and finally, the payload of the SKIP packet. The payload is either a clear payload, if authentication-only is being performed, or it is an ESP header and encrypted payload. The only fields that are non-zero for the purposes of the MAC computation in the 20-byte outer IP header are: 1) 4-bit IP version number, 2) 16-bit ID field, 3) the two 32-bit source and destination IP addresses, and 4) the 8-bit protocol field. All other fields of the 20- byte IP header are treated as zero. All IP options other than IPSO are ignored for the purposes of the MAC computation. The intent is to ignore any fields that may potentially be draft-ietf-ipsec-skip-02.txt [Page 20] INTERNET-DRAFT SKIP September 28, 1995 changed in transit by routers. 1.10 SKIP for Encryption When SKIP is used to supply keying material for encryption only, the Kp algorithm indicates packet encryption algorithm. Kp will be used as a key to the Kp algorithm. The Kp algorithm will be mapped to standard transforms such as RFC 1829. These transforms will also contain information such as Initialization Vectors or Message Indicators. As always, Kij Alg identifies the encryption algorithm used to encrypt Kp. 1.10.1 SKIP with ESP An example of use of SKIP for encryption is SKIP combined with the ESP protocol [RFC 1827]. The ESP protocol can be used to provide confidentiality of entire IP datagrams or the payload of IP datagrams, depending on whether ESP is operating in tunnel or transport mode respectively. An example of SKIP combined with ESP is illustrated 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 = SKIP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER=ESP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Alg | Kp Alg | RESERVED | COMP Alg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kijn... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI=SKIP_SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Transform Data, variable Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The reserved SPI SKIP_SPI in the ESP header indicates that algorithm information and keying material is contained in the preceding SKIP header. We assume that this reserved SPI has been assigned symbolic draft-ietf-ipsec-skip-02.txt [Page 21] INTERNET-DRAFT SKIP September 28, 1995 value SKIP_SPI. The SKIP_SPI value is specified later in this document. The Opaque transform data is defined by the particular transform (such as DES-CBC in RFC 1827). This data will normally contain the encrypted data and transform specific information such as the IV. Kij Alg identifies the encryption algorithm used to encrypt Kp. Kp is used as a key to the Kp algorithm which is used to encrypt the payload. 1.11 SKIP for Packet Encryption and Authentication Packets may be both encrypted and authenticated. An important issue when performing both authentication and encryption is key separation. Namely, the authentication and encryption keys MUST be different. This allows, for example, encryption keys to be short (possibly to satisfy export control laws) while keeping the authentication key as long as necessary. Furthermore, it MUST be infeasible to derive either one of the authentication key or the encryption key, should one of them be compromised. This is accomplished as follows. The Kp that is decrypted from the packet header is not used directly to encrypt/decrypt or authenticate the packet. Rather, it is used to derive two separate keys named E_kp and A_kp, where A_kp is used as the authentication key and E_kp is used as the encryption key. E_kp and A_kp are related to the Kp decrypted from the packet header as follows: E_kp = h(Kp, 1, Kp) | h(Kp, 0, Kp) A_kp = h(Kp, 3, Kp) | h(Kp, 2, Kp) where h() is a pseudo-random, one-way hash function, for example, MD5. For this version of SKIP, the one-way function MUST be MD5. The "|" above specifies concatenation. The construction above has the property that knowing either one of E_kp or A_kp does not compromise any information about the other key, because of the one-way property of MD5. This allows, e.g., weak encryption keys to be used with strong authentication keys. Should E_kp be compromised, nothing at all is revealed about A_kp, and vice versa. The actual number of key bits used is algorithm dependent. If the algorithms require less than 256 bits, then the low order key-size bits of the output of the pseudo-random one-way functions are used as the actual keys. If less than 128 bits of encryption key is required, then only the h(Kp, 0, Kp) function needs to be computed, because this provides the low order 128 bits of E_kp. Similarly, if only 128 bits or draft-ietf-ipsec-skip-02.txt [Page 22] INTERNET-DRAFT SKIP September 28, 1995 less are required for the authentication key A_kp, only the h(Kp, 2, Kp) function needs to be computed. When using MD5, the function specified above provides a total of 256 bits, which is a sufficient number of key bits for the expected encryption and authentication algorithms that will be used with SKIP. An implementation will use the maximum of the key-lengths indicated by Kp Alg and MAC Alg when determining the length of the actual Kp that will be decrypted from the SKIP header. For example, if Kp algorithm specifies a 40-bit encryption key length, the MAC algorithm specifies a 128-bit authentication key length, then the length of Kp will be 128 bits. This 128-bit Kp will be input to the functions specified above to generate E_kp, which will be low-order 40-bits of the E_kp function, and A_kp, which will be low-order 128 bits of the A_kp function. The length of the Encrypted Kp in the packet header is derived from the length of Kp and the key encryption algorithm, as indicated by Kij Alg. For example, if the length of Kp as discussed above turns out to be, say, 120 bits, and the key encryption algorithm (as specified by Kij Alg) is a 64-bit block cipher, then the length of the encrypted Kp in the SKIP header will be 128 bits, of which the upper 8 bits will be random fill. The random fill bits MUST be ignored for the E_kp and A_kp computation functions. Implementation Note: It is not necessary to perform a complicated set of conditional rules in order to determine the length of the encrypted Kp in an implementation of SKIP. A fast and simple way of doing this is to have a table indexed by the algorithm number, which produces the key lengths required for that algorithm. Since this table will be small enough to fit in most caches, this can result in a fast way to determine the appropriate encrypted key length in order to perform SKIP header decoding. A SKIP implementation will know when to perform the key separation procedure specified above by presence of non-zero values in both the Kp Alg identifier and the MAC Alg identifier. This indicates that both encryption and authentication are taking place, and therefore separate keys need to be computed. The other important issue when performing both authentication and encryption is the order of the two operations. For sending, SKIP compliant implementations MUST first encrypt the packet using E_kp as the encryption key, and then compute the MAC over the encrypted packet and invariant clear header fields using A_kp as the authentication key. draft-ietf-ipsec-skip-02.txt [Page 23] INTERNET-DRAFT SKIP September 28, 1995 Receiving IP nodes will use the reverse process. They will first authenticate the packet using A_kp, and only if it authenticates will the receiving IP node attempt to decrypt the packet using E_kp. If a packet fails to authenticate, the receiving IP node MUST discard that packet. Any protocol which uses both authentication and encryption MUST use this key separation algorithm. When performing encryption without authentication, or authentication without encryption, then key bits are directly derived from Kp, without using the key separation functions described above. 1.11.1 SKIP with AH and ESP SKIP combines naturally with AH and ESP. The Next protocol field in the SKIP header would be AH and the Next protocol field in AH header would ESP. A_Kp would be used for authentication and E_kp (as discussed in the previous section) would be used for encryption. The following is an example of SKIP with AH and ESP. In Addition, the use of Master Key-ID's is also demonstrated. draft-ietf-ipsec-skip-02.txt [Page 24] INTERNET-DRAFT SKIP September 28, 1995 SKIP Header 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 |C|1|1|N| Source NSID | Dest NSID |NEXT HEADER=AH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Alg | Kp Alg | MAC ALG | COMP Alg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in Kijn... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Master Key-ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Master Key-ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next=ESP | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SKIP_SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length AH MAC, computed using A_kp +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SKIP_SPI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP payload encrypted using E_kp (including IV and data) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits S and R have been set to 1 to support Master Key-IDs. All 32-bit quantities are transmitted in network order. 1.11.2 SKIP with combined ESP transforms For ESP transforms which combine encryption and authentication (for instance: Keyed MD5 with DES-CBC), only an ESP header is needed. The Kp algorithm in the SKIP header will indicate the transform and A_kp would be used for authentication and the E_kp (as discussed in a previous section) would be used for encryption. draft-ietf-ipsec-skip-02.txt [Page 25] INTERNET-DRAFT SKIP September 28, 1995 Since a SKIP implementation has to unambiguously distinguish between when authentication and encryption are both being taking place in order to perform key separation, the MAC field MUST contain the same algorithm identifier as the Kp algorithm identifier. Since this algorithm identifier will indicate a combined encryption/authentication transform for ESP, setting both fields to non-zero values unambiguously indicates that both encryption and authentication are taking place. 1.12 Generic use of SKIP header The SKIP header may be used for any protocol which requires keying material. The next header in the SKIP header would specify this protocol. A protocol being encapsulated SHOULD have a reserved value which indicates that the keying material to be used is in the SKIP header. An example of this kind of reserved value is SKIP_SPI which is used by the AH and ESP protocols. The protocol will define how the Kp, MAC and Compression algorithms will be used. Kijn will be used to encrypt Kp. In particular it is possible to pass SKIP in the payload of of a TCP/UDP packet. This allows the key-management and encryption/authentication to be performed in the application protocol (above TCP/UDP), and there may be times where it is advantageous to do so. 2. SKIP for Multicast IP 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 these multicast addresses. 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. An example of this is 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. draft-ietf-ipsec-skip-02.txt [Page 26] INTERNET-DRAFT SKIP September 28, 1995 2.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. 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 Kijn 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 pairwise secure protocol described in Section 1 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 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 # 2000. It is sent to the group owner's unicast IP address. draft-ietf-ipsec-skip-02.txt [Page 27] INTERNET-DRAFT SKIP September 28, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 TCP/UDP port # 2001 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. 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 | Kg Alg id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Multicast Address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry time (low 32-bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry time (high 32-bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recommended Key Change Interval (in seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recommended Key Change Interval (in bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kg .... (length dependent on Kg Alg) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 64-bit expiry time specifies when the multicast key is considered to have expired. This is in terms of seconds since, 0h Jan 1, 1900, 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 draft-ietf-ipsec-skip-02.txt [Page 28] INTERNET-DRAFT SKIP September 28, 1995 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. 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 pairwise keys Kijn, but instead are encrypted using the GIK Kg. An example encrypted multicast packet using ESP for packet encryption, 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 = SKIP... (typically 20-bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n=1 (unused) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved. | Kp Alg | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | Kp encrypted in GIK Kg... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI=SKIP_SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Kg to decrypt the packet encryption key Kp. An implementation of this protocol will use the destination IP multicast address to lookup the GIK Kg. draft-ietf-ipsec-skip-02.txt [Page 29] INTERNET-DRAFT SKIP September 28, 1995 There are two distinct advantages of this scheme. First, every member of the multicast group can update 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, 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. 2.2 SKIP for 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 GIK is permanent and has no expiry date and may be manually distributed between authorized members of the group (multicast or broadcast). The GIK is updated for the permanent multicast or broadcast group using the zero-message master key update procedure described in section 1 above for manually distributed master keys. Instead of using Kij as the input to generating the n'th master key Kijn, the manually distributed GIK shall be used to generate the n'th level GIK, and labeled GIKn. 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. To precisely define the master key update procedure in the context of broadcast/permanent multicast groups: GIKn = h(GIK, n, 1) | h(GIK, n, 0) where h() is a pseudo-random, one-way hash function, for example, 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 GIKn. GIKn is then used to encrypt packet keys, analogous to how packet keys are protected for unicast IP using Kijn. draft-ietf-ipsec-skip-02.txt [Page 30] INTERNET-DRAFT SKIP September 28, 1995 It is worth noting that all members of a group are considered equivalent from the point of view of multicast/broadcast authentication. There are no practical and efficient techniques to achieve multicast/broadcast authentication, where the authentication mechanism distinguishes between members of the same multicast group. Digital signatures is a technology that may be used for broadcast authentication, except all known signature techniques are too computationally expensive to be performed on a per packet basis. 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 in a completely scalable manner, using the procedures described above. 2.2.1 SKIP and RIPv2 As an example of both how SKIP can be used to supply keys for protocols other than AH/ESP, and use of SKIP 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. Since RIP is a broadcast protocol, keying semantics are different than with unicast. Please see the previous section on broadcast and fixed permanent multicast groups. draft-ietf-ipsec-skip-02.txt [Page 31] INTERNET-DRAFT SKIP September 28, 1995 The following is an example of SKIP combined with RIP V2. 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 |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER=RIP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Alg | RESERVED | MAC Alg | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp encrypted in GIKn ... (typically 8-16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RIP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Version | Routing Domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family=0xFFFF | Authentication Type=SKIP_AUTH| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AUTHENTICATION (MAC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ....Authenticated RIP Entries +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here the packet authentication keys are encrypted using GIKn, which is computed using procedures described in the preceding section. This use of SKIP to supply keys for non AH/ESP protocols is intended to be illustrative, and not exclusive. Other protocols can similarly be used with SKIP, either in the context of unicast, or transient/permanent multicast and broadcast group communications. 3. Algorithm Discovery An optional protocol is described for discovering the appropriate algorithms to use for various packet transformations, such as encryption, authentication, compression etc. Algorithm discovery is in many ways analogous to algorithm negotiation in conventional session oriented key setup. However, "negotiation" is a misnomer as applied to most existing protocols that accommodate this feature. This is because in essence there is no negotiation, simply a statement of capabilities draft-ietf-ipsec-skip-02.txt [Page 32] INTERNET-DRAFT SKIP September 28, 1995 on both sides. The sides agree to pick a common subset of their capabilities. SKIP allows the same statement of capabilities to occur in a stateless manner, entirely analogous to how the IP protocol performs path MTU discovery. A SKIP implementation is free to choose a set of algorithms with a particular node. If it chooses incorrectly, it will discover this through an authenticated ICMP message, which is in effect a statement of capabilities and preferences for that node. RFC 1825 requires that Keyed MD5 for authentication and DES-CBC for encryption are mandatory. The ICMP message is authenticated using this default authentication algorithm, which MUST be supported by all SKIP nodes that support this optional ICMP protocol. If a node receives a SKIP packet which specifies algorithms it does not support, it will send an authenticated ICMP message indicating this failure and specifying which algorithms it supports. The ICMP Packet MUST be encapsulated in AH with keyed MD5 used as the algorithm. Any received algorithm discovery ICMP message that is not authenticated MUST be ignored. draft-ietf-ipsec-skip-02.txt [Page 33] INTERNET-DRAFT SKIP September 28, 1995 The Algorithm discovery ICMP message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE=SKIP_ICMP| CODE | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nKij | nKp | nmac | ncomp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n update Frequency (in seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expected n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kij Algorithms (0-255), 1 byte each +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kp Algorithms (0-255), 1 byte each +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Algorithms (0-255), 1 byte each +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compression Algorithms (0-255), 1 byte each +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CODE should be interpreted as a bit field in the following way: 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |I|P|M|C|N| res | +-+-+-+-+-+-+-+-+ I is set if the Kij algorithm in the SKIP packet is unsupported. P is set if the Kp algorithm in the SKIP packet is unsupported. M is set if the MAC algorithm in the SKIP packet is unsupported. C is set if the compression algorithm in the SKIP packet is unsupported. N is set if an invalid n counter was sent in the packet bits 0-2 are reserved and should be set to 0. The ICMP type field SKIP_ICMP is specified later in this document. The time field, Current Time, is set to the system's concept of current time in seconds since 0h Jan 1, 1900. This is identical to the Integer portion of the NTP timestamp. draft-ietf-ipsec-skip-02.txt [Page 34] INTERNET-DRAFT SKIP September 28, 1995 The field "n update Frequency" is set with the value representing the number of seconds between increments of the n counter. For example, if the n counter is updated once an hour, this field would contain 3600. The nKij, nKp, nmac and ncomp fields should be filled in with the number of Kij, Kp, MAC and Compression algorithms the system supports, respectively. The Kij, Kp, MAC and Compression algorithms fields should be filled in sequentially with the one byte identifiers for each of the algorithms that the system supports. The algorithms should be an ordered list with the most desirable algorithms first and the least desirable last. For instance, if the system supports 5 Kij algorithms, nKij would be set to 5 and the Kij Algorithms field would be 5 bytes long (one byte for each algorithm supported). A host may force an ICMP message by sending a SKIP packet to the remote host with either the Kij or Kp algorithms set to zero. The compression algorithm may be set to 0 as well, but only if the "C" bit has been set. 4. Distribution of authenticated public keys As mentioned earlier, a variety of mechanisms can be employed to distribute authenticated public keys, such as, X.509 certificates, PGP certificates and Secure DNS resource records to name a few. 4.1 X.509 encoding of DH public values draft-ietf-ipsec-skip-02.txt [Page 35] INTERNET-DRAFT SKIP September 28, 1995 The X.509 certificate format is defined by the following ASN.1 syntax: Certificate ::= SIGNED SEQUENCE { version [0] Version DEFAULT v1988, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo } Version ::= INTEGER { v1988(0) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } The encoding of a Diffie-Hellman 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, draft-ietf-ipsec-skip-02.txt [Page 36] INTERNET-DRAFT SKIP September 28, 1995 DHPublicKey ::= INTEGER 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 } The DHPublicKey gets encapsulated as the BIT STRING in 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. 4.2 Encoding of the Distinguished Name (DN) When the name space is the IP address space, a 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 ub-ipAddress ::= 256 The DN in the certificate can contain multiple of these by iterating on the SEQUENCE-OF construct of the Relative Distinguished Name Sequence. draft-ietf-ipsec-skip-02.txt [Page 37] INTERNET-DRAFT SKIP September 28, 1995 The PrintableString contains either the hexadecimal representation or standard dot notation representation of an IP address. When individual users are identified using Distinguished Names, then the DN in the certificate naturally contains their DNs. Section 1 above describes how DNs may be used with SKIP, by identifying the DN name space using the NSID bytes. 4.3 Certificate Discovery Protocol An optional protocol is described to enable communicating IP-nodes to discover each other's certificate(s). This obviates the need for an on- line certificate directory server. A number of certificate types currently exist, for example, X.509, PGP and DNS-SIG. This protocol allows for all of these types. Also note, that a particular IP-node may have more than one certificate. A node could certainly have the same Diffie-Hellman public value in different certificate formats, or have multiple Diffie-Hellman public values each in a separate certificate or have the same Diffie-Hellman public value certified by different Certifying Authorities, and so on. In all these possible certificates the identity of the node remains constant. An algorithm for choosing a particular certificate (essentially a Diffie- Hellman public value) when more than one exist is described later. All certificate discovery protocol communication use the User Datagram Protocol (UDP). The initiator binds to port skip-cert-send (6456) and sends a certificate request to port skip-cert-recv (6455). The responder binds to port cert-recv-port and sends the response to port cert-send-port. Two separate ports are used to allow for multiple certificate requests to be made without waiting for the response to be received, (that means, one port is used to simply send requests out and the other port is used to receive responses). A simple cache of the Master Key-ID and the IP address to which the request was sent is all that is required to manage outstanding certificate requests. Implementation detail: Considering that a node may be pre-configured to allow only encrypted communication with any other node, a certificate request would be rejected. It is suggested that the two ports (cert- send-port and cert-recv-port) be treated as a "by-pass" channel for encryption. As only certificates requests are satisfied on these ports the window for vulnerability is limited. The certificate discovery packet: draft-ietf-ipsec-skip-02.txt [Page 38] INTERNET-DRAFT SKIP September 28, 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 | ACTION | STATUS |NUMBER-OF-CERTS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Master Key-ID of certificate(s) in packet ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | CERT-LENGTH | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | CERT-LENGTH | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VERSION = 1 in the context of specified ports. ACTION indicates the type of message. Possible values are: 1 (Request) - request for remote parties certificate(s). 2 (Reply) - response to a certificate request. STATUS is used only in responses (i.e. ACTION = 2). Possible values are: 0 (OK) - process the certificates sent. NUMBER-OF-CERTS must not be zero. 1 (Unknown Error) - an error has occurred. 2 (Unknown Master Key-ID) - no certificates for the requested Master Key-ID can be found in the local certificate database. NUMBER-OF-CERTS - if 0 then no certificates are present in the message and the message is simply a request for all certificates for the specified Master Key-ID or a response where the STATUS octet indicates an error. Note that this allows for the initiator to not only request for all certificates for a particular Key-ID but can also send in the same message all the certificates it has. As certificates have the subjects identity (i.e. specifies the certificate owner), this information does not have to be sent to other party. Master Key-ID - this is a 32 bit or a 128 bit identifier as described in the section on Master Key-IDs. CERT-TYPE specifies the certificate type of the certificate that is to follow. draft-ietf-ipsec-skip-02.txt [Page 39] INTERNET-DRAFT SKIP September 28, 1995 CERT-LENGTH specifies the length of the certificate in octets. CERTIFICATE - the actual certificate. The Certificate Discovery Protocol allows certificate requests to be made to any arbitrary IP-node. This feature allows the initiator to send requests to, say, an IP-node which is acting as a DNS or NFS server (and hence would have many certificates stored in its local certificate database). 4.4 Algorithm to determine which Diffie-Hellman public value to use There may be instances when an IP-node has more than one Diffie-Hellman public value, or also support other key agreement algorithms (for example, elliptic curves). In these situations the choice of the key agreement algorithm and/or the choice of public value to use is basically made by determining the fastest and the strongest algorithm/value respectively. For example, assume an IP-node I supports the Diffie-Hellman Key Agreement algorithm and has two certificates issued by the same CA but containing different public values. Assume that one certificate (cert512) has a 512 bit modulus and the other certificate (cert1024) has 1024 bit modulus. Now, it wishes to communicate with an IP-node J. IP- node J also uses Diffie-Hellman key agreement algorithm and has two certificates one of 512 bit modulus and other with 1024 bit modulus. The shared secret between the two nodes should be based on the stronger value, that means, the Kij is calculated using the public values with the 1024 bit modulus. 5. Assigned Numbers 5.1 SKIP protocol number SKIP has been assigned the protocol number 57 by IANA. This is what will be in the "protocol" field in the IP header, when the SKIP header follows the IP header. draft-ietf-ipsec-skip-02.txt [Page 40] INTERNET-DRAFT SKIP September 28, 1995 5.2 SKIP SPI value For use with the AH & ESP protocols, the value of 1 has been assigned by IANA for use with SKIP. Therefore SKIP_SPI as used in earlier sections should be treated as equal to 1. This will be the value used in the SPI fields of the AH & ESP protocols. 5.3 Name Space Identifier (NSID) Assignments Some of the name spaces that may be used with SKIP are assigned identifiers here. Other name space identifiers will be assigned by IANA. NSID Value Name Space Master Key ID length 0 IPv4 Address Space 32-bits 1 POSIX/XOPEN User Ids 32-bits 2 IPv6 Address Space 128-bits 3 MD5 of DNS Names 128-bits 4 MD5 of ISO DN ASN.1 encoding 128-bits 5 MD5 of U.S. Social Security # 128-bits 6 MD5 of Credit Card # 128-bits 7 MD5 of Principal's Public Key 128-bits 8 MD5 of RFC-822 Mailbox Address 128-bits 9 MD5 of Bank Account # 128-bits 10 MD5 of NIS Name 128-bits Only the IPv4 and IPv6 address spaces are used without transformation using MD5. All other names are hashed into 128-bits from their native name space encoding mechanism using the MD5 message digest algorithm. 5.4 Assigned Algorithm Numbers SKIP uses the following algorithms identifiers. Algorithm and type identifiers are specified for each place in the protocol where algorithm or type indicators are needed. These fall into five categories. Algorithms for key-encryption (Kij Alg), traffic encryption (Kp Alg), traffic authentication (MAC Alg), traffic compression (Comp. Alg) and certificate types used by the certificate discovery protocol. draft-ietf-ipsec-skip-02.txt [Page 41] INTERNET-DRAFT SKIP September 28, 1995 Key-Encryption Algorithms (Kij Alg) 1 DES-CBC (IV = 0, random fill upto multiple of 64-bits) 2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits) 3 IDEA-CBC (IV = 0, random fill upto multiple of 64-bits) Traffic Encryption Algorithms (Kp Alg) 1 DES-CBC (64-bit IV, padding ESP transform RFC 1829) 2 40-bit RC2-CBC (64-bit IV, PKCS # 5 padding algorithm) 3 40-bit RC4 (64-bit byte offset Message Indicator) 4 128-bit RC4 (64-bit byte offset Message Indicator) 5 2 key (k1, k2, k1) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81) 6 3 key (k1, k2, k3) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81) 7 IDEA-CBC (64-bit IV, padding according to PKCS #7, FIPS 81) 8 DES-CBC (64-bit IV, padding according to PKCS #7, FIPS 81) MAC Algorithms (MAC Alg) 1 128-bit Keyed MD5 (RFC 1828) 2 DES-CBC MAC Compression Algorithms (Comp Alg) Currently Unassigned Certificate Type (Cert Type) 1 X.509 2 PGP 3 Secure DNS IANA will assign the remaining algorithm identifiers. For interoperability purposes, RFCs 1828 and 1829 have been deemed as mandatory to implement. When implementing different key-encryption, traffic encryption, and key-agreement algorithms, a consistent set of key strengths MUST be chosen. This means that if a traffic key is, say 128 bits strength, then the key encryption key MUST be of strength 128-bits or greater. It isn't sensible to choose strong traffic protection algorithms and then encrypt the keys using weaker algorithms. Similarly, when using 128-bit symmetric keys, the modulus lengths for classic Diffie-Hellman (used to derive the master keys) MUST be 1024 bits or greater. The exponent size draft-ietf-ipsec-skip-02.txt [Page 42] INTERNET-DRAFT SKIP September 28, 1995 for classic Diffie-Hellman for symmetric master key sizes of 128 bits MUST be 256 bits or greater. For 64-bit master key sizes, the modulus length for classic Diffie- Hellman MUST be 512 bits or greater. The Diffie-Hellman exponent size for 64-bit master keys MUST be 128 bits or greater. Also, when 128-bit keyed MD5 is used, then the key-encryption algorithms MUST have strength equal to or greater than 128-bits. For interoperability purposes, use of Algorithm #2 (3 key triple DES-EDE- CBC) is deemed mandatory to implement for key encryption (Kij Alg), when also implementing keyed MD5 as specified in RFC 1829 for traffic authentication purposes, or any 128-bit strength traffic encryption algorithm (e.g. 2 or 3 key triple DES or IDEA). For each of the algorithm identifiers above, the range 250-255 will remain reserved for private use by cooperating entities. These values will not be assigned by IANA, and therefore will not have a globally unique meaning. They will only be used to implement proprietary algorithms by cooperating entities, and therefore will only have local uniqueness properties. 5.5 SKIP ICMP message (SKIP_ICMP) The SKIP algorithm discovery ICMP message has been assigned the type 39 (SKIP_ICMP) by IANA. 5.6 SKIP Certificate Discovery Protocol The SKIP Certificate Discovery Protocol uses two UDP ports to exchange certificates. "skip_cert_send" and "skip_cert_recv" have been assigned the values 6456, 6455 respectively by IANA. 6. Recommended Parameters and Implementation Notes 6.1 Generating Random Keys One of the most important considerations in a software only implementation of SKIP is to design an unpredictable pseudo-random number generation procedure. Weak and unpredictable sources of random number generation would be catastrophic to the security of SKIP or indeed any scheme that implements cryptography, no matter what the length of key and choice of encryption algorithm might be. draft-ietf-ipsec-skip-02.txt [Page 43] INTERNET-DRAFT SKIP September 28, 1995 In particular, common mistakes that MUST be avoided in implementing this unpredictable random number generator is to use values like the current process id, the host id or ethernet address, the current time of day or some simple combination of these as the sole input to generate a cryptographic key. These values are really not all that unpredictable. It must be ensured that there are at least as many truly random bits used in the key production phase as are specified in the chosen key length for that algorithm. None of these commonly used sources by themselves provide sufficiently many random bits for commonly used cryptographic algorithms. An algorithm that would be better would be one that utilizes a strong random seed, and then uses cryptographic primitives like pseudo-random one-way hash functions or encryption primitives to generate more pseudo-random bits. Timing many sources of asynchronous events, e.g. mouse clicks, keyboard input, packet arrival times, etc., with a conservative estimate of the number of true random bits derivable from each event (measured with the highest resolution clock available) is a recommended way of producing the random seed. One conservative estimate would be to extract 0.5 or less random bits from each such asynchronous event. Therefore MANY such events need to be processed before a truly random seed is available. This information can be further augmented with random user input in the form of many randomly chosen key-board characters. It is best to utilize as many different sources of random information as possible. When timing asynchronous events, it must be ensured that the timestamp code is as "close" to the event being timed as possible. Among other things, this means that the time-stamping program should have unbuffered access to the events. For example, if one is timing key-strokes, then the terminal must be in "raw" (or unbuffered) mode, and not buffered mode. Buffering the input will make what should be many independent asynchronous events into one event, because the time-stamps for many different events will become highly correlated. All this random information from timed asynchronous events etc. can be combined using a message digest function to produce a seed. This seed can then be used as one of the inputs to a cryptographically designed pseudo- random function, e.g. one that utilizes one-way message digest functions like MD5. It would be advisable to continuously add more true random bits to the pseudo-random number generation process, by fine- grain timing as many sources of asynchronous events as are available. draft-ietf-ipsec-skip-02.txt [Page 44] INTERNET-DRAFT SKIP September 28, 1995 Even if a hardware source of random bits is available, e.g. a noisy diode, it is still advisable to post-process the output of this hardware source using some of the cryptographic techniques described above. For more information on the subject of generating random keys, RFC 1750 [12] is recommended reading. 6.2 Key Update The best way to frustrate cryptanalysis of encryption and authentication keys is to periodically update the key used to encrypt or authenticate packets. Whereas the exact frequency with which keys are updated SHOULD be configurable based on site policies, some recommended parameters are provided. The traffic encryption/authentication key SHOULD be updated for every 10 Mbytes of protected traffic, or once every 2 minutes, which ever one results in a more frequent update policy. 6.3 n Update Frequency Updating the counter "n" updates the master key. For interoperability, a standard start time and n update frequency are specified here. As noted above, this prevents reuse of compromised packet authentication keys. The start time for computing "n" is 0h Jan 1, 1995. The time units of n are hours since this start time. Therefore the "n" counter is incremented once every hour. Symbolically, n is computed locally as local n = (current time) - (start time) normalized to hours A sending node uses the above method to compute (and update) n, and using this value of n it computes the Kijn value, as specified in Section 1 above. A receiving node will independently compute n, and check this against the value of n in the received SKIP header. If they do not differ by more than 1, the packet is accepted. If they differ by more than 1, the packet MUST be rejected, as this may be an attempt to reuse a past compromised authentication key. Since n is a 32 bit quantity, there is no practical danger of overflow of n, and hence there is no need to ever reset n. n is a monotonically increasing number, even across certificate updates. draft-ietf-ipsec-skip-02.txt [Page 45] INTERNET-DRAFT SKIP September 28, 1995 Note that this doesn't require the use of fine-grain synchronized clocks or a secure clock synchronization protocol. Nodes should by default have clocks synchronized within an hour of each other. If they are not synchronized even in this coarse-grain manner, then validating certificates and CRLs becomes problematic. Should future implementations of SKIP ever decide to use a different update frequency for n, say once every minute or second, then this can be communicated in a pairwise basis using the algorithm discovery ICMP message specified above. All this requires for interoperability is that SKIP implementations that use different n update frequency values also support the use of the ICMP algorithm discovery message, to indicate the use of their preferred n update frequency. 6.4 Recommended G & P values For interoperability, the values g and p in g^i mod p are specified here. Two sets of values are specified here. One uses a 1024 bit modulus (p). The other uses a 512 bit modulus. These values were computed using the BSAFE library from RSA Data Security, Inc. The 512 bit modulus is defined for interoperability with exportable implementations due to US export control regulations. 6.4.1 Parameters for 1024 bits Modulus: draft-ietf-ipsec-skip-02.txt [Page 46] INTERNET-DRAFT SKIP September 28, 1995 Base (g): cf ca d9 90 8d 98 c1 c4 4e 4e 88 20 69 e8 7b fb d0 ca e1 ee 24 64 a9 6c 89 70 a0 8c 86 00 30 c6 c2 83 4a 0d 82 bd a5 ba 10 cf 80 af 61 96 11 4b 3b 87 a9 7e 59 98 c4 aa 0c bd b7 2b 23 18 33 64 f3 b6 2e 1a 4d e8 86 85 aa de 78 a1 5d ce 65 33 75 7a 9d 00 b9 9e 05 26 ed 79 62 15 97 c4 06 26 fa 51 e1 5e f5 1d cb d2 23 e2 73 e5 f2 c7 3c c4 de 58 cd 3b b6 15 3c aa 84 7c fa 5f cb 6b 8d 78 Modulus (p): dd c9 08 3e 8f ae ef 28 16 ad 50 a9 68 ac bd 04 8e 90 9e ab 5d 41 fc 0a 51 3f 86 0a c4 1b 22 b9 30 dc a3 0a 59 73 05 38 59 b7 85 66 df ff c6 5b b9 1f fe 44 d9 d6 5e cb 9b 68 38 a1 fd 25 3f 01 51 88 9e 93 c3 22 24 f9 03 e6 9b 8b 07 34 9d 9f 9b 38 4b c0 97 03 dc e5 2e 92 47 4c 2c e1 59 26 14 82 49 dd 58 13 91 05 12 11 a1 45 06 ac 11 8f b1 83 53 46 93 88 9a 46 b1 8a 01 50 cb 5e 82 55 6.4.2 Parameters for 512 bits Modulus: Base (g): 67 e2 18 2c 5d 4f 23 c3 52 83 d6 15 23 aa 87 c6 f5 7f 13 ea fb bf 95 34 48 96 20 c1 ac 8d 39 18 a8 26 f3 93 98 ee 4c 3d b9 73 66 be f1 bb 53 6f bd 64 93 2f e2 18 25 db 6b 91 b0 f7 ff 94 b2 92 Modulus (p): cc c4 fd 03 1a 98 a1 33 8d a3 a2 45 d5 7e 16 51 c4 89 39 14 5d aa 38 de 35 27 6c c6 a0 e2 72 e4 42 6a d7 88 3b 50 12 08 66 7b 76 35 5b 61 dd 5f 65 1a 7c ef 54 b1 1b bb b4 e5 8a db d1 60 d2 b7 7. 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 signaled keys incur only the length overhead of the block size of a draft-ietf-ipsec-skip-02.txt [Page 47] INTERNET-DRAFT SKIP September 28, 1995 shared-key cipher. Also, establishing and changing packet encrypting keys involves only a shared-key cipher operation. Yet the scheme has the scalability and robustness of an authenticated public-key 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. This design permits straightforward configurations that allow highly available and load- balanced, protected IP communications. In addition, there are no complicated crash recovery considerations for intermediate or end nodes. High availability of network services, load balancing to better utilize the network's capacity and no crash recovery considerations on end nodes are among some of the properties that have made IP successful as an internet protocol. SKIP preserves all these properties of IP. We have also described how this scheme may be used in conjunction with datagram multicast protocols, both for transient and permanent multicast groups. The SKIP multicast key-management scheme allows extreme flexibility in terms of updating multicast traffic encryption/authentication keys even for very large multicast groups. It also allows all possible traffic encryption algorithms for multicast data, including all stream ciphers. Acknowledgements I would like to thank all of the people who helped make this draft possible. (Any errors and shortcomings are only attributable to the author.) Whitfield Diffie for many helpful discussions on this subject. Geoff Mulligan and Bill Danielson for reviewing this draft and providing constructive suggestions. Martin Patterson for reviewing this draft, and providing feedback and input based on extensive implementation and testing. Marc Dye for suggesting using name spaces other than IP addresses with SKIP, and for the notion of a name space identifier. Tom Markson and Hemma Prafullchandra contributed substantial pieces of this draft, and provided entensive critique and feedback of this, in addition to doing sanity checks of the draft by implementing major pieces of it. draft-ietf-ipsec-skip-02.txt [Page 48] INTERNET-DRAFT SKIP September 28, 1995 Bob Hinden provided valuable suggestions, and created the first skeleton SKIP document in the format of an Internet-Draft. Hilarie Orman suggested the encapsulation scheme which is reflected in this draft and provided other valuable input. Cheryl Madson suggested using SKIP to encapsulate protocols such as OSPF and RIP and other protocols that may need keying material well as other valuable input and critique. Jeff Schiller suggested many improvements to the draft in order to facilitate building interoperable implementations. Two separate groups independently "cleanroom" implemented SKIP based on early drafts and provided invaluable feedback: Germano Caronni, Michael Hauber and Christian Schneider in Switzerland and Kanat Alimjanov in Russia deserve special credit for their efforts. Phillip Zimmerman and Colin Plumb provided valuable information on integrating a web-of-trust certification model, as exemplified in the PGP secure mail package, with SKIP style certificates. In addition the protocol has benefited greatly from discussions on the ipsec mailing list. Many valuable improvements to the draft have come as a result of this. Noteworthy contributions have come from the following individuals: Amir Herzberg, Hugo Krawcyk, Steve Bellovin, Dragan Grebovich, Charles Lynn, Russ Housely. References [1] RFCs 1421-1424, Privacy Enhanced 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 draft-ietf-ipsec-skip-02.txt [Page 49] INTERNET-DRAFT SKIP September 28, 1995 [7] "Public Key Cryptography Standards", PKCS#s 1-10 from RSA Data Security Inc., Redwood City, CA, ftp://ftp.rsa.com/pub/pkcs [8] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995 [9] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995 [10] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995 [11] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D draft-ietf-dnssec-secext-04.txt), Work In Progress [12] D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994 [13] R. Rivest, "The MD5 Message Digest Algorithm", RFC 1321, April 1992 [14] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995 [15] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995 [16] J. Moy, "OSPF Version 2", RFC 1583, March 1994 Author Information: Ashar Aziz Distinguished Engineer Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Ave., Mountain View, CA 94043 e-mail: ashar.aziz@Eng.Sun.COM alternate e-mail address: ashar@incog.com draft-ietf-ipsec-skip-02.txt [Page 50]