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