Simple Key-Management for Internet Protocols (SKIP)


Ashar Aziz
Tom Markson
Hemma Prafullchandra

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, IPv4 and IPv6) are session-less datagram oriented protocols. A key-management scheme is described that is particularly well suited for use in conjunction with a session-less datagram protocol like IPv4 and IPv6.

Simple Key-Management for Internet Protocols (SKIP) has been designed to work with the IP Security Protocols AH and ESP, which are specified for both IPv4 and IPv6.


1 . SKIP Overview

2. Simple Key-Management for Internet Protocols

2.1 Manual Distribution of Kij
2.2 Zero-Message Master Key Update Algorithm
2.3 Independence from Cryptographic Algorithms
2.4 High Availability and Load Balancing Using SKIP
2.5 Intermediate Authentication with End-to-End Security Using SKIP
2.6 Attacks That the Protocol Guards Against
2.7 Naming, Name Spaces, and Master Key-IDs
2.8 The SKIP Header
2.9 Deriving Keys for Packet Encryption and Authentication
2.10 SKIP for Authentication
2.11 SKIP for Encryption
2.12 SKIP with Combined Transforms
2.13 Generic Use of SKIP Header

3 . Security Considerations

3.1 Generating Random Keys
3.2 Key Update
3.3 Choosing Key Strengths
3.4 Forward Secrecy

4 Informational Section

4.1 SKIP with AH
4.2 SKIP with ESP
4.3 SKIP with AH and ESP

5 Assigned Numbers

5.1 SKIP Protocol Number
5.2 SKIP SPI Value
5.3 Name Space Identifier (NSID) Assignments
5.4 Assigned Algorithm Numbers

6 Recommended Parameters and Implementation Notes

6.1 n Update Frequency
6.2 SKIP with the Certificate Discovery Protocol
6.3 Recommended g and p Values

7 Conclusions

8 Acknowledgments

9 References


1. SKIP 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 public keys can be authenticated 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 authenticating public keys using certificates. Secure Domain Name Security (DNS) [11] provides an example of authenticating public keys (and other resources) using a secure directory service. Still another example of authenticating public keys is the web-of-trust "introducer" model, best exemplified in the Pretty Good Privacy (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 or 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 sessionless protocol. The IP source would need to first communicate with the IP destination to acquire this session key. Also, if and when the session key needs to be changed, the IP source and the IP destination need to communicate again 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 looses all session state, then mechanisms need to exist to securely remove the half-opened session state on the side that did not crash. These mechanisms need to be secure because insecure (unauthenticated) removal of half-opened sessions opens the door to a trivial denial-of-service attack.

Performing session-oriented key-management at the IP layer has another major drawback. An important feature of the IP protocol is recovery from intermediate node or link failures by dynamically rerouting 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 rerouting of IP traffic around failed routers or links. In addition to rerouting for reasons of router or 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 splits the traffic among those equal cost routes, thereby load balancing IP traffic among several different routers or links.

Performing session-oriented key-management for IP defeats these properties of IP. For example, if encryption is being performed at some intermediate point (for instance, encrypting router or firewall) then session-oriented key-management makes dynamic rerouting of encrypted IP traffic for reasons of failed or congested nodes or links far more complicated than the straightforward fail-over and rerouting mechanisms that exist for unencrypted IP traffic. This is because, in essence, a stateful connection has been created to an intermediate point. A packet is no longer an independent entity; it now requires information from a security association establishment phase, namely the session key, to be properly processed. Rerouting encrypted traffic for decryption by another intermediate node 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 or authenticate rerouted IP traffic. Thus, session-oriented key-management, implemented at the IP layer, breaks many of the properties that have made IP successful as an internet protocol.

This motivates considering key-management schemes that operate in a sessionless and stateless manner.

An alternative design could utilize authenticated RSA public keys in a stateless key-management scheme. This might work through in-band 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, Privacy Enhanced Mail (PEM) [6] and other secure mail programs perform message encryption. Although this avoids the session state establishment requirement and prior out-of-band communication 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 will 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 will need to be performed 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 values can avoid the need for pseudo-session state management between two ends to acquire and change packet encrypting keys. Authenticated DH public values 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 rerouting of protected IP traffic through alternate encrypting intermediate nodes for crash-recovery, fail-over, and load-balancing scenarios.

2. Simple Key-Management for Internet Protocols

To implement SKIP, each IP-based source and destination has an authenticated Diffie-Hellman (DH) [4] public value. This public value can be authenticated in numerous ways. Some possibilities for authenticating DH public values are by the use of X.509 certificates [6], Secure DNS [11], and PGP certificates [24].

These certificates can be signed using any signature algorithm, such as RSA or DSA. In case of X.509 certificates, 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. A detailed description of this can be found in [23]. In the following discussion, the focus is on IP nodes, although user-oriented keying is possible and is further described in Section 1.2.7.

Thus, each IP source or destination I has a secret value i, and a public value gi mod p. Similarly, IP node J has a secret value j and a public value gj mod p.

Once n certificates are assigned to n IP nodes, O(n2) mutually authenticated pairwise keys arise, simply as a result of the public value authentication process. This is because each pair of IP source and destination I and J can acquire a mutually authenticated shared secret gij mod p. The symmetric keys derivable from these shared secrets require no setup overhead, except for the authenticated public value 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 value. Since there is nothing secret about DH public values, one natural way to discover the relevant authenticated public value is to distribute these using a directory service or the Certificate Discovery Protocol (CDP) [19].

This computable shared secret is used as the basis for a key-encrypting key to provide IP packet-based authentication and encryption. Thus, gij mod p is called the long-term secret, and is derived from a key Kij . Kij is used as the key for a block Symmetric Key CryptoSystem (SKCS) like DES, RC2, IDEA, and such.

Kij is derived from gij mod p by taking the low-order key-size bits of gij mod p. Since gij mod p should minimally be 512 bits, and for greater security should be 1024 bits or more, enough bits can always be derived for use as Kij, which is a key for a SKCS. SKCS key sizes are typically in the range of 40 to 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) simply by knowing the source IP node's authenticated public value. Because this key is implicit, and is used as a master key, its length can be made as long as desired, without any additional protocol overhead. Increasing the length of Kij in combination with a strong cryptosystem, can make cryptanalysis of Kij arbitrarily difficult.

Kij is used to encrypt a transient key, which is called Kp (for packet key). Kp is then used as a key to encrypt or authenticate an IP packet or a collection of packets. This is done to limit the actual amount of data encrypted using the long-term key Kij. Since it is desirable to keep Kij for a relatively long period of time, the actual IP data traffic is not encrypted using key Kij. Instead, transient keys are only encrypted in this long-term key, and use the transient keys (Kp) to encrypt or 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 .

Note: For the sake of simplicity, the key Kp is described in this section as a packet encryption or authentication key. Actually, Kp is used to derive two separate keys; one for encryption and another for authentication. This is further described in Section 1.2.9.

The first time a source I, which has a secret value i, needs to communicate with destination J, which has a public value
gj mod p, it computes the shared secret gij 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: To prepare this packet for transmission to node J, no communication is necessary with node J. When node J receives this packet, it also computes the shared secret Kij and caches it for later use. (To do this, if it did not already possess I's authenticated DH public value, it may need to obtain this from the local directory service, and check its authenticity.) Using Kij, it obtains Kp, and using Kp it obtains the original IP packet that 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 computationally expensive public key operation, the packet encrypting or authenticating keys can be changed by the transmitting side and discovered by the receiving side.

2.1 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 one of the keys that is manually established when using SKIP.

Since manual rekeying 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.

2.2 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 reuse 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 reuse is prevented by updating the implicit master key Kij and by never reusing 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. To check certificate validity information, such coarse-grain synchronization is required in any case for any scheme that uses public-key certificates. Recommended time units or counter update frequency and the agreed-upon start time is specified later in this document.

Once the counter has moved forward, packets encrypted with the help of counter values that differ by more than one from the local n must be rejected.

This counter value is passed in the field labeled n following the version and next header fields of the SKIP header, which is described in Section 1.2.8.

The counter n is computed as described in Section 1.6.1. The n'th master key is computed using the following functions:

Kij' = Low order 256 bits of Kij
Kijn = h(Kij' | n | 01h) | h(Kij' | n | 00h)

where h() is a pseudo-random, one-way hash function. This function, which is specified as the "Hash Algorithm," is part of the Kij algorithm. For example, if Kij algorithm is "DES-CBC, MD5 for key separation," h() is MD5. The " | " represents concatenation, and the high-order bits are on the left side. The low-order bits of this operation are used for Kijn . The 00h, and 01h are 1-byte values containing 0 and 1, respectively. The counter n must be in network order for purposes of this computation.

When using public key agreement or manual key agreement to establish Kij, Kij must be 256-bits long. This means that if Kij is derived from gij mod p, then the low-order 256 bits are used as the input to the Kijn calculation. When manually establishing Kij, the Kij length must be 256 bits.

A pictorial representation of the above operation using MD5 is as follows:

MD5 (Kij [MSB first] n [32 bits] 00) --> Low 128 bits of Kijn
MD5 (Kij [MSB first] n [32 bits] 01) --> Low 128 bits of Kijn

2.3 Independence from Cryptographic Algorithms

Although the descriptions above have been presented using the cryptographic constructions of classic DH (exponentiations over a prime field), the protocols can be generalized 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. Thus, a public key agreement system is distinguished from a public key cryptosystem that 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 [17] and schemes that utilize exponentiation using composite moduli.

Essentially, all aspects of the key-management protocol described above can be generalized to public and private values of the public key agreement type.

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 (for instance, secure DNS).

2.4 High Availability and Load Balancing Using SKIP

Using the SKIP protocol, it is straightforward to construct highly-available and load-balanced protected IP configurations.

To support a redundant configuration, a set of intermediate nodes are set up to share the same long-term Diffie-Hellman secret or public value pair. These nodes can all have different IP addresses, as long as the destination Master Key-ID (MKID) 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.

(The notion of MKIDs, and how they differ from the source and destination IP addresses, is explained in Section 1.2.7.)

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 or authenticated IP traffic. The standard dynamic IP routing facilities provide for high availability and load balancing. No new protocol is required to achieve these goals. Should one of these intermediate nodes (or their associated network links) fail, IP automatically routes packets through the remaining set of nodes, and these rerouted IP packets remain decryptable by the other members of the redundant set. There is no limit to the number of nodes or links that can be configured in such a redundant configuration.

2.5 Intermediate Authentication with End-to-End Security Using SKIP

It is sometimes desirable to authenticate end-to-end protected IP traffic at an intermediate node [9]; for example, a site firewall. Such intermediate authentication is typically not practical with conventional session-oriented key-management, since it isn't practical to dynamically share end-to-end transient session keys with an intermediate node.

Using SKIP, intermediate authentication of end-to-end protected IP traffic can be realized, if participating principals can share their long-term private keys with the intermediate node. This may not be desirable if the long-term keys belong to individual users, because of privacy related concerns, but may be acceptable in case the long-term keys belong to servers on the network; for example, mail or file servers.

Once a long-term key has been shared with an intermediate node, the intermediate node can authenticate end-to-end protected IP traffic just as easily as it can authenticate end-to-intermediate protected IP traffic. With knowledge of the interior principal's long-term private key, an intermediate device can recover the packet authentication key, verify the packet authenticity, and, if it is verified, forward the packet unmodified to its destination.

Such a scheme has the benefit of end-to-end encryption or authentication of IP traffic while still maintaining cryptographic checks at a security perimeter defined by the intermediate device (for example, a site's network boundary).

Note: With knowledge of another principal's long term private key, the intermediate device is also in a position to decrypt the end-to-end protected traffic, or forge traffic for principals whose keys it knows. If this is not desirable, then this kind of long term private key sharing should not take place by foregoing either intermediate authentication or end-to-end protection.

2.6 Attacks That the Protocol Guards Against

It is not possible to list all possible attacks on a cryptographic protocol in a short space. Instead, a well-known category of attacks on cryptographic protocols is described and shows how SKIP defeats those attacks.

2.6.1 Intruder In-the-Middle Attacks

Unauthenticated DH is susceptible to an intruder in-the-middle attack. To overcome this, authenticated DH 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 DH public parameters are long-term and authenticated. Intruder in-the-middle attacks on DH assume that the parties cannot determine who the public DH keys belong to. Authenticated DH public values 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).

2.6.2 Known Key Attacks

If the in-band traffic keys Kp used for packet authentication are ever compromised (for whatever reason), then the master key update algorithm described above precludes the reuse 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 reuse past compromised keys Kp to any advantage.

Also, even if all the packet encryption or authentication keys (Kp) encrypted in a given Kijn are compromised, then this doesn't help an attacker learn any other Kp, since knowing any number of keys Kp 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 a Kijn, and that should be infeasible even given a very large number of known or chosen Kp keys as long as the key-encryption algorithm is practically secure against a known or chosen text attack. To the extent that the key-encryption algorithm is secure against a known or chosen text attack, SKIP is secure against a known or chosen key attack.

2.6.3 Clogging Defense

An attacker can 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; for example, the DH computation.

To prevent denial-of-service attacks on the SKIP scheme described above, a recommended solution is to precompute 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 is still able to communicate with the set of machines for which it has precomputed master keys, it simply stops 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 (for example, 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 administrators should always be in the precompute cache used to prevent this form of denial-of-service attack. This allows the administrator to securely add more principals to the precompute cache, even during a clogging attack.

2.7 Naming, Name Spaces, and Master Key-IDs

SKIP uses two 1-byte fields in the SKIP header, Source Name Space ID (NSID) and destination NSID, to indicate that MKIDs are used for looking up authenticated public values instead of the source or destination IP addresses. These fields also identify which name space is being used for MKIDs.

Note: The term Master Key-ID is used instead of certificate ID, since the SKIP protocol allows manual master key setup. Master Key-ID is a generic term used to identify a particular Kij, whether it is obtained manually or through use of certified DH public values.

MKIDs effectively decouple the identification of a master key for purposes of key lookup, and access control from issues of network topology, routing, and IP addresses. As an example, this allows IP nodes to use different IP addresses for routing and key lookup purposes.

More importantly, it allows non-IP entities, such as individual users, to be identified using whatever name space is being used for them.

SKIP permits multiple name spaces to be used by using the NSID fields in the SKIP header. The first NSID byte refers to the name space of the source MKID, and the second NSID refers to the name space of the destination MKID.

The length of the MKID is implicit in the choice of the NSID. There are two commonly used lengths, 32 bits and 128 bits. A 32-bit MKID can be used to identify, for example, IPv4 addresses, or XOPEN or POSIX user IDs. A 128-bit MKID can be used to refer to an IPv6 address.

The usage of NSIDs also allows many different name spaces (up to 255) to be used with SKIP. One way of deriving the MKID is to define it to 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 DNs, etc. Another way of deriving the MKID is to use some unique identifier as the keyid. Examples of this include POSIX or XOPEN user IDs, or 802. x MAC addresses.

If the names have associated privacy concerns, then employing the message digest scheme can potentially protect these sensitive names, due to the one-way property of a message digest. It is important to note that this privacy aspect of protecting names using their message-digest is only possible if the name space is large enough to resist an exhaustive search attack. If the name space is too small, then this allows an attack that compares all the names in the name space to their message digests. Names that are sensitive and taken from a small name space should no t be used with this message digest representation.

It is also possible for this identifier to be the message digest of a principal's DH public value since some principals may wish to be known by their public values alone. If the public value is used as an identification mechanism, it simplifies the distribution of authenticated public values since there is an algorithmic and cryptographic binding between a name and its public value. This is the same purpose that certificates serve, so this can potentially simplify the distribution of public values in communities that choose this naming mechanism because it eliminates the need for a third party (for example, Certifying Authority (CA), secure directory server, trusted introducer, etc.) to ensure a secure binding between a name and a public value. The encoding for UDH public values is beyond the scope of this document and is defined separately [20].

There is a separate NSID byte for source and destination, so it is possible for entities identified using different name spaces to communicate as long as the two parties can understand both name spaces.

Principals in the network need to be able to reverse-lookup a certificate (or equivalent information) using the MKID. There are no security issues in the binding between a name in its native name space, and the message-digest-derived MKID since there is a cryptographic binding between the 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 an NSID field is zero, then the corresponding MKID is absent. In this case, the corresponding MKID defaults to the source or destination IPv4 or IPv6 address, respectively.

Although a MKID can be allocated out of the IPv4 or 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 use, this decoupling allows nodes to move around on the network and come in from dynamically assigned IP addresses (using, for example, the Dynamic Host Configuration Protocol [18]), and still have access control and DH public value lookup occur based on the source MKIDs.

Still another example includes mobile users, identified in any name space, who can securely access network data and services from many different IP nodes. This is because key lookup and access control is based on their native names (identified using the source MKID), and not the IP address of the node from which they are performing the network access. These users can carry around their private keys in smart cards or, alternatively, these private keys can be distributed over the network encrypted in a per-user password. Users can be identified using their DNS names, POSIX or XOPEN user IDs, X.500 DNs, etc.

Similarly, destination MKIDs can serve many purposes as well. When the destination MKID refers to an IP address, it can be used to pass end-to-end encrypted SKIP packets through an encrypting intermediate node. Without a destination MKID, an intermediate node that is encrypting or decrypting SKIP packets for multiple machines has no way of knowing whether a received packet should be uncompressed, decrypted, authenticated, or just forwarded. A destination MKID enables an encrypting intermediate node (for example, router or firewall) to determine whether to process a packet or simply forward it. The destination MKID is present when the destination NSID is non-zero.

On an end node, the destination MKID can be used to distinguish between multiple users on the same IP node.

If the source NSID is non-zero, the source MKID must be used for public value lookups and the source IP address must not be used. If the destination NSID is non-zero, the destination MKID must be used for public value lookups and the destination IP address must not be used.

Note: A node must not process a packet that has a destination MKID that does not match a local MKID even if the destination IP address matches.

Some commonly used name spaces have been assigned NSIDs. These are specified in the SKIP Assigned Numbers Document

2.8 The SKIP Header

A SKIP header communicates the in-band keying, algorithms, and next protocol used in the packet. The SKIP header is illustrated below. Fields are transmitted left to right. All value fields in the SKIP header are transmitted in network order

0    

15

16    

31

Ver

Rsvd

Source NSID

Dest NSID

Next Header

Counter n

Kij Alg

Crypt Alg

MAC Alg

Comp Alg

Kp encrypted in Kijn . . . (typically 8 to 16 bytes)

Source Master Key-ID (If Source NSID is non-zero)

Destination Master Key-ID (If Dest NSID is non-zero)

The first field of the SKIP header is the version (Ver). The protocol described in this document is 1. The four bits following the version are reserved (Rsvd) for future versions of SKIP, and are set to zero by all SKIP v1 implementations and ignored. A non-zero source NSID indicates that a packet contains a source MKID. The value of the source NSID indicates the name space from which the MKID is derived. A non-zero destination NSID indicates the SKIP header contains a destination MKID. The value of the destination NSID indicates the name space from which the MKID is derived.

Following the NSID bytes in the SKIP header, the next header field is used to indicate which protocol follows the SKIP header. This field usually indicates Encapsulating Security Payload (ESP) or Authentication Header (AH). But the next header can be any protocol that requires keying material. Examples of protocols other than AH or ESP that can use SKIP are given later.

The Counter n field is a 32-bit field that is used for coarse-grain playback protection and to prevent compromised key reuse.

The 1-byte field Kij algorithm identifies two distinct algorithms; the key encryption algorithm and the hash algorithm. The key encryption algorithm always uses the low-order bits of the DH shared secret as the key. The Kij algorithm must specify both the encryption algorithm and the hash algorithm. The key encryption algorithm must be a block cipher algorithm used in CBC mode to encrypt Kp (which is a variable number of bits). The Initialization Vectors (IV) for the CBC mode encryption must always be set to all zeros (IV=0). So, for example, for 64-bit IV algorithms, such as DES-CBC, the IV is 64-bits of zero.

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 or MAC algorithms. The low-order key-length bits of the decrypted output are used as Kp.

The hash algorithm is generally a one-way, pseudo-random function used to generate the n 'th version of the master key and to split Kp into separate encryption and authentication keys.

The key separation algorithm is generally a cryptographic hash function used to generate the master key and to split Kp into encryption and authentication keys.

The Crypt Alg and MAC Alg specify algorithms used by the interior protocol for encryption and authentication. These algorithms are specific to the protocol that uses them and the transforms it specifies. In general, the MAC Alg specifies the algorithm used to calculate a Message Authentication Code (MAC) and the Crypt Alg specifies the algorithm used to encrypt the packet. This is not an absolute, however; for instance, it is possible to have a Crypt Alg that provides both encryption and MAC computation.

The Comp Alg field specifies the algorithm that was used to compress packets prior to encryption or authentication. A non-zero Comp Alg field indicates that compression was performed on the plaintext, prior to encryption or authentication. The value of the Comp Alg field indicates the compression algorithm that was employed.

The values for the algorithm fields is described later in this document.

The field "Kp Encrypted in Kijn " is the encrypted Kp that has been encrypted with Kijn using the Kij algorithm.

The source MKID field contains the MKID of the sender. This field is only present if the source NSID is non-zero.

The destination MKID field contains the MKID of the intended SKIP receiver. This field is only present if the destination NSID is non-zero.

In a specific use of the SKIP header, a field may not be relevant, and its value is denoted as reserved (Rsvd). All reserved fields must be set to zero in the SKIP header and ignored.

2.9 Deriving Keys for Packet Encryption and Authentication

In general, packets can be both encrypted and authenticated. An important issue when performing both authentication and encryption is key separation. Conforming SKIP implementations must derive authentication and encryption keys originating via SKIP in the manner specified below.

The Kp, which is decrypted from the packet head, 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 | Crypt Alg | 02h) | h(Kp | Crypt Alg | 00h)

A_kp = h(Kp | MAC Alg | 03h) | h(Kp | MAC Alg | 01h)

where h() is a pseudo-random, one-way hash function. This function, which is specified as the "Hash Algorithm," is part of the Kij algorithm. For example, if the Kij algorithm is "DES-CBC, MD5 for Hash," then h() is MD5. The "|" specifies concatenation, in the same manner as described in Section 1.2.2. Crypt Alg and MAC Alg are the 1-byte fields from the SKIP header.

The construction above has the property that knowing either one of E_kp or A_kp keys does not compromise any information about the other key because of the one-way property of h(). This allows, for example, 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 MD5(Kp | Crypt Alg| 00h) function needs to be computed because this provides the low-order 128 bits of E_kp. Similarly, if only 128 bits or less are required for the authentication key A_kp, only the MD5(Kp | MAC Alg | 01h) 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 is used with SKIP.

An implementation uses the maximum of the key-lengths indicated by Crypt Alg and MAC Alg when determining the length of the actual Kp that is decrypted from the SKIP header. For example, if Crypt Alg specifies a 64-bit encryption key length, the MAC Alg specifies a 128-bit authentication key length--thus, the length of Kp is 128 bits. This 128-bit Kp is input to the functions specified above to generate E_kp, which is low-order 64-bits of the E_kp function, and A_kp, which is 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 is 128-bits, of which the upper 8 bits is random fill. The random fill bits must be treated as zero for the E_kp and A_kp computation functions. In the example given above, the Kp input to the E_kp and A_kp functions is 128 bits, with the upper 8 bits set to zero.

Note: It is not necessary to perform a complicated set of conditional rules 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 that produces the key lengths required for that algorithm. Since this table is small enough to fit in most caches, this can result in a fast way to determine the appropriate encrypted key length to perform SKIP header decoding.The key separation function described above is always used, irrespective of whether only one or the other of authentication or encryption is being performed. Namely, even if encryption is being done in the absence of authentication or authentication is being done in the absence of encryption, the keys used for encryption or authentication must be derived separately, as specified above. Kp is never used directly to authenticate or encrypt traffic.

2.10 SKIP for Authentication

This section describes how SKIP compliant implementations use SKIP originated keys to achieve packet authentication.

To achieve authentication in the absence of privacy, SKIP compliant implementations use the key A_kp to compute a MAC over the packet and invariant clear header fields. The term "MAC" is synonymous with the term "Authentication Data" in RFC 1826.

The MAC Alg field in the SKIP header must be used to lookup a specific authentication transform. The key A_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.

Scope of MAC Computation

All non-reserved SKIP header fields must be included in the IP authentication header's calculation of authentication data. The reserved fields in the SKIP header are zeroed for the purpose of IP authentication header's authentication data calculation.

2.11 SKIP for Encryption

When SKIP is used to supply keying material for encryption only, the Crypt Alg indicates the packet encryption algorithm. E_kp is used as a key to the Crypt Alg. The Crypt Alg is mapped to standard transforms, such as [15]. These transforms also contain information such as IVs or Message Indicators (MIs).

As always, Kij Alg identifies the encryption algorithm used to encrypt Kp.

2.12 SKIP with Combined Transforms

For transforms that combine encryption and authentication, such as ESP using Keyed MD5 with DES-CBC, only one header, ESP in this case, is needed. The Crypt Alg in the SKIP header indicates the transform and A_kp is used for authentication and E_kp (as discussed in Section 1.2.9) is used for encryption. The MAC Alg field must contain the same value as the Crypt Alg field, since this is a combined authentication or encryption transform.

2.13 Generic Use of SKIP Header

The SKIP header can be used for any protocol that requires keying material. The next header in the SKIP header specifies this protocol. A protocol being encapsulated should have a reserved value that 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 defines how the Crypt, MAC, and Comp algorithms are used. Kijn is used to encrypt Kp.

3. Security Considerations

3.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 is 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.

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 unpredictablIt 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 a sufficient amount of random bits for commonly used cryptographic algorithms.

For more information on the subject of generating random keys, RFC 1750 [12] is recommended reading.

3.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 or authentication key should be updated for every 10-Mbytes of protected traffic, or once every two minutes, whichever one results in a more frequent update policy.

The traffic encryption or authentication key (derived using Kp) must be updated every time a Kijn is updated. In addition, in case multiple Kijn 's exist on a given node, then Kp must not be shared among different Kijn s. Kp must be randomly generated for each end destination and for different principals on the same node.

3.3 Choosing Key Strengths

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, 12-bits in 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 DH (used to derive the master keys) must be 1024 bits or greater. The exponent size for classic DH for symmetric master key sizes of 128-bits must be 256 bits or greater.

Also, when a 128-bit MAC algorithm is used, then the key-encryption algorithms should have strength equal to or greater than the size of the resulting hash. For interoperability purposes, use of Algorithm #2 (3-key triple DES-EDE-CBC with MD5 for key separation) is deemed mandatory to implement for key encryption (Kij Alg), when also implementing authentication or any 128-bit-strength traffic encryption algorithm (for example, 2- or 3-key triple DES or IDEA).

3.4 Forward Secrecy

Perfect forward secrecy (PFS), as described in [3], is not addressed by the base protocol described in this document. The protocol as described has a small amount of bilateral state. The risk of compromise of past encrypted traffic due to future compromise of long-term keying material can be minimized by minimizing the longevity of any particular master key. Future extensions to the base SKIP protocol can address forward secrecy by either having short-lived certified DH public values, or by introducing an ephemeral DH component into the master key computation. Doing the latter would introduce greater bilateral state and overhead than is in the base SKIP protocol.

4. Informational Section

This section gives examples of how SKIP is used with various IP security encapsulation protocols, such as AH and ESP.

4.1 SKIP with AH

The AH Protocol [9] is used to provide authentication for IP datagrams.

The SKIP header precedes the AH header and follows the IP header as shown below:
The detailed protocol encoding for SKIP followed by an AH header is shown below:
IPv4 with SKIP AH Example

IPv4 Header

SKIP Hdr

Auth Hdr

Inner Protocol (e.g.IP,TCP,UDP)

0    

15

16    

31

Ver

Rsvd

Source NSID

Dest NSID

Next Header = AH

Counter n

Kij Alg

Reserved

MAC Alg

Comp Alg

Kp encrypted in Kijn . . . (typically 8 to 16 bytes)

Next Header

Length

Reserved

SKIP_SPI)

Authentication Data computed using A_kp (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, for example, RFC 1828 [14], as an example of an authentication transform.

4.2 SKIP with ESP

An example of use of SKIP for encryption is SKIP combined with the ESP protocol [10]. 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. The SKIP header follows the IP header and precedes the ESP header as shown below:
IPv4 with SKIP ESP Example

IPv4 Header

SKIP Hdr

ESP Hdr

Inner Protocol (e.g.IP,TCP,UDP)

The detailed protocol encoding of SKIP combined with ESP is illustrated below:

0    

15

16    

31

Clear IP header protocol = SKIP . . . (typically 20-bytes)

Ver

Rsvd

Source NSID

Dest NSID

Next Header = AH

Counter n

Kij Alg

Crypt Alg

Reserved

Comp Alg

Kp encrypted in Kijn . . . (typically 8 to 16 bytes)

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. The assumption is that this reserved SPI has been assigned symbolic value SKIP_SPI. The SKIP_SPI value is specified later in this document. The source and destination NSIDs are assumed to be zero, meaning that MKIDs are absent.

The opaque transform data is defined by the particular transform (such as, DES-CBC in RFC 1829). This data normally contains the encrypted data and transform specific information, such as the IV.

Kij Alg identifies the encryption algorithm used to encrypt Kp. Kp is used to derive the key E_kp (as specified above) that is used to encrypt the payload.

4.3 SKIP with AH and ESP

SKIP can be used with combined AH and ESP modes. The next protocol field in the SKIP header is AH, and the next protocol field in AH header is ESP.
A_Kp is used for authentication, and E_kp (as discussed in Section 1.2.9) is used for encryption.

 

The following is an example of SKIP with AH and ESP. In addition, the use of MKID's is also demonstrated.

0    

15

16    

31

Clear IP header protocol = SKIP . . . (typically 20-bytes)

Ver

Rsvd

Source NSID

Dest NSID

Next Header = AH

Counter n

Kij Alg

Crypt Alg

MAC Alg

Comp Alg

Kp encrypted in Kijn . . . (typically 8 to 16 bytes)

Source Master Key-ID

Destination Master Key-ID

Next = ESP

Length

Reserved

SKIP_SPI

Variable length AH MAC, computed using A_kp

SKIP_SPI

ESP transform data (e.g., IV), payload encrypted using E_kp

 

5. Assigned Numbers

5.1 SKIP Protocol Number

SKIP has been assigned the protocol number 57 by the IANA. This is what is in the "protocol" field in the IP header when the SKIP header follows the IP header.

5.2 SKIP SPI Value

For use with the AH and 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 is the value used in the SPI fields of the AH and ESP protocols.

5.3 Name Space Identifier (NSID) Assignments

Name space assignments are located in the SKIP Assigned Numbers Document

5.4 Assigned Algorithm Numbers

Algorithm numbers are assigned in the SKIP Assigned Numbers Document

6. Recommended Parameters and Implementation Notes

6.1 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 Jan 1, 1995 00:00:00 UTC. 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.2.2. A receiving node independently computes n and checks 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 should be rejected, as this can 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.

Note: 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.

6.2 SKIP with the Certificate Discovery Protocol

The certificate discovery protocol (CDP) [19] can be used to exchange SKIP certificates. The name field in the name record of CDP is the concatenation of the NSID and MKID values, respectively. For example, for NSID=01 MKID=7f000001, the name is 017f000001.

6.3 Recommended g and p Values

For interoperability, the values g and p in gj mod p are specified in the SKIP Assigned Numbers Document, for various modulus lengths.

7. Conclusions

The scheme, Simple Key-Management for Internet Protocols (SKIP), is particularly well suited for use with 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 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. In addition, there are no complicated crash recovery considerations for intermediate or end nodes.

8. Acknowledgments

The authors would like to thank all of the people who helped make this report possible.

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.

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, as well as other valuable input and critique.

Two separate groups independently "cleanroom" implemented SKIP based on early drafts and provided invaluable feedback: Michael Hauber and Christian Schneider in Switzerland, and Kanat Alimjanov, Alex Vopilov, Nick Tzarev and Roman Sagalev in Russia, deserve special credit for their efforts.

Germano Caronni suggested many useful SKIP protocol enhancements, and also led the independent implementation of SKIP in Switzerland.

Phillip Zimmermann 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. Colin Plumb also contributed the section describing the generation of the prime values used in SKIP.

Colin Plumb provided the prime generation software and algorithm description given in the recommended primes section. The choice of the quote used to seed the primes is due to Phillip Zimmermann and Colin Plumb.

Joseph Reveane, Rich Skrenta, and Ben Stoltz reviewed this draft and provided constructive suggestions.

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, and Russ Housely.

References

[1] RFCs 1421-1424, Privacy Enhanced Mail

[2] Aziz, A., Diffie, W., Privacy and Authentication for Wireless LANs, IEEE Personal Communications, February 1994

[3] Diffie, W., Wiener, M., Van Oorschot, P, Authentication and Authenticated Key Exchanges, in Designs Codes and Cryptography, Kluwer Academic Publishers, 1991

[4] Diffie, W., Hellman, M., New Directions in Cryptography, IEEE Transactions on Information Theory, Vol IT-22, Nov 1976,
pp. 644-654

[5] Deering, S. E., Host Extensions for IP Multicasting, RFC 1112

[6] Kent, S., Certificate-Based Key Management, RFC 1422

[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 Security Payload, RFC 1827, August 1995

[11] Eastlake, D., Kaufman, C., Domain Name Security Extensions, Work in Progress

[12] Eastlake, D., Crocker, S., Schiller, J., Randomness Recommendations for Security, RFC 1750, December 1994

[13] Rivest, R., The MD5 Message Digest Algorithm, RFC 1321, April 1992

[14] Metzger, P., Simpson, W., IP Authentication Using Keyed MD5, RFC 1828, August 1995

[15] Karn, P., Metzger, P., Simpson, W., The ESP DES-CBC Transform, RFC 1829, August 1995

[16] Moy, J., OSPF Version 2, RFC 1583, March 1994

[17] Menezes, A., Elliptic Curve Public Key Cryptosystems, Kluwer Academic Publishers, 1993

[18] Droms, R., Dynamic Host Configuration Protocol, RFC 1531, October 1993

[19] Aziz, A., Markson, T., Prafullchandra, H., Certificate Discovery Protocol, October 1996

[20] Aziz, A., Markson, T., Prafullchandra, H., Encoding of an Unsigned Diffie-Hellman Public Value, October 1996

[21] Aziz, A., Markson, T., Prafullchandra, H., SKIP Algorithm Discovery Protocol, October 1996

[22] Aziz, A., Markson, T., Prafullchandra, H., SKIP Extensions for IP Multicast, October 1996

[23] Aziz, A., Markson, T., Prafullchandra, H., X.509 Encoding of Diffie-Hellman Public Value, October 1996

[24] Atkins, D., Stallings, W., Zimmerman, P., PGP Message Exchange Formats, Work in Progress