Simple Key-Management for Internet Protocol

Simple Key-Management for Internet Protocol or SKIP was a protocol developed circa 1995 by the IETF Security Working Group for the sharing of encryption keys. SKIP and Photuris were evaluated as key exchange mechanisms for IPsec before the adoption of IKE in 1998.^[1]

Skip is hybrid Key distribution protocol Simple Key Management for Internet Protocols (SKIP) is similar to SSL, except that it establishes a long-term key once, and then requires no prior communication in order to establish or exchange keys on a session-by-session basis. Therefore, no connection setup overhead exists and new keys values are not continually generated. SKIP uses the knowledge of its own secret key or private component and the destination's public component to calculate a unique key that can only be used between them.

Each side's public component can be defined as gx mod p, where x is the private component. In this system, g is the generator and p is a prime number that is used as the modulus (mod). g and p are fixed values known to both parties.

The first node is called Node I. Node I has a public component Ki and a private component i. The second node is called Node J. Node J has a public component Kj and a private component j.

Every node's public component is distributed in the form of a certificate. They are connected by an unsecure network.

Because Node I knows its own private component and Node J's public component, it can use the two components to compute a unique key that only the two of them can know.

Note - This shared secret is implicit. It does not need to be communicated explicitly to either principal. Each principal can compute this secret based on knowledge of the other principal's identity and public-key certificate. The shared secret is computed using the well-known Diffie-Hellman algorithm.

This mutually authenticated long-term secret is used to derive a key, which is denoted Kij in SKIP Version 1 and Kijn in SKIP, n is a number derived from an ever increasing counter that is called the "n counter."

Note - In SKIP, the master key is not used directly, but it is hashed together with some other data to produce the key.

The key is derived by taking the low-order key size bits of gij mod p. The key Kij or Kijn is used as a master or key-encrypting key to provide IP packet-based encryption and authentication. An individual IP packet is encrypted (or authenticated) using a randomly generated packet key denoted as Kp.

The packet key is in turn encrypted using Kij or Kijn. Since Kij or Kijn can be cached for efficiency, it allows traffic (that is, packet) keys to be modified very rapidly (if necessary even on a per-packet basis) without incurring the computational overhead of a public-key operation.

Furthermore, since the keys are communicated in the packets themselves, there is no need to incur the overhead and complexity of a pseudo-session layer underneath IP. Figure B-5 shows an encrypted IP packet, using the two-step encryption procedure described above.

Figure B-5 Encrypted Packet

When a node receives this encrypted packet, it looks up the sender's certificate. Using this and the receiving node's long-term private key, the receiving node can compute Kij or Kijn. Using Kij or Kijn, the receiving node can decrypt Kp and, therefore, decrypt the packet.

Although there is a packet key in each packet, it is not necessary to change the key in every packet. The keys can be changed as frequently as desired based on key-management policies enforced at the site.

Zero-Message Master-Key Update

The preceding section describes how the nodes can compute one long-term key, Kij or Kijn. Changing this key requires issuing a new certificate to one or the other principal.

There are two desirable reasons for updating the master key. The first is that it minimizes the exposure of any given key-encrypting key, making cryptanalysis more difficult. Second, updating the master key prevents reusing compromised traffic keys (Kp). Should a traffic key used for packet authentication ever be compromised (for whatever reason), then it cannot be used to send forged traffic since the encryption of Kp under the current Kij or Kijn is not known.

The master key is updated by sending a counter (say n) in the packet that only increments and is never decremented. The key Kij becomes a function of this counter n, as follows:

Kijn = h(Kij, n) 

where h is a pseudo-random function such as MD5.

A second feature of the incrementing counter is that it prevents coarse-grained playback of traffic. Once the master keys are updated, traffic that has been encrypted or authenticated with the help of earlier master keys cannot be played back.

In SKIP, the n-counter increments once an hour. It began at zero on January 1, 1995, 00:00:00 GMT.

Summary

This appendix discussed the ideas essential to understanding how SKIP works in more detail. It described how SunScreen SKIP handles keys and certificates with and without a CA; examined how the encryption algorithm operates; listed what important services SunScreen SKIP provides; and presented an overall view of the SunScreen SKIP architecture.

References

http://docs.oracle.com/cd/E19957-01/805-5743/6j5dvnrfs/index.html