IPSEC Working Group Ashar Aziz
INTERNET-DRAFT Tom Markson
Hemma Prafullchandra
Sun Microsystems, Inc.
Expires in six months December 21, 1995
Simple Key-Management For Internet Protocols (SKIP)
<draft-ietf-ipsec-skip-06.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed to
to the working group mailing list (ipsec@ans.net) or to the authors.
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet-Drafts draft documents are valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
draft-ietf-ipsec-skip-06.txt [Page 1]
INTERNET-DRAFT SKIP December 21, 1995
Abstract
There are occasions where it is advantageous to put authenticity and
privacy features at the network layer. The vast majority of the privacy
and authentication protocols in the literature deal with session
oriented key-management schemes. However, many of the commonly used
network layer protocols (for example, IPv4 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 IPv4 or IPv6.
SKIP has been designed to work with the IP Security Protocols AH and ESP
[8, 9, 10] which are specified for both IPv4 and IPv6.
draft-ietf-ipsec-skip-06.txt [Page 2]
CONTENTS
Status of this Memo................................. 1
Abstract............................................ 2
1. Simple Key-Management for Internet Protocols........ 3
1.1 Manual distribution of Kij.................... 5
1.2 Zero-Message Master Key Update Algorithm...... 5
1.3 Independence from Cryptographic
Algorithms.................................... 7
1.4 High Availability and Load Balancing using
SKIP.......................................... 7
1.5 Intermediate Authentication with End-to-End
security using SKIP........................... 8
1.6 Attacks that the protocol guards against...... 9
1.6.1 Intruder in the Middle Attacks 9
1.6.2 Known Key Attacks 9
1.6.3 Clogging Defense 10
1.7 Naming, Name Spaces and Master Key-IDs........ 10
1.8 The SKIP Header............................... 13
1.9 Deriving Keys for Packet Encryption and
Authentication................................ 16
1.10 SKIP for Authentication....................... 17
1.10.1 Scope of MAC computation 18
1.11 SKIP for Encryption........................... 18
1.12 SKIP with combined transforms................. 18
- i -
1.13 Generic use of SKIP header.................... 18
2. Security Considerations............................. 19
2.1 Generating Random Keys........................ 19
2.2 Key Update.................................... 19
2.3 Choosing Key Strengths........................ 20
2.4 Forward Secrecy............................... 20
3. Informational Section............................... 20
3.1 SKIP with AH.................................. 21
3.2 SKIP with ESP................................. 22
3.3 SKIP with AH and ESP.......................... 23
4. Assigned Numbers.................................... 24
4.1 SKIP protocol number.......................... 24
4.2 SKIP SPI value................................ 25
4.3 Name Space Identifier (NSID) Assignments...... 25
4.4 Assigned Algorithm Numbers.................... 25
5. Recommended Parameters and Implementation Notes..... 26
5.1 n Update Frequency............................ 26
5.2 SKIP with the Certificate Discovery
Protocol...................................... 27
5.3 Recommended g & p values...................... 27
5.3.1 Prime generation method 27
5.3.2 Diffie-Hellman Parameters for 1024
bits Modulus 28
- ii -
5.3.3 Diffie-Hellman Parameters for 2048
bits Modulus: 29
6. Conclusions......................................... 30
Acknowledgements.................................... 31
References.......................................... 32
Author's Address(es)................................ 34
- iii -
INTERNET-DRAFT SKIP December 21, 1995
1. Simple Key-Management for Internet Protocols
In order to implement SKIP each IP based source and destination shall
have an authenticated Diffie-Hellman (DH) [4] public value. This public
value may be authenticated in numerous ways. Some possibilities for
authenticating DH public values is 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 may be found in [23]. In the discussion
below we focus on IP nodes, although user oriented keying is possible
and is further described in section 1.7.
Thus each IP source or destination I has a secret value i, and a public
value g^i mod p. Similarly, IP node J has a secret value j and a public
value g^j mod p.
Once n certificates are assigned to n IP nodes, O(n^2) mutually
authenticated pairwise keys arise, simply as a result of the public
value authentication process. This is because each pair of IP source
and destination I and J can acquire a mutually authenticated shared
secret g^ij mod p. The symmetric keys derivable from these shared
secrets require no setup overhead, except for the authenticated public
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 [19].
This computable shared secret is used as the basis for a key-
encrypting-key to provide IP packet based authentication and encryption.
Thus we call g^ij mod p the long-term secret, and derive from it a key
Kij. Kij is used as the key for a block Symmetric Key CryptoSystem
(SKCS) like DES, RC2, IDEA, and such.
Kij is derived from g^ij mod p by taking the low order key-size bits of
g^ij mod p. Since g^ij mod p should minimally be 512 bits and for
greater security should be 1024 bits or more, we can always derive
enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are
draft-ietf-ipsec-skip-06.txt [Page 3]
INTERNET-DRAFT SKIP December 21, 1995
typically in the range of 40-256 bits.
The important point here is that Kij is an implicit pairwise shared key.
It does not need to be sent in ANY packet or negotiated out-of-band. The
destination IP node can compute this shared key (Kij) 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/authenticate an IP packet or a
collection of packets. This is done in order to limit the actual amount
of data encrypted using the long-term key Kij. Since 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 we only encrypt
transient keys in this long-term key, and use the transient keys (Kp) to
encrypt/authenticate IP data traffic. This limits the amount of data
protected using the long-term key to a relatively small amount even over
a long period of time, since keys (Kp) represent a relatively small
amount of data. Because Kij is used to only encrypt other keys, and not
traffic, it is referred to as a master key.
[Note: For the sake of simplicity, the key Kp is described in this
section as a packet encryption and/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.9]
The first time a source I, which has a secret value i, needs to
communicate with destination J, which has a public value g^j mod p, it
computes the shared secret g^ij mod p. It then derives from this shared
secret the master key Kij. The source I then generates a random key Kp
and encrypts this key using Kij. The Kij and Kp keys are used as keys
for a symmetric key algorithm.
Note: In order to prepare this packet for transmission to node J, no
communication was necessary with node J. When node J receives this
packet, it also computes the shared secret Kij and caches it for later
use. (In order to do this, if it did not already possess I's
authenticated DH public value, it may have 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, which it then delivers
to the appropriate handler which is either a local transport entity or
another outbound interface.
draft-ietf-ipsec-skip-06.txt [Page 4]
INTERNET-DRAFT SKIP December 21, 1995
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/authenticating keys can be changed by the transmitting side
and discovered by the receiving side.
1.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 that are manually established when
SKIP is being used.
Since manual re-keying is a slow and awkward process, it still makes
sense to use the two level keying structure, and encrypt the packet
encryption key Kp using the manually established master key Kij. This
has the same benefit as before, namely it avoids over-exposing the
master key, since it is advantageous to maintain the master key over
relatively long periods of time. This is particularly true for high-
speed network links, where it is easy to encrypt large amounts of data
over a short period of time.
Because of the separation of master keys (the key Kij) and traffic
encryption keys (packet encryption key Kp), the SKIP scheme makes it
possible to automatically update traffic encryption keys even when
relying on manual master key distribution.
1.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 re-use of compromised traffic authentication keys as well as to
provide coarse-grain playback protection of data traffic. In the event
that a particular traffic authentication key is compromised (for
whatever reason) its re-use is prevented by updating the implicit master
key Kij and by never re-using a master key.
This counter can easily be constructed in a stateless manner as the
number of time-units since an agreed upon start time. The time units
draft-ietf-ipsec-skip-06.txt [Page 5]
INTERNET-DRAFT SKIP December 21, 1995
can be fairly coarse, such as hours. This only requires loosely
synchronized clocks to within an hour. Such coarse grain synchronization
is required in any case for any scheme that uses public key
certificates, in order to check certificate validity information.
Recommended time units/counter update frequency and the agreed upon
start time is specified later in the document.
Once the counter has moved forward, packets encrypted with the help of
counter values that differ by more than 1 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.8.
The counter n is computed as described in section 5.1. The n'th master
key is computed using the following function:
Kijn = h(Kij | n | 01h) | h(Kij | n | 00h)
where h() is a pseudo-random, one-way hash function, for example, MD5
[13]. For version 1 of SKIP, the one-way function MUST be 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 one 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
g^ij 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 hash +------------------------+
| Kij (MSB first) | n (32 bits) |00| ========> | Low 128 bits of Kijn |
+-----------------+-------------+--+ +------------------------+
+-----------------+-------------+--+ MD5 hash +------------------------+
| Kij (MSB first) | n (32 bits) |01| ========> | High 128 bits of Kijn |
+-----------------+-------------+--+ +------------------------+
draft-ietf-ipsec-skip-06.txt [Page 6]
INTERNET-DRAFT SKIP December 21, 1995
1.3 Independence from Cryptographic Algorithms
Although the descriptions above have been presented using the
cryptographic constructions of classic Diffie-Hellman (exponentiations
over a prime field) the protocols 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. Here we distinguish
between a public key agreement system and a public key cryptosystem
which has the trapdoor property (for example, RSA).
Examples of cryptographic constructions, other than exponentiation over
a prime field, that can be used to provide the same public key agreement
property are constructions that employ elliptic curves over finite
fields [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 (e.g. secure DNS).
1.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/public value
pair. These nodes may all have different IP addresses, as long as the
destination Master Key-ID is the same, since that is what is used to
identify the master keys. Note: it is far easier and simpler to
configure a set of nodes to share the same long-term secret, than it is
to dynamically share transient session keys between a set of nodes.
[The notion of Master Key-IDs, and how they differ from the source and
destination IP addresses, is explained in section 1.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/authenticated IP traffic. The standard
draft-ietf-ipsec-skip-06.txt [Page 7]
INTERNET-DRAFT SKIP December 21, 1995
dynamic IP routing facilities provide for high-availability and load-
balancing. No new protocol is required in order to achieve these goals.
Should one of these intermediate nodes (or their associated network
links) fail, IP will automatically route packets through the remaining
set of nodes, and these re-routed IP packets will remain decryptable by
the other members of the redundant set. There is no limit to the number
of nodes/links that can be configured in such a redundant configuration.
1.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], e.g. 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 MAY 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, e.g. mail or file servers, etc.
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 verifies, forward the packet
unmodified to its destination.
Such a scheme has the benefit of end-to-end encryption/authentication of
IP traffic, while still maintaining cryptographic checks at a security
perimeter defined by the intermediate device (e.g. 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.
draft-ietf-ipsec-skip-06.txt [Page 8]
INTERNET-DRAFT SKIP December 21, 1995
1.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 we describe a well known category of
attacks on cryptographic protocols, and show how SKIP defeats those
attacks.
1.6.1 Intruder in the Middle Attacks
Unauthenticated Diffie-Hellman is susceptible to an intruder in the
middle attack. To overcome this, authenticated Diffie-Hellman schemes
have been proposed, that include a signature operation with the parties'
private signature keys.
SKIP is not susceptible to intruder in the middle types of attacks. This
is because the Diffie-Hellman public parameters are long-term and
authenticated. Intruder in the middle attacks on Diffie-Hellman assume
that the parties cannot determine who the public Diffie-Hellman keys
belong to. Authenticated Diffie-Hellman 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).
1.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 re-use of compromised keys to send forged
traffic.
This is because even if a particular traffic key Kp is compromised, this
does not tell an attacker anything about the current implicit key Kijn,
and therefore the attacker would not be able to compute the encryption
of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an
attacker cannot re-use past compromised keys Kp to any advantage.
Also, even if all the packet encryption/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/chosen Kp keys as long as the key-encryption
algorithm is practically secure against a known/chosen text attack. To
the extent that the key-encryption algorithm is secure against a
draft-ietf-ipsec-skip-06.txt [Page 9]
INTERNET-DRAFT SKIP December 21, 1995
known/chosen text attack, SKIP is secure against a known/chosen key
attack.
1.6.3 Clogging Defense
An attacker may attempt to mount a denial-of-service attack on a node
implementing SKIP, by trying to force it to perform an unacceptably high
number of computationally expensive operations, e.g. the Diffie-Hellman
computation.
In order to prevent denial-of-service attacks on the SKIP scheme
described above, a recommended solution is to pre-compute and cache
master keys Kij, based either on usage patterns of the machine or
through administrative action. In case a clogging attack occurs, the IP
node will still be able to communicate with the set of machines for
which it has pre-computed master keys, it will simply stop computing new
master keys. This allows business as usual activities to carry on, even
while a clogging attack occurs, since there are no computationally
expensive (e.g. public key) operations required to key or re-key with an
IP node once the master key Kij has been computed.
The keys belonging to administrators SHOULD always be in the pre-compute
cache used to prevent this form of denial-of-service attack. This allows
the administrator to securely add more principals to the pre-compute
cache, even during a clogging attack.
1.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 Master Key-IDs will be
used for looking up authenticated public values instead of the source
and/or destination IP addresses. These fields also identify which name
space is being used for Master Key-IDs.
[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.]
Master Key-IDs effectively decouple the identification of a master key
for purposes of key lookup and access control from issues of network
topology, routing and IP addresses. As one example, this allows IP nodes
to use different IP addresses for routing and key lookup purposes.
draft-ietf-ipsec-skip-06.txt [Page 10]
INTERNET-DRAFT SKIP December 21, 1995
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 Master Key-ID, and the second NSID refers to the name space of
the destination Master Key-ID.
The length of the Master Key ID is implicit in the choice of the NSID.
There are two commonly used lengths, 32 bits and 128 bits. A 32 bit
Master Key-ID may be used to identify, e.g., IPv4 addresses or
XOPEN/POSIX user ids. A 128 bit Master Key-ID may 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 Master Key-ID 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 Distinguished Names, etc. Another way is to use some
unique identifier as the keyid. Examples of this include POSIX/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 which compares all the names in the name space to their
message digests. Names which are sensitive and taken from a small name
space SHOULD NOT 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 (e.g.
Certifying Authority, secure directory server, trusted introducer, etc.)
to ensure a secure binding between a name and a public value. The
encoding for unsigned DH public values is beyond the scope of this
document and is defined separately [20].
draft-ietf-ipsec-skip-06.txt [Page 11]
INTERNET-DRAFT SKIP December 21, 1995
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 will need to be able to reverse lookup a
certificate (or equivalent information) using the Master Key ID. There
are no security issues in the binding between a name in its native name
space, and the message digest derived Master Key ID, since there is a
cryptographic binding between two. The collision resistance property of
a message digest function provides this security. Therefore reverse-
lookup is primarily a database issue, and not a secure binding issue.
If an NSID field is zero, then the corresponding Master Key-ID is
absent. In this case, the corresponding Master Key-ID defaults to the
source or destination IPv4 or IPv6 address respectively.
Although a Master Key-ID MAY be allocated out of the IPv4/v6 address
spaces, it is never used for IP routing purposes. Instead, it is used as
a semi-permanent identifier for a master key.
To illustrate one possible 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 Diffie-Hellman public value
lookup occur based on the source Master Key-IDs.
Still other examples include mobile users, identified in any name space,
who can securely access network data and services from many different IP
nodes. This is because key lookup and access control will be based on
their native names (identified using the Source Master Key-ID), and not
the IP address of the node from which they are performing the network
access. These users may carry around their private keys in smart cards,
or alternatively, these private keys may be distributed over the network
encrypted in a per-user password. Users may be identified using their
DNS names, POSIX/XOPEN user ids, X.500 Distinguished Names, etc.
Similarly Destination Master Key-IDs can serve many purposes as well.
When the Destination Master Key-ID 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 Master Key-ID, an intermediate
node which is encrypting/decrypting SKIP packets for multiple machines
would have no way of knowing whether a received packet should be
uncompressed/decrypted/authenticated or just forwarded. A destination
Master Key-ID enables an encrypting intermediate node (e.g., router or
firewall) to determine whether to process a packet or simply forward it.
draft-ietf-ipsec-skip-06.txt [Page 12]
INTERNET-DRAFT SKIP December 21, 1995
The destination Master Key-ID is present when the Destination NSID is
non-zero.
On an end node, the Destination Master Key-ID can be used to distinguish
between multiple users on the same IP node.
If the Source NSID is non-zero, the source Master Key-ID 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 Master Key-ID MUST be
used for public value lookups and the destination IP address MUST NOT be
used.
Note: A node MUST NOT process a packet which has a destination Master
Key-ID that does not match a local Master Key-ID even if the destination
IP address matches.
Some commonly used name spaces have been assigned NSIDs. These are
specified in section 4.3 in the "Assigned Numbers" section below. More
name spaces will be registered through Internet Assigned Numbers
Authority (IANA).
1.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.
draft-ietf-ipsec-skip-06.txt [Page 13]
INTERNET-DRAFT SKIP December 21, 1995
SKIP Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rsvd | Source NSID | Dest NSID | NEXT HEADER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kij Alg | Crypt Alg | MAC Alg | Comp Alg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kp encrypted in Kijn... (typically 8-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 4 bits following the version are
reserved for future versions of SKIP, and will be set to zero by all
SKIP v1 implementations and ignored. A non-zero Source NSID indicates
that a packet contains a source Master Key-ID. The value of the Source
NSID indicates the name space from which the Master Key-ID is derived. A
non-zero Dest NSID indicates the SKIP header contains a destination
Master Key-ID. The value of the Dest NSID indicates the name space from
which the Master Key-ID 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 will
usually indicate ESP or AH. But the NEXT HEADER may be any protocol
which requires keying material. Examples of protocols other than AH/ESP
that may use SKIP are given later.
The "Counter n" field is a 32 bit field which is used for coarse grain
playback protection and to prevent compromised key re-use.
The 1 byte field, Kij algorithm identifies the algorithm used to encrypt
Kp. This algorithm always takes the low order bits of DH shared secret
as the key to encrypt/decrypt Kp.
The Kij algorithm MUST be a block cipher algorithm. It is always used in
CBC mode to encrypt Kp, which is a variable number of bits. The IV for
draft-ietf-ipsec-skip-06.txt [Page 14]
INTERNET-DRAFT SKIP December 21, 1995
the CBC mode encryption MUST always be set to all zeros (IV=0). So,
e.g., for 64-bit IV algorithms, such as DES-CBC, the IV is 64 bits of
zero (0).
The input to the key encryption algorithm is padded with a random fill
up to a multiple of the block size of the key-encryption algorithm. The
length of Kp is derived from knowledge of the encryption/MAC algorithms.
The low order key-length bits of the decrypted output are used as Kp.
The Crypt Alg and MAC Alg specify algorithms used by the interior
protocol for encryption and authentication. These algorithms are
specific to the protocol which will use them and the transforms it
specifies. In general, the MAC Alg specifies the algorithm used to
calculate a MAC and the 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 which provides both encryption and MAC
computation.
The Comp Alg field specifies the algorithm that was used to compress
packets prior to encryption/authentication. A non-zero Comp Alg field
indicates that compression was performed on the plaintext, prior to
encryption/authentication. The value of the Comp Alg field indicates the
compression algorithm that was employed.
The values for the algorithm fields will be described later in this
document.
The field "Kp Encrypted in Kijn" is the encrypted Kp which has been
encrypted with Kijn using the Kij algorithm.
The source Master Key-ID field contains the Master Key-ID of the sender.
This field is only present if the Source NSID is non-zero.
The destination Master Key-ID field contains the Master Key-ID of the
intended SKIP receiver. This field is only present if the Dest NSID is
non-zero.
In a specific use of the SKIP header, a field may not be relevant, and
its value will be denoted as RESERVED. All RESERVED fields MUST be set
to zero in the SKIP header and ignored.
draft-ietf-ipsec-skip-06.txt [Page 15]
INTERNET-DRAFT SKIP December 21, 1995
1.9 Deriving Keys for Packet Encryption and Authentication
In general, packets may 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 that is decrypted from the packet header is not used directly to
encrypt/decrypt or authenticate the packet. Rather, it is used to derive
two separate keys named E_kp and A_kp, where A_kp is used as the
authentication key and E_kp is used as the encryption key. E_kp and
A_kp are related to the Kp decrypted from the packet header as follows:
E_kp = h(Kp | 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, for example, MD5.
For this version of SKIP, the one-way function MUST be MD5. The "|"
above specifies concatenation, in the same manner as described in
section 1.2 above. 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 does not compromise any information about the
other key, because of the one-way property of MD5. This allows, e.g.,
weak encryption keys to be used with strong authentication keys. Should
E_kp be compromised, nothing at all is revealed about A_kp, and vice
versa.
The actual number of key bits used is algorithm dependent. If the
algorithms require less than 256 bits, then the low order key-size bits
of the output of the pseudo-random one-way functions are used as the
actual keys. If less than 128 bits of encryption key is required, then
only the MD5(Kp | 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 will be used with SKIP.
An implementation will use the maximum of the key-lengths indicated by
Crypt Alg and MAC Alg when determining the length of the actual Kp that
will be decrypted from the SKIP header. For example, if Crypt Alg
draft-ietf-ipsec-skip-06.txt [Page 16]
INTERNET-DRAFT SKIP December 21, 1995
specifies a 64-bit encryption key length, the MAC algorithm specifies a
128-bit authentication key length, then the length of Kp will be 128
bits. This 128-bit Kp will be input to the functions specified above to
generate E_kp, which will be low-order 64-bits of the E_kp function, and
A_kp, which will be low-order 128 bits of the A_kp function.
The length of the Encrypted Kp in the packet header is derived from the
length of Kp and the key encryption algorithm, as indicated by Kij Alg.
For example, if the length of Kp as discussed above turns out to be,
say, 120 bits, and the key encryption algorithm (as specified by Kij
Alg) is a 64-bit block cipher, then the length of the encrypted Kp in
the SKIP header will be 128 bits, of which the upper 8 bits will be
random fill. The random fill bits MUST be 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 would be 128 bits, with upper 8 bits set
to zero.
Implementation Note: It is not necessary to perform a complicated set of
conditional rules in order to determine the length of the encrypted Kp
in an implementation of SKIP. A fast and simple way of doing this is to
have a table indexed by the algorithm number, which produces the key
lengths required for that algorithm. Since this table will be small
enough to fit in most caches, this can result in a fast way to determine
the appropriate encrypted key length in order to perform SKIP header
decoding.
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 and/or authentication MUST be
derived separately as specified above. Kp is NEVER used directly to
authenticate or encrypt traffic.
1.10 SKIP for Authentication
This section describes how SKIP compliant implementations use SKIP
originated keys to achieve packet authentication.
In order to achieve authentication in the absence of privacy, SKIP
compliant implementations use the key A_kp to compute a Message
Authentication Code (MAC) over the packet and invariant clear header
fields. The term "MAC" is synonymous with the term "Authentication Data"
in RFC 1826.
draft-ietf-ipsec-skip-06.txt [Page 17]
INTERNET-DRAFT SKIP December 21, 1995
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.
1.10.1 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.
1.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 will be mapped to standard
transforms such as [15]. These transforms will also contain information
such as Initialization Vectors (IVs) or Message Indicators (MIs).
As always, Kij Alg identifies the encryption algorithm used to encrypt
Kp.
1.12 SKIP with combined transforms
For transforms which combine encryption and authentication such as ESP
using Keyed MD5 with DES-CBC, only an one header, ESP in this case, is
needed. The Crypt Alg in the SKIP header will indicate the transform
and A_kp would be used for authentication and the E_kp (as discussed in
section 1.9) would be used for encryption. The MAC Alg field MUST
contain the same value as the Crypt Alg field, since this would be a
combined authentication/encryption transform.
1.13 Generic use of SKIP header
The SKIP header may be used for any protocol which requires keying
material. The next header in the SKIP header would specify this
protocol. A protocol being encapsulated SHOULD have a reserved value
which indicates that the keying material to be used is in the SKIP
header. An example of this kind of reserved value is SKIP_SPI which is
used by the AH and ESP protocols. The protocol will define how the
Crypt, MAC and Compression algorithms will be used. Kijn will be used to
draft-ietf-ipsec-skip-06.txt [Page 18]
INTERNET-DRAFT SKIP December 21, 1995
encrypt Kp.
2. Security Considerations
2.1 Generating Random Keys
One of the most important considerations in a software only
implementation of SKIP is to design an unpredictable pseudo-random
number generation procedure. Weak and unpredictable sources of random
number generation would be catastrophic to the security of SKIP or
indeed any scheme that implements cryptography, no matter what the
length of key and choice of encryption algorithm might be.
In particular, common mistakes that MUST be avoided in implementing this
unpredictable random number generator is to use values like the current
process id, the host id or ethernet address, the current time of day or
some simple combination of these as the sole input to generate a
cryptographic key. These values are really not all that unpredictable.
It must be ensured that there are at least as many truly random bits
used in the key production phase as are specified in the chosen key
length for that algorithm. None of these commonly used sources by
themselves provide sufficiently many random bits for commonly used
cryptographic algorithms.
For more information on the subject of generating random keys, RFC 1750
[12] is recommended reading.
2.2 Key Update
The best way to frustrate cryptanalysis of encryption and authentication
keys is to periodically update the key used to encrypt or authenticate
packets. Whereas the exact frequency with which keys are updated SHOULD
be configurable based on site policies, some recommended parameters are
provided.
The traffic encryption/authentication key SHOULD be updated for every 10
Mbytes of protected traffic, or once every 2 minutes, which ever one
results in a more frequent update policy.
The traffic encryption/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
Kijns. Kp MUST be randomly generated for each end destination, and for
draft-ietf-ipsec-skip-06.txt [Page 19]
INTERNET-DRAFT SKIP December 21, 1995
different principals on the same node.
2.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 128 bits strength, then
the key encryption key MUST be of strength 128-bits or greater. It isn't
sensible to choose strong traffic protection algorithms and then encrypt
the keys using weaker algorithms.
Similarly, when using 128-bit symmetric keys, the modulus lengths for
classic Diffie-Hellman (used to derive the master keys) MUST be 1024
bits or greater. The exponent size for classic Diffie-Hellman for
symmetric master key sizes of 128 bits MUST be 256 bits or greater.
Also, when 128-bit keyed MD5 is used, then the key-encryption algorithms
SHOULD have strength equal to or greater than 128-bits. For
interoperability purposes, use of Algorithm #2 (3 key triple DES-EDE-
CBC) is deemed mandatory to implement for key encryption (Kij Alg), when
also implementing keyed MD5 as specified in RFC 1829 for traffic
authentication purposes, or any 128-bit strength traffic encryption
algorithm (e.g. 2 or 3 key triple DES or IDEA).
2.4 Forward Secrecy
Perfect forward secrecy 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
may be minimized by minimizing the longevity of any particular master
key. Future extensions to the base SKIP protocol may 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.
3. Informational Section
This section gives examples of how SKIP is used with various IP security
encapsulation protocols such as AH and ESP.
draft-ietf-ipsec-skip-06.txt [Page 20]
INTERNET-DRAFT SKIP December 21, 1995
3.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:
+-------------+----------+----------+-------------------------------+
| IPv4 Header | SKIP Hdr | Auth Hdr |Inner Protocol(e.g.IP, TCP,UDP)|
+-------------+----------+----------+-------------------------------+
IPv4 with SKIP/AH Example
The detailed protocol encoding for SKIP followed by an AH header is
shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clear IP Header protocol = SKIP... (typically 20-bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Counter n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP hdr
| Kij Alg | RESERVED | MAC Alg | Comp Alg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Kp encrypted in Kijn... (typically 8-16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Next Header | Length | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SKIP_SPI | AH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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, e.g., RFC 1828 [14], as an
example of an authentication transform.
draft-ietf-ipsec-skip-06.txt [Page 21]
INTERNET-DRAFT SKIP December 21, 1995
3.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 Header | SKIP Hdr | ESP Hdr |Inner Protocol (e.g.IP,TCP,UDP)|
+-------------+----------+----------+-------------------------------+
IPv4 with SKIP/ESP Example
The detailed protocol encoding of SKIP combined with ESP is illustrated
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clear IP Header protocol = SKIP... (typically 20-bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=ESP| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Counter n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
| Kij Alg | Crypt Alg | RESERVED | Comp Alg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Kp encrypted in Kijn... (typically 8-16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| SPI=SKIP_SPI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
| Opaque Transform Data, variable Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
The reserved SPI SKIP_SPI in the ESP header indicates that algorithm
information and keying material is contained in the preceding SKIP
header. We assume that this reserved SPI has been assigned symbolic
value SKIP_SPI. The SKIP_SPI value is specified later in this document.
The Source and Dest NSIDs are assumed to be zero, meaning that Master
Key-IDs are absent.
draft-ietf-ipsec-skip-06.txt [Page 22]
INTERNET-DRAFT SKIP December 21, 1995
The Opaque transform data is defined by the particular transform (such
as DES-CBC in RFC 1829). This data will normally contain the encrypted
data and transform specific information such as the IV.
Kij Alg identifies the encryption algorithm used to encrypt Kp. Kp is
used to derive the key E_kp (as specified above) which is used to
encrypt the payload.
3.3 SKIP with AH and ESP
SKIP can be used with combined AH/ESP modes. The Next protocol field in
the SKIP header would be AH and the Next protocol field in AH header
would ESP.
+----------+----------+----------+---------+------------------------------+
| IPv4 Hdr | SKIP Hdr | Auth Hdr | ESP Hdr |Inner Protocol(e.g.IP,TCP,UDP)|
+----------+----------+----------+---------+------------------------------+
IPv4 with SKIP/AH/ESP Example
A_Kp would be used for authentication and E_kp (as discussed in section
1.9) would be used for encryption.
The following is an example of SKIP with AH and ESP. In Addition, the
use of Master Key-ID's is also demonstrated.
draft-ietf-ipsec-skip-06.txt [Page 23]
INTERNET-DRAFT SKIP December 21, 1995
SKIP Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clear IP Header protocol = SKIP... (typically 20-bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Counter n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Kij Alg | Crypt Alg | MAC ALG | Comp Alg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
| Kp encrypted in Kijn... (typically 8-16 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Master Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Destination Master Key-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Next=ESP | Length | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SKIP_SPI | Auth Hdr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length AH MAC, computed using A_kp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| SKIP_SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
| ESP transform data (e.g. IV), payload encrypted using E_kp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
4. Assigned Numbers
4.1 SKIP protocol number
SKIP has been assigned the protocol number 57 by the Internet Assigned
Numbers Authority (IANA). This is what will be in the "protocol" field
in the IP header, when the SKIP header follows the IP header.
draft-ietf-ipsec-skip-06.txt [Page 24]
INTERNET-DRAFT SKIP December 21, 1995
4.2 SKIP SPI value
For use with the AH & ESP protocols, the value of 1 has been assigned by
IANA for use with SKIP. Therefore SKIP_SPI as used in earlier sections
should be treated as equal to 1. This will be the value used in the SPI
fields of the AH & ESP protocols.
4.3 Name Space Identifier (NSID) Assignments
Some of the name spaces that may be used with SKIP are assigned
identifiers here. Other name space identifiers will be assigned by IANA.
NSID Value Name Space Master Key ID length
1 IPv4 Address Space 32-bits
2 POSIX/XOPEN User Ids 32-bits
3 IPv6 Address Space 128-bits
4 MD5 of DNS Names 128-bits
5 MD5 of ISO DN ASN.1 encoding 128-bits
6 MD5 of Arbitrary ASCII string 128-bits
7 802.x MAC Address 48-bits
8 MD5 of Principal's DH Pub Val 128-bits
9 MD5 of RFC-822 Mailbox Address 128-bits
10 MD5 of Bank Account # 128-bits
11 MD5 of NIS Name 128-bits
NSID values 1 through 11 are assigned as is described above. NSID
values 12 through 259 inclusive are reserved to IANA for future
allocation as Assigned Numbers. Such future allocation by IANA will
normally require that a public specification exist for the Name Space
obtaining such allocation. NSIDs in the range 250 through 255 inclusive
are reserved for private use among consenting parties. NSIDs in the
range 250 through 255 inclusive will hence only have local uniqueness
properties.
4.4 Assigned Algorithm Numbers
SKIP uses the following algorithms identifiers. Algorithm and type
identifiers are specified for each place in the protocol where algorithm
or type indicators are needed.
These fall into four categories. Algorithms for key-encryption (Kij
Alg), traffic encryption (Crypt Alg), traffic authentication (MAC Alg),
draft-ietf-ipsec-skip-06.txt [Page 25]
INTERNET-DRAFT SKIP December 21, 1995
and traffic compression (Comp. Alg).
Key-Encryption Algorithms (Kij Alg)
1 DES-CBC (IV = 0, random fill up to multiple of 64-bits)
2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits)
3 IDEA-CBC (IV = 0, random fill up to multiple of 64-bits)
Traffic Encryption Algorithms (Crypt Alg)
1 DES-CBC (specified in RFC 1829)
2 3 key (k1, k2, k3) Triple DES (EDE-CBC) (specified in RFC 1851)
MAC Algorithms (MAC Alg)
1 128-bit Keyed MD5 (RFC 1828)
2 DES-CBC MAC
3 Keyed SHA (RFC 1852)
Compression Algorithms (Comp Alg)
Reserved to IANA
IANA will assign the range 10-250 for the algorithm identifiers above.
The range 250-255 will remain reserved for use with proprietary
algorithms and will not be assigned by IANA. These values will only have
local uniqueness properties.
For interoperability purposes, RFCs 1828 and 1829 have been deemed as
mandatory to implement.
5. Recommended Parameters and Implementation Notes
5.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.
draft-ietf-ipsec-skip-06.txt [Page 26]
INTERNET-DRAFT SKIP December 21, 1995
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 above. A receiving node will independently compute n, and
check this against the value of n in the received SKIP header. If they
do not differ by more than 1, the packet is accepted. If they differ by
more than 1, the packet MUST be rejected, as this may be an attempt to
reuse a past compromised authentication key.
Since n is a 32 bit quantity, there is no practical danger of overflow
of n, and hence there is no need to ever reset n. n is a monotonically
increasing number, even across certificate updates.
Note that this doesn't require the use of fine-grain synchronized clocks
or a secure clock synchronization protocol. Nodes should by default have
clocks synchronized within an hour of each other. If they are not
synchronized even in this coarse-grain manner, then validating
certificates and CRLs becomes problematic.
5.2 SKIP with the Certificate Discovery Protocol
The Certificate Discovery Protocol [19] may be used to exchange SKIP
certificates. The Name field in the Name Record of Certificate
Discovery Protocol is the concatenation of the NSID and MKID values,
respectively. For example, for NSID=01, MKID=7f000001, the name would
be 017f000001.
5.3 Recommended g & p values
For interoperability, the values g and p in g^i mod p are specified
here, for various modulus lengths.
5.3.1 Prime generation method
The primes given below were generated using the following algorithm.
The prime generation method is given so it is possible to independently
verify how the primes were generated.
The prime generator is based on SHA.1, the FIPS 180.1 secure hash
algorithm. This takes the given seed as input and produces a 160-bit
output sequence in 20 bytes. These bytes are taken as a big-endian
number to produce a number n0 from 0 to 2^160-1.
draft-ietf-ipsec-skip-06.txt [Page 27]
INTERNET-DRAFT SKIP December 21, 1995
(I.e. n0 = 2^152 * byte0 + 2^144 * byte1 + ... + 2^8 * byte19 + byte20.)
Then, the seed is incremented, as a big-endian array of bytes, modulo
its size (i.e. the last byte is incremented, propagating carry if
necessary), and hashed again to produce n1, then n2, etc.
A number of arbitrary size may be constructed by concatenating N = n0 +
2^160 * n1 + 2^320 * n2 + .... To get a number no larger than 2^k, take
the low-order k bits of N, N mod 2^k. Obviously, if k is 1024, it is
only necessary to compute n0 through n6.
To generate a k-bit prime p (2^k > p >= 2^(k-1)), take t = N mod 2^(k-
2), i.e. a number with at most k-2 significant bits. Then add 2^(k-1),
to force the number into the desired range, and 2^(k-2), to force it
into the high half of the range. This extra refinement makes an attack
more expensive, without affecting the time required to do computations
mod p. Additional high-order 1 bits could be forced, but the
incremental benefit rapidly diminishes.
The resultant number t is used as the starting point in a search for a
suitable prime p. p is chosen to be the first number >= t such that p
is prime and (p-1)/2 is prime.
Because SHA.1 is a cryptographic hash, it is computationally infeasible
to find an input which has a given output. Indeed, there is no known
technique better than brute-force search to find an input which produces
an output with any special properties. Assuming that there is an
unknown class of primes which are easy to solve the discrete logarithm
problem for, this ensures that the chance of choosing a prime p which is
a member of that class is no better than random chance, regardless of
malice on the part of the party generating the prime.
The seed chosen is arbitrary, so was chosen for aesthetic reasons. It
is the 79 bytes of the ASCII representation of a quote by Gandhi:
"Whatever you do will be insignificant, but it is very important that
you do it."
5.3.2 Diffie-Hellman Parameters for 1024 bits Modulus
draft-ietf-ipsec-skip-06.txt [Page 28]
INTERNET-DRAFT SKIP December 21, 1995
Base (g):
0x02
Modulus (p) (MSB first):
0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD,
0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B,
0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C,
0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6,
0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B,
0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D,
0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43,
0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,
0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,
0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,
0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,
0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,
0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,
0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,
0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,
0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x2F, 0x78, 0xC7
5.3.3 Diffie-Hellman Parameters for 2048 bits Modulus:
draft-ietf-ipsec-skip-06.txt [Page 29]
INTERNET-DRAFT SKIP December 21, 1995
Base (g):
0x02
Modulus (p) (MSB first):
0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17,
0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05,
0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1,
0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7,
0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3,
0xD0, 0x07, 0xC6, 0xCB, 0x43, 0xA9, 0x94, 0xAD,
0xF7, 0x4C, 0x64, 0x86, 0x49, 0xF8, 0x0C, 0x83,
0xBD, 0x65, 0xE9, 0x17, 0xD4, 0xA1, 0xD3, 0x50,
0xF8, 0xF5, 0x59, 0x5F, 0xDC, 0x76, 0x52, 0x4F,
0x3D, 0x3D, 0x8D, 0xDB, 0xCE, 0x99, 0xE1, 0x57,
0x92, 0x59, 0xCD, 0xFD, 0xB8, 0xAE, 0x74, 0x4F,
0xC5, 0xFC, 0x76, 0xBC, 0x83, 0xC5, 0x47, 0x30,
0x61, 0xCE, 0x7C, 0xC9, 0x66, 0xFF, 0x15, 0xF9,
0xBB, 0xFD, 0x91, 0x5E, 0xC7, 0x01, 0xAA, 0xD3,
0x5B, 0x9E, 0x8D, 0xA0, 0xA5, 0x72, 0x3A, 0xD4,
0x1A, 0xF0, 0xBF, 0x46, 0x00, 0x58, 0x2B, 0xE5,
0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD,
0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B,
0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C,
0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6,
0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B,
0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D,
0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43,
0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,
0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,
0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,
0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,
0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,
0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,
0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,
0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,
0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x32, 0x0B, 0x3B
6. Conclusions
We have described a scheme, Simple Key-Management for Internet Protocols
(SKIP) that 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.
draft-ietf-ipsec-skip-06.txt [Page 30]
INTERNET-DRAFT SKIP December 21, 1995
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.
Acknowledgements
I would like to thank all of the people who helped make this draft
possible. (Any errors and shortcomings are only attributable to the
author.)
Whitfield Diffie for many helpful discussions on this subject. Geoff
Mulligan and Bill Danielson for reviewing this draft and providing
constructive suggestions. Martin Patterson for reviewing this draft, and
providing feedback and input based on extensive implementation and
testing.
Marc Dye for suggesting using name spaces other than IP addresses with
SKIP, and for the notion of a name space identifier.
Bob Hinden provided valuable suggestions, and created the first skeleton
SKIP document in the format of an Internet-Draft.
Hilarie Orman suggested the encapsulation scheme which is reflected in
this draft and provided other valuable input. Cheryl Madson suggested
using SKIP to encapsulate protocols such as OSPF and RIP and other
protocols that may need keying material well as other valuable input and
critique.
Ran Atkinson provided detailed critique and feedback, and helped greatly
in making this document consistent with the IP security encapsulation
and security architecture documents.
Jeff Schiller suggested improvements to the draft in order to facilitate
building interoperable implementations.
Two separate groups independently "cleanroom" implemented SKIP based on
early drafts and provided invaluable feedback: 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.
draft-ietf-ipsec-skip-06.txt [Page 31]
INTERNET-DRAFT SKIP December 21, 1995
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 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, Russ Housely.
References
[1] RFCs 1421-1424, Privacy Enhanced Mail
[2] A Aziz, W Diffie, "Privacy and Authentication for Wireless LANs",
IEEE Personal Communications, Feb 1994.
[3] W. Diffie, M. Wiener, P. Van Oorschot, "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
draft-ietf-ipsec-skip-06.txt [Page 32]
INTERNET-DRAFT SKIP December 21, 1995
[9] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995
[10] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995
[11] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D
draft-ietf-dnssec-secext-04.txt), Work In Progress
[12] D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommendations
for Security", RFC 1750, December 1994
[13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
1992
[14] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC
1828, August 1995
[15] P. Karn, P. Metzger, W. Simpson, "The ESP DES-CBC Transform", RFC
1829, August 1995
[16] J. Moy, "OSPF Version 2", RFC 1583, March 1994
[17] A. Menezes, "Elliptic Curve Public Key Cryptosystems", Kluwer
Academic Publishers, 1993
[18] R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, October,
1993
[19] Aziz, A., Markson, T., Prafullchandra, H., "Certificate Discovery
Protocol", (I-D draft-ietf-ipsec-cdp-00.txt), Work in Progress
[20] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned
Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh-
00.txt), Work in Progress
[21] Aziz, A., Markson, T., Prafullchandra, H., "SKIP Algorithm
Discovery Protocol", (I-D draft-ietf-ipsec-skip-adp-00.txt), Work in
Progress
[22] Aziz, A., Markson, T., Prafullchandra, H., "SKIP Extensions for IP
Multicast", (I-D draft-ietf-ipsec-skip-mc-00.txt), Work in Progress
[23] Aziz, A., Markson, T., Prafullchandra, H., "X.509 Encoding of
Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-x509-
00.txt), Work in Progress
draft-ietf-ipsec-skip-06.txt [Page 33]
INTERNET-DRAFT SKIP December 21, 1995
[24] Atkins, D., Stallings, W., Zimmerman, P., "PGP Message Exchange
Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress
Author's Address(es)
Ashar Aziz
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: ashar.aziz@eng.sun.com
Alternate email address: ashar@incog.com
Tom Markson
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: markson@incog.com
Alternate email address: markson@eng.sun.com
Hemma Prafullchandra
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: hemma@eng.sun.com
Alternate email address: hemma@incog.com
draft-ietf-ipsec-skip-06.txt [Page 34]
