[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP (a key-management proposal)
I have a key-management proposal (SKIP) that I would like to
present to this group. I believe that this key-management proposal has
many advantages for use in conjunction with a session-less and
stateless protocol like IP (or CLNP or SIPP).
Unfortunately, the proposal is not yet in the form an
Internet-Draft, for which I apologize. However, I am hoping that
there is enough information in the included draft overview to convey
the basic ideas of the proposal.
The proposed protocol format is simply a placeholder for conveying
what sort of information needs to be present in the protocol
that uses this kind of key-management. Something like swIPe could
also be used, provided swIPe can accomodate the notion of a
session-less key-management system, such as the one proposed here.
(I am not sure if the existing swIPe protocol can do this, and
this is one of the reasons I am presenting this proposal earlier
than I was planning on. Perhaps the swIPe folks can tell me
if this sort of key-management can be accommodated by their
protocol).
The section on management of certificates (section 4) is purely
exploratory at the moment. It could be easily modified, without
affecting the basic key-management algorithm. (CRLs are not
mentioned, but they are obviously part of a certificate based
infrastructure).
The main advantage of this proposal is its stateless nature,
and the use of a zero-message key-management protocol. It combines
the advantages of a public-key certificate infrastructure
(scalability, robustness etc.) with the advantages of
shared key cryptography (speed, small block sizes etc.).
Please comment.
Ashar.
----------------Begin Draft Overview of SKIP---------------------
Simple Key-Management For Internet Protocols (SKIP)
Draft 0.1
Ashar Aziz
(ashar.aziz@Eng.Sun.Com)
6/16/94
Sun Microsystems Laboratories, Inc.
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) 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 and some of its re-
placement candidates like CLNP and SIPP. We also describe an ap-
plication of this scheme in the context of Internet multicasting
protocols.
1.0 Overview
Any kind of scalable and robust key- management scheme that needs
to scale to the number of nodes possible in the Internet needs to
be based on an underlying public-key certificate based infras-
tructure. This is the direction that, e.g, the key-management
scheme for secure Internet e-mail, Privacy Enhanced Mail or PEM
[1] , is taking.
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 certi-
ficate, what is meant here is that the key being certified is an
RSA public key.)
One way to obtain authenticity and privacy at a datagram layer
like IP is to use RSA public key certificates. (In the following
description we use the term IP, whereas this can be any connec-
tionless datagram protocol like CLNP or SIPP).
There are two ways RSA certificates can be used to provide au-
thenticity and privacy for a datagram protocol. The first way is
to use out-of-band establishment of an authenticated session key,
using one of several session key establishment protocols. This
session key can then be used to encrypt IP data traffic. Such a
scheme has the disadvantage of establishing and maintaining a
pseudo session state on top of 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. This communica-
tion requirement is particularly ill-suited to a datagram proto-
col like IP, which doesn't even require the receiving side to be
up in order to send packets to it. Of course, in order to estab-
lish and change negotiated session keys, the other side has to be
up to negotiate or re-negotiate the session key.
The second way an RSA certificate can be used is to do in-band
signalling of the packet encryption key, where the packet encryp-
tion key is encrypted in the recipient's public key. This is the
way, e.g, PEM does message encryption. Although this avoids the
session state establishment requirement, and also does not re-
quire the two parties to communicate 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- 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, as and 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 high.
Use of Diffie-Hellman (DH) public-key certificates [4] can avoid
the pseudo session state establishment and the communications re-
quirement between the two ends in order to acquire and change
packet encrypting keys. Furthermore, this scheme does not incur
the overhead of carrying 64-128 bytes of keying information in
every packet.
This kind of key-management scheme is better suited to protocols
like IP, because it doesn't even require the remote side to be up
in order to establish and change packet encrypting 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 has a
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. (We call such a certificate a
Diffie-Hellman certificate, because the public value that is cer-
tified is a Diffie-Hellman public value.) How the certificates
are managed is described in more detail later.
Thus each IP source or destination I has a secret value i, and
computes a public value a**i mod p. Each pair of IP source and des-
tination I and J can acquire a shared secret a**ij mod p. They can
acquire this shared secret without actually having to communi-
cate, as long as the public key of each IP node is known to all
the other IP nodes. Local caching of DH certificates can elim-
inate the constant need for a directory service.
We use this computable shared secret as a key-encrypting-key to
provide for IP packet based authentication and encryption. Thus
we call a**ij mod p the long-term secret, and derive from it a key
Kij. Kij is used as the key for a shared-key cryptosystem (SKCS)
like DES or RC2. An important point here is that Kij is an impli-
cit pair-wise shared secret. 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
secret Kij.
Kij is derived from aij mod p by taking the low order key-size
bits of aij mod p. Since a**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-172
bits.
We use Kij to encrypt a transient key, which we call Kp. Kp is
then used to encrypt an IP packet or collection of packets. This
is done in order to limit the actual amount of data in the long-
term key. Since we would like to keep the long-term key for a re-
latively long period of time, say one or two years, we dont en-
crypt the actual IP data traffic in key Kij. Instead we only en-
crypt transient keys in this long-term key, and use the transient
keys to encrypt 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, like one year.
Thus the first time an IP source I, which has a secret value i,
needs to communicate with IP destination J, which has a secret
value j, it computes the shared secret aij mod p. It can then
dervive from this shared secret the long-term key Kij. IP source
I then generates a random key Kp and encrypts this key using Kij.
It encrypts the IP packet (header and data) in key Kp. It sends
the encrypted IP packet, the encrypted key Kp, encapsulated in an
outer IP header with the same source and destination addresses,
and therefore the outgoing packet looks like,
IP header with destination addresses I and J,
protocol type SKIP_ENCRYPTED
IP data ,
SKCS Algorithm Identifier and key size for Kij (1 byte)
SKCS Algorithm Identifier and key size for Kp (1 byte)
Kp encrypted in Kij (8-16 bytes)
Message Indicator (8 bytes)
Encrypted IP Hdr and Data portion.
In order to prepare this packet for emission on the outbound side
of IP node I, no communication was necessary with IP node J.
Also, since Kij is used as the key for a SKCS, the length of en-
crypted key Kp is padded up to the block size of a shared-key ci-
pher (typically 8 bytes), as opposed to the block size of a
public-key cipher (typically 64-128 bytes), which would have been
the case if RSA certificates had been used in conjunction with
in-band signalling of the packet encryption key.
When IP node J receives this packet, it also computes the shared
secret Kij and caches it for later use. 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 tran-
sport entity or another outbound interface.
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 Ini-
tialization 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 can be
64 bits also).
If the source IP node (I in this case) decides to change the
packet encryption key Kp, the receiving IP node 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, and
this is a shared-key cryptosystem operation. Thus, without re-
quiring communication between trasnsmitting and receiving ends,
and without necessitating the use of a public-key operation, the
packet encrypting key can be changed by the transmitting side.
Since DH certififcates are used, the nodes themselves have no
public-key signature algorithm. This is not a major problem,
since signing on a per-packet basis using a public- key cryp-
tosystem is too cumbersome in any case. The integrity of the
packets is determined in a pairwise fasion using a SKCS.
In order to keep the amount of data encrypted in any given key to
be less than 232 (assuming a 64-bit block cipher) at T1 speeds of
1.5 Mbits/sec, the packet encryption key will need to change
roughly every six hours. This results in the amount of key ma-
terial encrypted in the long-term key in a years to be roughly
24K bytes, well under the 232 limit that would necessitate chang-
ing the long-term key more frequently than a year.
2.1 Integrity-Only Protection
SKIP may be used to provide for packet integrity in the absence
of packet confidentiality. This can be done by computing a
message-digest over the header and data portions which need to be
integrity protected, and encrypting this message-digest directly
using key Kij. Since the message-digest is a small amount of in-
formation, it is not necessary to use a two-level keying struc-
ture to encrypt the message-digests. The protocol field in the IP
header will identify whether the message is SKIP_ENCRYPTED (as in
Section 2.0) or SKIP_AUTHENTICATED.
In case it is SKIP_AUTHENTICATED, the SKIP protocol header will
contain algorithm identifiers for the hash algorithms and the Kij
encryption algorithm (1 byte each), followed by the encrypted
message-digest (8-20 bytes).
2.2 Playback Considerations
This key-management scheme does not provide for any level of
playback protection for the datagrams themselves. Most of the
transport protocols deal with playbacks at the datagram layer
anyway. For example, TCP does sequencing of IP packets. Therefore
it isn't necessary to provide for this functionality at the da-
tagram layer.
If playback protection is important for a given application, then
it needs to be built on top of the secure datagram protocol.
Since the key-management itself is a zero- message protocol, it
isn't meaningful to talk about replay attacks on the key-
management algorithm itself.
2.3 Intruder in the middle attacks
Unauthenticated Diffie-Hellman is susceptible to an intruder in
the middle attack. To overcome this, authenticated Diffie- Hell-
man schemes have been proposed, that include a signature opera-
tion with the parties' private signature keys.
SKIP is not susceptible to intruder in the middle types of at-
tacks. 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 values belong to. Diffie- Hellman certifi-
cates eliminate this possibility, without requiring any exchange
of messages between the two parties.
2.4 Storage of Cached 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 provide a hardware device to
compute, store and perform operations using these keys. This dev-
ice can ensure that there are no interfaces to extract the key
from the device.
2.5 Manual Keying
As an interim measure, in the absence of certification hiear-
chies, nodes may wish to employ manually exchanged keying infor-
mation. To handle such cases, the pair key Kij can be the key
that is 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 re-
latively 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.
3.0 Considerations for Datagram Multicast Protocols
It is possible to use this kind of scheme in conjunction with da-
tagram multicasting protocols like IP (or IPng) multicast [5].
However, this will require key-management awareness in the estab-
lishment and joining process of multicast groups.
This would work as follows. The notion of a group owner needs to
exist. When secure multicasting to multicast address M is re-
quired, a group membership creation primitive will need to estab-
lish the secret value, and provide the public value. So, for mul-
ticast address M, a randomly generated secret value m is created
by the group owner and the public value am mod p is computed.
Also associated with each group address M is a membership list of
addresses that are allowed to transmit and receive encrypted mul-
ticast datagrams to and from group address M.
The public value is distributed securely to the nodes that wish
to transmit to multicast address M. This is done by using the
pairwise secure datagram protocol described in section 2 above.
Thus nodes wishing to transmit to group address M acquire the
public value am mod p from the group owner in a secured datagram
from the group owner to the transmitting nodes. This value is
distributed in the form of a certificate that is "signed" (using
a SKCS) in the long-term pair-wise shared secret. This allows the
group creation primitive to establish lifetimes for the transient
secret value m and its corresponding public value.
Nodes wishing to receive encrypted datagrams sent to multicast
address M need to acquire the secret value m. This is done by
sending the request to join primitive to the group owner. If the
requesting node's address is part of the group's receive member-
ship, then the group owner will send the secret value m, and the
associated public value certificate in an encrypted packet, again
using the pairwise secure protocol described in Section 2 above.
Transmitting node I wishing to send to group address M will use
the value aim mod p to derive the key Kim. Transmitting nodes
don't need to know the secret value m; all they need to know is
the group public value am mod p, and knowing their own secret
value i can compute the shared secret aim mod p from which they
derive Kim. Kim is then used to encrypt the packet encrypting key
Kp. Since the receiving nodes know the group secret m, and the
public value ai mod p they can also compute Kim, and thereby de-
crypt the packet.
An advantage of this scheme is that only the keying information
is distributed in a pairwise fashion. The actual encrypted data
packet is sent using the standard multicast delivery mechanisms,
thereby allowing the same sort of network bandwidth efficiency
that is expected of a network layer multicast protocol when
operating over subnetworks which also support multicasting (like
ethernet, FDDI etc).
How the identity of the group owner is established and communi-
cated 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 facility can be defeat-
ed.
The scalability of this scheme is intended to be limited to a
moderate number of nodes, and not an extremely large number of
nodes. This is not a major limitation, because there is an obvi-
ous tradeoff between keeping a value secret and having it be
widely distributed.
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] and also by the European PASS-
WORD project can be used. Namely, there can be a Top Level Certi-
fying Authority(TLCA) which may well be the same the Internet
Policy Registration Authority (IPRA), Policy Certifying Authori-
ties (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 au-
thorization certificates, in order to properly track the owner-
ship of IP addresses. Since we would like to directly use IP ad-
dresses in the DH certificates, we cannot use the name subordina-
tion principles alone (as e.g used by PEM) in order to determine
if a particular CA has the authority to bind a particular IP ad-
dress to a DH public value.
We can still use the X.509/PEM certificate format, since the sub-
ject Distinguished Name (DN) in the certificate can be the ascii
decimal representation of an IP (or IPng) address.
Since the nodes only have DH public keys, which have no signature
capability, the nodes are themselves unable to issue certifi-
cates. 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 ad-
dresses over which it has jurisdiction. The CA has either an RSA
or DSA certificate issued by the PCA.
An authorization certificate will also contain information about
whether the CA to whom authority is being delegated can sub-
delegate that authority. The CA which has delegatable authority
over a range of IP addresses can delegate authority over part of
the range to a subordinate CA, by signing another authorization
certificate using its own private key. If the authority is non-
delegatable, then the CA cannot delegate authority for that range
of addresses.
The range of IP addresses are identified in the certificate in
the form of a list of IP address prefix, length pairs.
5.0 Conclusions
We have described a scheme, Simple Key- Management for Internet
Protocols (SKIP) that is particularly well suited to connection-
less datagram protocols like IP and its replacement candidates
like CLNP and SIPP. Both the protocol and computational overheads
of this scheme are relatively low. In-band signalled keys incur
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 chang-
ing packet encrypting keys requires no communication between
sending and receiving nodes and no establishment of a pseudo ses-
sion state between the two sides is required.
In many ways the key-management scheme here has structural simi-
larities with the scheme used by PEM [1]. Both use the concept of
an inter-change key (in our case that is the pair key Kij) and
data encrypting keys (the packet encryption keys Kp). By using
the implicit shared secret property of long-term DH public
values, and treating the resulting keys as keys for a SKCS, we
have reduced the protocol overhead substantially as compared to
the overhead of PEM when used in conjunction with an asymmetric
key- management system.
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.
References
[1] Internet PEM RFCs 1421-1424
[2] A Aziz, W Diffie, "Privacy and Authentication for Wire-
less 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
[5] S. Deering, "IP Multicast", Ref needed
[6] S. Kent, "Certificate Based Key Management," RFC 1422 for
PEM