[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 03 04 05 06

Internet Engineering Task Force               Ashar Aziz
INTERNET-DRAFT                                Sun Microsystems, Inc.
Expires in six months                         October 16, 1995





          Simple Key-Management For Internet Protocols (SKIP)
                     <draft-ietf-ipsec-skip-03.txt>



Status of this Memo

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. Future revisions of this document are
intended to become a standards track RFC in the area of key-management
for Internet protocols and applications. Comments should be sent to the
IP Security WG mailing list (ipsec@ans.net).

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-03.txt                        [Page 1]


                                CONTENTS


    Status of this Memo.................................   1

    Abstract............................................   2

1.  Overview............................................   3

    1.1   Simple Key-Management for Internet
          Protocols.....................................   5

    1.2   Manual distribution of Kij....................   8

    1.3   Zero-Message Master Key Update Algorithm......   8

          1.3.1   Zero Message Master key Update with
                  Diffie-Hellman   9

          1.3.2   Zero Message Master Key update with
                  Manual Keying   9

    1.4   Independence from Cryptographic
          Algorithms....................................  10

    1.5   Storage of Cryptographic Keys.................  10

    1.6   SKIP for High Availability and Load
          Balancing.....................................  11

    1.7   Attacks that the protocol guards against......  11

          1.7.1   Intruder in the Middle Attacks  12

          1.7.2   Known Key Attacks  12

          1.7.3   Anti-Clogging Defense  12

          1.7.4   Non-Goal: Perfect Forward Secrecy  13

    1.8   Naming, Name Spaces and Master Key-IDs........  13

    1.9   The SKIP Header...............................  16





                           - i -











    1.10  The relative order of compression, encryption
          and authentication............................  19

    1.11  Deriving Keys for Packet Encryption and
          Authentication................................  19

    1.12  SKIP for Authentication.......................  21

          1.12.1  SKIP with AH  21

          1.12.2  Scope of MAC computation  22

    1.13  SKIP for Encryption...........................  23

          1.13.1  SKIP with ESP  23

          1.13.2  SKIP with AH and ESP  24

          1.13.3  SKIP with combined ESP transforms  26

    1.14  Generic use of SKIP header....................  26

2.  SKIP for Multicast IP...............................  26

    2.1   Transient Multicast Groups....................  27

    2.2   SKIP for Broadcast/Permanent Multicast
          Groups........................................  30

          2.2.1   SKIP and RIPv2  31

3.  Algorithm Discovery.................................  32

4.  Distribution of authenticated public values.........  35

    4.1   Encoding of an Unsigned DH public value.......  35

    4.2   X.509 encoding of DH public values............  37

          4.2.1   Encoding of the Distinguished Name
                  (DN)  39

    4.3   Certificate Discovery Protocol................  40





                           - ii -











    4.4   Algorithm to determine which Diffie-Hellman
          public value to use...........................  42

5.  Assigned Numbers....................................  43

    5.1   SKIP protocol number..........................  43

    5.2   SKIP SPI value................................  43

    5.3   Name Space Identifier (NSID) Assignments......  43

    5.4   Assigned Algorithm Numbers....................  44

    5.5   SKIP ICMP message (SKIP_ICMP).................  46

    5.6   SKIP Certificate Discovery Protocol...........  46

    5.7   SKIP Multicast GIK request port...............  46

6.  Recommended Parameters and Implementation Notes.....  46

    6.1   Generating Random Keys........................  46

    6.2   Key Update....................................  47

    6.3   n Update Frequency............................  47

    6.4   Recommended G & P values......................  48

          6.4.1   Parameters for 1024 bits Modulus:  48

7.  Conclusions.........................................  49

    Acknowledgements....................................  50

    References..........................................  51












                          - iii -



INTERNET-DRAFT              SKIP            October 16, 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, IP and IPv6) are session-less
datagram oriented protocols. We describe a key-management scheme that is
particularly well suited for use in conjunction with a session-less
datagram protocol like IP or IPv6.

We also describe a simple extension of this protocol to provide scalable
group key-management for Internet multicasting protocols. SKIP 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-03.txt                        [Page 2]


INTERNET-DRAFT              SKIP            October 16, 1995



1.  Overview

Any key-management scheme that can scale to the number of nodes possible
in the Internet must be based on an underlying authenticated public key
based infrastructure. These authenticated public keys may be distributed
using a variety of mechanisms, such as public key certificates, a secure
directory server and so on. ITU standard X.509 provides an example of
distributing authenticated public keys using certificates. Secure DNS
[11] provides an example of distributing authenticated public keys (and
other resources) using a secure directory service. Still another example
of distributing authenticated public keys is the web-of-trust
"introducer" model, best exemplified in the PGP secure e-mail software
package.

All of these mechanisms essentially provide a secure binding between an
entity's name (or identifier) and its public key. Most of the existing
applications assume that the key being authenticated is a key for a
public key cryptosystem, such as RSA [7].

There are two ways authenticated RSA public keys can be used to provide
authenticity and privacy for a datagram protocol, such as IP. The first
is to use out-of-band establishment of an authenticated session key,
using one of several session key establishment protocols prior to
communication [2,3]. This session key is then used to
encrypt/authenticate IP data traffic.

Such a scheme has the disadvantage of having to establish and (securely)
manage a pseudo session layer underneath IP, which is a 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 could involve the use of a computationally expensive
public key operation.

This secure management of the pseudo session state is further
complicated by crash recovery considerations.  If one side crashes, and
loses all session state, then mechanisms need to exist to securely
remove the half-open session state on the side that did not crash.
These mechanisms need to be secure because insecure (unauthenticated)
removal of half-open sessions would open the door to a trivial denial of
service attack.

Performing session oriented key-management at the IP layer has another
major drawback. An important feature of the IP protocol is recovery from



draft-ietf-ipsec-skip-03.txt                        [Page 3]


INTERNET-DRAFT              SKIP            October 16, 1995



intermediate node or link failures, by dynamically re-routing around
failed intermediate links and nodes. Indeed, a basic motivation for the
design of the IP layer was to help build a network that could repair
itself from failure due to destruction of partial network assets under a
military attack. In the commercial environment, this same requirement
exists for reasons of high availability of network access and services.

IP facilitates this failure recovery by not requiring intermediate nodes
to maintain any kind of state on a per communications instance basis.
Each IP packet is independently routable. This permits simple re-routing
of IP traffic around failed routers/links. In addition to re-routing for
reasons of router/link failure, IP protocols also perform dynamic
routing to better utilize the network's capacity, by performing load
balancing of network traffic. For example, if equal cost routes exist to
a destination, the OSPF [16] routing protocol will split the traffic
among those equal cost routes, thereby load balancing IP traffic among
several different routers/links.

Performing session oriented key-management for IP defeats these
properties of IP. For example, if encryption is being performed at some
intermediate point (e.g. encrypting router or firewall) then session
oriented key-management makes dynamic re-routing of encrypted IP traffic
for reasons of failed or congested nodes/links far more complicated than
the straightforward fail-over/re-routing mechanisms that exist for
unencrypted IP traffic. This is because, in essence, a stateful
connection has been created to an intermediate point. A packet is no
longer an independent entity; it now requires information from a
security association establishment phase, namely the session key, in
order to be properly processed.  Rerouting encrypted traffic for
decryption by another intermediate node either for fail-over or load-
balancing considerations is not practical with session oriented key-
management. This is because it is not practical to simply and securely
share transient session keys, which exist only on a pairwise basis, with
many other intermediate nodes. Without knowledge of the transient
session key with which the packets are protected, another intermediate
node is not able to decrypt/authenticate re-routed IP traffic.  Thus,
session oriented key-management, implemented at the IP layer, breaks
many of the properties which have made IP successful as an internet
protocol.

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

An alternative design could utilize authenticated RSA public keys in a
stateless key-management scheme.  This might work through in-band



draft-ietf-ipsec-skip-03.txt                        [Page 4]


INTERNET-DRAFT              SKIP            October 16, 1995



signaling of the packet encryption key, where the packet encryption key
is encrypted in the recipient's RSA public key. This is the way, for
example, PEM and PGP perform message encryption. Although this avoids
the session state establishment requirement and prior out-of-band
communication in order to set up and change packet encryption keys, this
scheme has the disadvantage of having to carry the packet encryption key
encrypted in the recipient's public key in each IP packet.

Since an RSA encrypted key would minimally need to be 64 bytes, and can
be 128 bytes, this scheme incurs the overhead of 64 to 128 bytes of
keying information in every packet. (As time progresses, the RSA block
size would need to be closer to or greater than 128 bytes simply for
security reasons.) Also, when the packet encryption key changes a public
key operation would need to be performed in order to recover the new
packet encryption key. Thus both the protocol and computational overhead
of such a scheme is very high.

Use of authenticated Diffie-Hellman (DH) [4] public values can avoid the
need for pseudo session state management between two ends in order to
acquire and change packet encrypting keys. Authenticated DH public
values serve as the basis for a very simple, efficient and stateless
key-management scheme that does not entail any of the drawbacks noted
above. Apart from being exceedingly simple to implement, this stateless
key-management scheme provides straightforward and scalable solutions to
permit dynamic re-routing of protected IP traffic through alternate
encrypting intermediate nodes for crash-recovery/fail-over/load-
balancing scenarios.


1.1  Simple Key-Management for Internet Protocols

We stipulate that each IP based source and destination shall have an
authenticated Diffie-Hellman public value.  This public value may be
distributed in numerous ways. One mechanism (described here) is by the
use of X.509/PEM certificate format [6]. Another mechanism, described
later, relies on naming principals using the message digest of their DH
public value.

The X.509 certificates can be signed using any signature algorithm, such
as RSA or DSA. 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.  In the
discussion below we focus on IP nodes, although user oriented keying is
possible and is further described later in section 1.8.



draft-ietf-ipsec-skip-03.txt                        [Page 5]


INTERNET-DRAFT              SKIP            October 16, 1995



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
authenticated public value distribution 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.

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. Since Kij is used for key-
encryption, one MUST NOT use a stream cipher for this purpose.

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
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



draft-ietf-ipsec-skip-03.txt                        [Page 6]


INTERNET-DRAFT              SKIP            October 16, 1995



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.11.]

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.

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.

Since the authenticated public values are Diffie-Hellman public values,
the nodes themselves have no public-key signature algorithm. This is not
a problem, since signing on a per-packet basis using a public-key
cryptosystem is too cumbersome. The integrity of the packets is
determined using a symmetrically keyed Message Authentication Code
(MAC).



draft-ietf-ipsec-skip-03.txt                        [Page 7]


INTERNET-DRAFT              SKIP            October 16, 1995



1.2  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 the key that is manually established.

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



draft-ietf-ipsec-skip-03.txt                        [Page 8]


INTERNET-DRAFT              SKIP            October 16, 1995



This counter value is passed in the field labeled "n" following the
version and processing mode bits of the SKIP header described in Section
1.9.

1.3.1  Zero Message Master key Update with Diffie-Hellman

The n'th level implicit key (which we denote as Kijn) is derived using
the following function:

Kijn = g^ijn mod p

Implementation note: The n'th value g^ijn mod p is computable from the
(n-1)th value as (g^ij(n-1) mod p)*(g^ij mod p) by performing only a
single multiplication at each step.  This can be significantly faster
than performing the exponentiation (g^ij mod p)^n mod p at each step.


1.3.2  Zero Message Master Key update with Manual Keying

As before, n can be computed as the difference between an agreed upon
start time (specified later in this document) and the current time.
Then, the n'th master key is generated 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 this version 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.

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-03.txt                        [Page 9]


INTERNET-DRAFT              SKIP            October 16, 1995



1.4  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 are completely generalizable 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. This includes the master key update algorithm described
in the previous section.

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.5  Storage of Cryptographic Keys

Since the Kijn values need to be cached for efficiency, reasonable
safeguards need to be taken to protect these keys.

One possible way to do this is to utilize a hardware device to compute,
store and perform operations using these keys. This device can ensure
that there are no interfaces to extract the keys from the device. Such
devices can be in the form of tamper-proof smart cards, PCMCIA devices,
and so on.

A full discussion of system-level protection of cryptographic keys,
while an important issue, is beyond the scope of this document.









draft-ietf-ipsec-skip-03.txt                       [Page 10]


INTERNET-DRAFT              SKIP            October 16, 1995



1.6  SKIP for High Availability and Load Balancing

Since the SKIP protocol as described above is completely stateless, it
is straightforward to construct highly-available and load-balanced
protected IP configurations.

For a redundant configuration, a site configures itself with multiple
intermediate nodes that share the same long-term Diffie-Hellman secret
(and thereby public) value. These nodes may all have different IP
addresses, as long as the receiver 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.8].

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
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 routers (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.

Thus high-availability and load-balancing simply fall out from the basic
stateless SKIP design, without requiring an additional (and complex) set
of protocols to deal with these issues.


1.7  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.








draft-ietf-ipsec-skip-03.txt                       [Page 11]


INTERNET-DRAFT              SKIP            October 16, 1995



1.7.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. Certified 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.7.2  Known Key Attacks

If the in-band traffic keys Kp used for packet authentication are ever
compromised, 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, knowing any number of past keys Kp does not help an attacker learn
any other Kp, since knowing any number of Kp keys 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
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 immune
to a chosen text attack, which will always be the case. Thus SKIP is
immune to known or chosen key attacks of this variety.

1.7.3  Anti-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.





draft-ietf-ipsec-skip-03.txt                       [Page 12]


INTERNET-DRAFT              SKIP            October 16, 1995



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.4  Non-Goal: Perfect Forward Secrecy

Although perfect forward secrecy as described in [3], is a desirable and
appealing goal for a key-distribution protocol, there are no known
practical and scalable techniques for achieving perfect forward secrecy
for a stateless message based protocol. Here a message based protocol is
contrasted with a stateful session based protocol. Common examples of
message based protocols include secure e-mail protocols such as PEM and
PGP. There are no known techniques for providing perfect forward secrecy
of encrypted data for these stateless message based protocols.

In support of dynamic IP routing, IP is more accurately modeled as a
message based protocol. For these reasons, SKIP does not attempt to
provide perfect forward secrecy of encrypted IP traffic. Only a stateful
session oriented key distribution protocol can provide perfect forward
secrecy, but such a scheme breaks the basic properties of IP as noted
above, vastly complicating crash (or making impossible) highly available
and load-balanced protected IP configurations.

1.8  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.





draft-ietf-ipsec-skip-03.txt                       [Page 13]


INTERNET-DRAFT              SKIP            October 16, 1995



[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 particulay 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.

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 receiver 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 256) to
be used with SKIP, by letting the Master Key-ID 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, U.S. Social Security numbers, Bank Account numbers, etc.

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



draft-ietf-ipsec-skip-03.txt                       [Page 14]


INTERNET-DRAFT              SKIP            October 16, 1995



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.

There is a separate NSID byte for sender and receiver, 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 DHCP protocol) 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 Receiver Master Key-IDs can serve many purposes as well.  When
the Receiver Master Key-ID refers to an IP address, it can be used to



draft-ietf-ipsec-skip-03.txt                       [Page 15]


INTERNET-DRAFT              SKIP            October 16, 1995



pass end-to-end encrypted SKIP packets through an encrypting
intermediate node. Without a receiver 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 receiver
Master Key-ID enables an encrypting intermediate node (e.g., router or
firewall) to determine whether to process a packet or simply forward it.
The receiver Master Key-ID is present when the Destination NSID is non-
zero.

On an end node, the Receiver Master Key-ID can be used to distinguish
between multiple users on the same IP node.

If the Source NSID is non-zero, the sender 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 receiver 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 receiver 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
described in the "Assigned Numbers" section below. More name spaces will
be registered through IANA.

1.9  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 32 bit quantities in the SKIP
header are transmitted in network order.















draft-ietf-ipsec-skip-03.txt                       [Page 16]


INTERNET-DRAFT              SKIP            October 16, 1995



SKIP Header

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Sender Master Key-ID  (If Source NSID is non-zero)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Receiver 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. A non-zero Source NSID indicates that a packet
contains a sender 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 receiver 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-03.txt                       [Page 17]


INTERNET-DRAFT              SKIP            October 16, 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. This is further described in a later section.

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 sender 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 receiver 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 will be set
to zero in the SKIP header.








draft-ietf-ipsec-skip-03.txt                       [Page 18]


INTERNET-DRAFT              SKIP            October 16, 1995



1.10  The relative order of compression, encryption and authentication

The protocol allows three potential transforms to be performed, namely
compression, encryption and authentication. The order in which these
transforms are performed is very important.  It is desirable for
encryption to follow compression, because encrypted data is not
(generally) compressible. Authentication must follow encryption and/or
compression because it is unknown whether transforming a MAC using
either encryption or compression results in a valid MAC.

Therefore SKIP compliant implementations MUST use the following order.

For outgoing IP packets, a) IF compression is to be performed then the
data is first compressed b) and IF encryption is to be performed, then
the output of step a) is encrypted, c) and IF authentication is to be
performed, then the output of step b) is authenticated. If, for example,
all three transforms are being performed, then first data gets
compressed, compressed data gets encrypted, and the compressed-encrypted
data is authenticated.

Received packets MUST be transformed using the reverse order. If
authentication is being used then the packets will be checked for
authenticity first. Only if the packets pass the authentication phase
will they be decrypted if encryption was performed, and then
uncompressed if compression was performed.

1.11  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. Namely, the authentication and encryption keys MUST be
different. This allows, for example, encryption keys to be short
(possibly to satisfy export control laws) while keeping the
authentication key as long as necessary.  Furthermore, it must be
infeasible to derive either one of the authentication key or the
encryption key, should one of them be compromised.

This is accomplished as follows. 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:





draft-ietf-ipsec-skip-03.txt                       [Page 19]


INTERNET-DRAFT              SKIP            October 16, 1995



E_kp = h(Kp | 01h) | h(Kp | 00h)

A_kp = h(Kp | 03h) | h(Kp | 02h)

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.3.2. 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 |
02h) 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
specifies a 40-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 40-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 ignored for the E_kp and A_kp
computation functions.




draft-ietf-ipsec-skip-03.txt                       [Page 20]


INTERNET-DRAFT              SKIP            October 16, 1995



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.12  SKIP for Authentication

Note: Packet authentication and packet integrity are used
interchangeably in this document, since there is no meaningful
cryptographic distinction between the two.

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.

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





draft-ietf-ipsec-skip-03.txt                       [Page 21]


INTERNET-DRAFT              SKIP            October 16, 1995



    +-------------+----------+----------+----------------------------+
    | IPv4 Header | SKIP Hdr | Auth Hdr |Upper Protocol (e.g.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 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    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.


1.12.2  Scope of MAC computation

The scope of the MAC computation is the entire packet, including the
outer clear IP header, followed by the SKIP header, followed by AH
header, and finally, the payload of the AH header.





draft-ietf-ipsec-skip-03.txt                       [Page 22]


INTERNET-DRAFT              SKIP            October 16, 1995



RFC 1826 describes the scope of the MAC computation and the treatment of
fields in the AH header as well as IP header fields that may change in
transit. SKIP implementations MUST follow the MAC computation procedure
as defined in RFC 1826. In addition to inclusion of the IP and AH
headers as specified in RFC 1826, SKIP implementations MUST include the
SKIP header for purposes of MAC computation. For purposes of MAC
computation, all SKIP header fields MUST be treated as containing the
values that a SKIP receiver will see. Any RESERVED values in the SKIP
header MUST be treated as zero for purposes of MAC computation.


1.13  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 RFC 1829. These transforms will also contain
information such as Initialization Vectors or Message Indicators.

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

1.13.1  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  |Upper Protocol (e.g.TCP,UDP)|
    +-------------+----------+----------+----------------------------+

                      IPv4 with SKIP/ESP Example












draft-ietf-ipsec-skip-03.txt                       [Page 23]


INTERNET-DRAFT              SKIP            October 16, 1995



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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    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.

The Opaque transform data is defined by the particular transform (such
as DES-CBC in RFC 1827). 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.


1.13.2  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.





draft-ietf-ipsec-skip-03.txt                       [Page 24]


INTERNET-DRAFT              SKIP            October 16, 1995



  +----------+----------+----------+---------+----------------------------+
  | IPv4 Hdr | SKIP Hdr | Auth Hdr | ESP Hdr |Upper Protocol (e.g.TCP,UDP)|
  +----------+----------+----------+---------+----------------------------+

                      IPv4 with SKIP/AH/ESP Example

A_Kp would be used for authentication and E_kp (as discussed in a
previous section) 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.

SKIP Header

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |    Sender Master Key-ID                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |    Receiver 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 |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   ---







draft-ietf-ipsec-skip-03.txt                       [Page 25]


INTERNET-DRAFT              SKIP            October 16, 1995



1.13.3  SKIP with combined ESP transforms

For ESP transforms which combine encryption and authentication (for
instance: Keyed MD5 with DES-CBC), only an ESP header 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 a previous
section) 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.14  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
encrypt Kp.

In particular it is possible to pass SKIP in the payload of of a TCP/UDP
packet. This allows the key-management and encryption/authentication to
be performed in the application protocol (above TCP/UDP), and there may
be times where it is advantageous to do so.


2.  SKIP for Multicast IP

We describe multicast key distribution in two specific contexts.  The
first is in the context of a transient multicast group, where an
application, such as video/audio conferencing, dynamically allocates a
multicast address or addresses, uses it for a period of time, and then
relinquishes these multicast addresses.

The second is in the context of permanent multicast groups, where a
fixed set of well known multicast addresses is used by participants of
the protocol. An example of this is routing protocols that use well
known multicast addresses in order to propagate routing information in
the network.

Broadcast IP may be considered a special case of the second context,
where a set of well known IP addresses serve as broadcast addresses for
a subnetwork.




draft-ietf-ipsec-skip-03.txt                       [Page 26]


INTERNET-DRAFT              SKIP            October 16, 1995



2.1  Transient Multicast Groups

A simple extrapolation of SKIP for unicast IP gives a scalable key-
management scheme for IP multicast applications.  In order to achieve
secure transient multicast groups, key-management awareness needs to
exist in the multicast group-join process.

Furthermore, in order to distribute multicast keying material, the
notion of a group owner needs to exist. How the identity of the group
owner is established and communicated to the participating nodes is left
to the application layer. However, this also needs to be done in a
secure fashion, otherwise the underlying key-management can be defeated.

When secure multicasting to multicast address M is required, a group
membership creation primitive will establish the group key Kg and the
membership list of addresses that are allowed to transmit and receive
encrypted multicast datagrams to and from group address M. This action
will be taken by the group owner.

An important point is that the group key Kg is not used as a packet
encryption key, but rather as the Group Interchange Key (GIK). Namely,
Kg is used as a key-encrypting-key, similar to way the master keys Kijn
are used in SKIP for unicast IP.

Nodes wishing to transmit/receive encrypted datagrams to multicast
address M need to acquire the GIK Kg. This is done by sending an
encrypted/authenticated request-to-join primitive to the group owner. If
the requesting node's address is part of the group's authorized
membership list, then the group owner will send the GIK Kg, algorithm
identifier, associated lifetime information and key-change policy in an
encrypted packet, using the pairwise secure protocol described in
Section 1 above.

The packet formats for the GIK request/response is given below. This
describes the payload portion of either a TCP or UDP packet, which has
been enhanced using SKIP unicast procedures. If using UDP, multiple
requests may need to be sent, in case of packet losses of earlier
requests/response messages.  The request is sent to TCP/UDP port #
skip_multicast_gik_request (which is specified in the "Assigned Numbers"
section). It is sent to the group owner's unicast IP address.








draft-ietf-ipsec-skip-03.txt                       [Page 27]


INTERNET-DRAFT              SKIP            October 16, 1995




    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version = 1    | Reserved                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    IP Multicast Address M                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The first field specifies the version of this protocol, which is 1. It
is followed by the actual IP multicast address for which the GIK is
being requested. The request packet that is sent must have the minimal
enhancement of source-origin authentication, which is accomplished using
the AH protocol. The group owner's response is an encrypted packet
containing the GIK Kg.  The response is sent to the requestor's
ephemeral TCP/UDP port at the requester's unicast IP address. The packet
format is as follows, and as before, it defines the data-portion of a
TCP or UDP packet.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version = 1    | Kg Alg id    |    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    IP Multicast Address M                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Expiry time        (low 32-bits)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Expiry time        (high 32-bits                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Recommended Key Change Interval (in seconds)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Recommended Key Change Interval (in bytes)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Kg  .... (length dependent on Kg Alg)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The 64-bit expiry time specifies when the multicast key is considered to
have expired. This is in terms of seconds since, 0h Jan 1, 1900,
expressed in GMT. The Recommended Key-Change interval is what every
source of encrypted traffic to the multicast group uses to determine the
key-change policy. There are two ways of specifying key-change policy.



draft-ietf-ipsec-skip-03.txt                       [Page 28]


INTERNET-DRAFT              SKIP            October 16, 1995



One is in terms of elapsed time since last key-change. This is specified
by the "Recommended Key Change Interval (in seconds)" field, which
specifies the number of seconds to wait before changing keys. The other
is in terms of the amount of data encrypted in a given packet encryption
key. This is specified using the "Recommended Key Change Interval (in
bytes)" field. Each source of encrypted traffic MUST use whichever of
these determines the more frequent key-change policy, whether this is in
terms of amount of traffic encrypted in a given key, or in terms of
elapsed time (in seconds) since the last key change.

Transmitting nodes to group address M will randomly generate packet
encryption keys Kp, and encrypt these keys using Kg. The packet
structure is similar to the structure used for encrypted unicast SKIP
packets, except that the packet keys Kp are not encrypted in the
pairwise keys Kijn, but instead are encrypted using the GIK Kg. An
example encrypted multicast packet using ESP for packet encryption, is
shown below.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Clear IP Header  protocol = SKIP... (typically 20-bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |  Ver  | Rsvd. | Source NSID   | Dest NSID     |NEXT HEADER    |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |                    Counter n                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
   |    Reserved  |  Crypt Alg       |   Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |    Kp encrypted in GIKn Kg...           (typically 8-16 bytes)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+                                       ---
   |                    SPI=SKIP_SPI                               |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
   |            Opaque Transform Data, variable Length             |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---


The destination IP address will be used by the receiver to determine
whether to use unicast or multicast key-processing procedures on a
received IP packet. In case the destination address is an IP multicast
address, it will use the GIK Kg to decrypt the packet encryption key Kp.
An implementation of this protocol will use the destination IP multicast
address to lookup the GIK Kg.




draft-ietf-ipsec-skip-03.txt                       [Page 29]


INTERNET-DRAFT              SKIP            October 16, 1995



There are two distinct advantages of this scheme.  First, every member
of the multicast group can update packet encryption keys as often as it
needs (in line with the policy set by the group owner), without
involving key-setup communications overhead involving every member of
the group. This can be extremely frequent, e.g. once every few seconds
even with very large multicast groups, because there is no extra
communications overhead for updating packet encryption keys.

Second, since all the packet encryption keys are randomly generated, and
hence different, there is no problem in using stream-ciphers with
multicast. This is because each source of encrypted traffic when using a
stream cipher would use a different key-stream and thus there is no
key-stream reuse problem. If all members of the multicast group used the
same packet encryption key, then certain stream ciphers could not be
used with multicast IP, because of problems related to key-stream reuse.

2.2  SKIP for Broadcast/Permanent Multicast Groups

For broadcast and permanent multicast groups, the key distribution
scheme is similar to the one described above for transient multicast
groups, except that GIK is permanent and has no expiry date and may be
manually distributed between authorized members of the group (multicast
or broadcast). The GIK is updated for the permanent multicast or
broadcast group using the zero-message master key update procedure
described in section 1 above for manually distributed master keys.
Instead of using Kij as the input to generating the n'th master key
Kijn, the manually distributed GIK shall be used to generate the n'th
level GIK, and labeled GIKn.

This allows for a simple, automated and scalable way of updating the
master key used for the permanent group, which further frustrates
cryptanalysis of the master key. Since n is a 32-bit number, the time it
will take to overflow this counter, based on hourly updates of the
master key, is sufficiently long to be a non-issue.

To precisely define the master key update procedure in the context of
broadcast/multicast groups:

GIKn = h(GIK | n | 01H) | h(GIK | n | 00H)

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 "|"
represents concatenation. The low order bits of the output of this
operation are used for GIKn. GIKn is then used to encrypt packet keys,
analogous to how packet keys are protected for unicast IP using Kijn.



draft-ietf-ipsec-skip-03.txt                       [Page 30]


INTERNET-DRAFT              SKIP            October 16, 1995



It is worth noting that all members of a group are considered equivalent
from the point of view of multicast/broadcast authentication. There are
no practical and efficient techniques to achieve multicast/broadcast
authentication, where the authentication mechanism distinguishes between
members of the same multicast group. Digital signatures is a technology
that may be used for broadcast authentication, except all known
signature techniques are too computationally expensive to be performed
on a per packet basis.

Even when relying on manual key distribution to initialize a protected
multicast/broadcast group, both the master and the traffic protection
keys are automatically updated in a completely scalable manner, using
the procedures described above.

2.2.1  SKIP and RIPv2

As an example of both how SKIP can be used to supply keys for protocols
other than AH/ESP, and use of SKIP in the context of permanent multicast
groups, we describe SKIP for RIPv2 [RFC 1388].  The RIP protocol
specifies a field for authentication type and how to compute and
distribute a MAC for authenticated RIP information.

The authentication type of the first RIP entry would be set to a value
which we will assign the symbolic name SKIP. The Authentication field
would contain the MAC. The scope of authentication is identical to that
of AH.

Since RIP is a broadcast protocol, keying semantics are different than
with unicast. Please see the previous section on broadcast and fixed
permanent multicast groups.


















draft-ietf-ipsec-skip-03.txt                       [Page 31]


INTERNET-DRAFT              SKIP            October 16, 1995



The following is an example of SKIP combined with RIP V2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Clear IP Header  protocol = SKIP... (typically 20-bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
   |  Ver  | Rsvd. | Source NSID   | Dest NSID     |NEXT HEADER=RIP|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |                    Counter n                                  |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
   |    Kij Alg    |   RESERVED    |  MAC Alg      |  RESERVED     |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |    Kp encrypted in GIKn ...          (typically 8-16 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
   | Command       |  Version      |  Routing Domain               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | Address Family=0xFFFF         |  Authentication Type=SKIP_AUTH|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RIP Hdr
   |                       AUTHENTICATION (MAC)                    |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |                    ....Authenticated RIP Entries                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---


Here the packet authentication keys are encrypted using GIKn, which is
computed using procedures described in the preceding section.

This use of SKIP to supply keys for non AH/ESP protocols is intended to
be illustrative, and not exhaustive. Other protocols can similarly be
used with SKIP, either in the context of unicast, or transient/permanent
multicast and broadcast group communications.


3.  Algorithm Discovery

An optional protocol is described for discovering the appropriate
algorithms to use for various packet transformations, such as
encryption, authentication, compression etc. Algorithm discovery is in
many ways analogous to algorithm negotiation in conventional session
oriented key setup. However, "negotiation" is a misnomer as applied to
most existing protocols that accommodate this feature. This is because
in essence there is no negotiation, simply a statement of capabilities
on both sides. The sides agree to pick a common subset of their
capabilities.



draft-ietf-ipsec-skip-03.txt                       [Page 32]


INTERNET-DRAFT              SKIP            October 16, 1995



SKIP allows the same statement of capabilities to occur in a stateless
manner, entirely analogous to how the IP protocol performs path MTU
discovery. A SKIP implementation is free to choose a set of algorithms
with a particular node. If it chooses incorrectly, it will discover this
through an authenticated ICMP message, which is in effect a statement of
capabilities and preferences for that node.

RFC 1825 requires that Keyed MD5 for authentication and DES-CBC for
encryption are mandatory. The ICMP message is authenticated using RFC
1825 as the default authentication algorithm, which MUST be supported by
all SKIP nodes that support this optional ICMP protocol.

If a node receives a SKIP packet which specifies algorithms it does not
support, it SHOULD send an authenticated ICMP message indicating this
failure and specifying which algorithms it supports. The ICMP Packet
MUST be encapsulated in AH with keyed MD5 used as the algorithm. Any
received algorithm discovery ICMP message that is not authenticated MUST
be ignored.






























draft-ietf-ipsec-skip-03.txt                       [Page 33]


INTERNET-DRAFT              SKIP            October 16, 1995



The Algorithm discovery ICMP message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TYPE=SKIP_ICMP|  CODE         |    CHECKSUM                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    nKij       |   nKp         |     nmac      | ncomp         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Current Time                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  n update Frequency  (in seconds)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Expected n                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kij Algorithms (0-255), 1 byte each
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Crypt Algorithms (0-255), 1 byte each
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MAC Algorithms (0-255), 1 byte each
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Compression Algorithms (0-255), 1 byte each
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CODE should be interpreted as a bit field in the following way:

         7 6 5 4 3 2 1 0
        +-+-+-+-+-+-+-+-+
        |I|P|M|C|N| res |
        +-+-+-+-+-+-+-+-+

        I is set if the Kij algorithm in the SKIP packet is unsupported.
        P is set if the Crypt algorithm in the SKIP packet is unsupported.
        M is set if the MAC  algorithm in the SKIP packet is unsupported.
        C is set if the compression algorithm in the SKIP packet is
          unsupported.
        N is set if an invalid n counter was sent in the packet

        bits 0-2 are reserved and MUST be set to 0.

The ICMP type field SKIP_ICMP is specified later in this document.

The time field, Current Time, is set to the system's concept of current
time in seconds since 0h Jan 1, 1900. This is identical to the Integer
portion of the NTP timestamp.



draft-ietf-ipsec-skip-03.txt                       [Page 34]


INTERNET-DRAFT              SKIP            October 16, 1995



The field "n update Frequency" is set with the value representing the
number of seconds between increments of the n counter. For example, if
the n counter is updated once an hour, this field would contain 3600.

The nKij, nKp, nmac and ncomp fields should be filled in with the number
of Kij, Kp, MAC and Compression algorithms the system supports,
respectively.

The Kij, Kp, MAC and Compression algorithms fields should be filled in
sequentially with the one byte identifiers for each of the algorithms
that the system supports. The algorithms should be an ordered list with
the most desirable algorithms first and the least desirable last.

For instance, if the system supports 5 Kij algorithms, nKij would be set
to 5 and the Kij Algorithms field would be 5 bytes long (one byte for
each algorithm supported).

A host may force an ICMP message by sending a SKIP packet to the remote
host with Kij set to zero.



4.  Distribution of authenticated public values

As mentioned earlier, a variety of mechanisms can be employed to
distribute authenticated public values, such as, X.509 certificates, PGP
certificates, Secure DNS resource records and use of the message digest
of a public value as the name of a principal.

We define the encodings of the public values for the case where a
principal's name is the message digest of its DH public value, and for
use with signed X.509 certificates.

4.1  Encoding of an Unsigned DH public value

This encoding scheme is used to distribute a DH public value, for cases
where the principal's name is the message digest of the public value.
Although the public value is distributed in an unsigned manner, there is
still a strong binding between a name and the public value, given the
collision resistance properties of a message digest. The principal's
names need to be securely distributed out of band.







draft-ietf-ipsec-skip-03.txt                       [Page 35]


INTERNET-DRAFT              SKIP            October 16, 1995



The following is how the public value is encoded for purposes
of message digest computation and distribution in the network.
All 16/32 bit values are in network order.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Not Valid before                            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Not Valid After                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            PrimeLen           |   Prime   (p)                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           .....                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            GenLen             |   Generator (g)               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           .....                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           PublicValueLen      |   Public Value (g^i mod p)    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           .....                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


"Not Valid Before" is the time which the public value becomes valid. It
is in NTP time format (the Integer portion). "Not Valid After" is the
time which the public value expires. It is in NTP time format (the
Integer portion).

PrimeLen is Length of the DH Prime (p) in bytes.  Prime contains the
binary representation of the DH prime with most significant byte first.
GenLen is the length of the Generator (g) in bytes. Generator is the
binary representation of g with most significant byte first.
PublicValueLen is the Length of the Public Value (g^i mod p) in bytes.
PublicValue is the binary representation of of the DH public value with
most significant byte first.

Although, strictly speaking, an unsigned DH public value is not a
certificate, this value is distributed using the optional certificate
discovery protocol specified later. Certificate verification in this
instance means verifying that the message digest of the Unsigned DH
public value (encoded as specified above) is the same as the (securely
known) name of the principal. When using this instead of signed
certificates, certificate verification MUST be performed by performing



draft-ietf-ipsec-skip-03.txt                       [Page 36]


INTERNET-DRAFT              SKIP            October 16, 1995



the message digest computation. A message digest type that has been
assigned a certificate type is the MD5 algorithm.

IMPORTANT NOTE: The unsigned DH public value can ONLY be used when
principals are named using the message digest of their DH public value,
AND these names are securely communicated. Unsigned DH public values
MUST NOT be used instead of signed DH certificates when principals are
named using something other than the message digest of their public
value, since this opens up the possibility of an intruder-in-the-middle
attack, described in Section 1 above. In order to use other naming
schemes, signed certificates such as X.509, Secure DNS, PGP, etc.
should be used instead.


4.2  X.509 encoding of DH public values

































draft-ietf-ipsec-skip-03.txt                       [Page 37]


INTERNET-DRAFT              SKIP            October 16, 1995



The X.509 certificate format is defined by the following ASN.1 syntax:

Certificate ::= SIGNED SEQUENCE {
                  version [0]           Version DEFAULT v1988,
                  serialNumber          CertificateSerialNumber,
                  signature             AlgorithmIdentifier,
                  issuer                Name,
                  validity              Validity,
                  subject               Name,
                  subjectPublicKeyInfo  SubjectPublicKeyInfo
                }

Version ::= INTEGER { v1988(0) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {
               notBefore UTCTime,
               notAfter UTCTime
             }

SubjectPublicKeyInfo ::= SEQUENCE {
                           algorithm    AlgorithmIdentifier,
                           subjectPublicKey     BIT STRING
                         }

AlgorithmIdentifier ::= SEQUENCE {
                          algorithm       OBJECT IDENTIFIER,
                          parameters      ANY DEFINED BY algorithm OPTIONAL
                        }


The encoding of a Diffie-Hellman public value in an X.509 certificate
will be in the form of an INTEGER.  The algorithm identifier will be as
defined in PKCS #3 [7].  Thus,













draft-ietf-ipsec-skip-03.txt                       [Page 38]


INTERNET-DRAFT              SKIP            October 16, 1995




DHPublicKey ::= INTEGER

AlgorithmIdentifier ::= SEQUENCE {
                          algorithm     OBJECT IDENTIFIER
                          SEQUENCE {
                            prime INTEGER,      -- p
                            base  INTEGER,      -- g
                            privateValueLength INTEGER OPTIONAL
                          }
                        }

with the OBJECT IDENTIFIER value being,

dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840)
                                        rsadsi(113549) pkcs(1) 3  1 }


The DHPublicKey gets encapsulated as the BIT STRING in
SubjectPublicKeyInfo of an X.509 certificate in the obvious manner.  The
certificate and CRL encoding is the same as in RFC 1422.  CRLs will be
used with SKIP in the usual manner, in line with each site's
certificate/CRL management policies.

4.2.1  Encoding of the Distinguished Name (DN)

When the name space is the IP address space, a certificate is allowed to
bind multiple IP addresses to a single public value to accommodate cases
where a single IP node has multiple IP addresses.  The SEQUENCE-OF
construct in a DN readily allows for this.  What is needed is an ASN.1
OBJECT IDENTIFIER for an AttributeType specifying an IP address.

This is defined here as,


ipAddress ATTRIBUTE
                WITH ATTRIBUTE-SYNTAX
                        PrintableString (SIZE(1 .. ub-ipAddress))
                ::= { ipsec-oid 1 }     -- ipsec-oid needs to be registered


ub-ipAddress ::= 256

The DN in the certificate can contain multiple of these by iterating on
the SEQUENCE-OF construct of the Relative Distinguished Name Sequence.



draft-ietf-ipsec-skip-03.txt                       [Page 39]


INTERNET-DRAFT              SKIP            October 16, 1995



The PrintableString contains either the hexadecimal representation or
standard dot notation representation of an IP address.

When individual users are identified using Distinguished Names, then the
DN in the certificate naturally contains their DNs. Section 1 above
describes how DNs may be used with SKIP, by identifying the DN name
space using the NSID bytes.

4.3  Certificate Discovery Protocol

An optional protocol is described to enable communicating IP-nodes to
discover each other's certificate(s). This obviates the need for an on-
line certificate directory server.

A number of certificate types currently exist, for example, X.509, PGP
DNS-SIG, Unsigned DH pub value. This protocol allows for all of these
types.  Also note, that a particular IP-node may have more than one
certificate.  A node could have the same Diffie-Hellman public value in
different certificate formats, or have multiple Diffie-Hellman public
values each in a separate certificate or have the same Diffie-Hellman
public value certified by different Certifying Authorities, and so on.
In all these possible certificates the identity of the node remains
constant.  An algorithm for choosing a particular certificate
(essentially a Diffie-Hellman public value) when more than one exist is
described later.

All certificate discovery protocol communication use the User Datagram
Protocol (UDP).  The initiator binds to port skip-cert-send (6456) and
sends a certificate request to port skip-cert-recv (6455).  The
responder binds to port skip-cert-recv and sends the response to port
skip-cert-send.  Two separate ports are used to allow for multiple
certificate requests to be made without waiting for the response to be
received, (that means, one port is used to simply send requests out and
the other port is used to receive responses).  A simple cache of the
Master Key-ID and the IP address to which the request was sent is all
that is required to manage outstanding certificate requests.

Implementation Note:  Considering that a node may be pre-configured to
allow only encrypted communication with any other node, a certificate
request would be rejected.  It is suggested that the two ports (skip-
cert-send and skip-cert-recv) be treated as a "by-pass" channel for
encryption.  As only certificates requests are satisfied on these ports
the window for vulnerability is limited.





draft-ietf-ipsec-skip-03.txt                       [Page 40]


INTERNET-DRAFT              SKIP            October 16, 1995



The certificate discovery packet:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VERS  |ACTION |    STATUS     |      NSID     |NUMBER-OF-CERTS|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Master Key-ID of certificate(s) in packet                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  CERT-TYPE    | CERT-LENGTH   |  CERTIFICATE                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                ...                                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  CERT-TYPE    | CERT-LENGTH   |  CERTIFICATE                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


VERS indicates protocol version #. VERS = 1 for this protocol.

ACTION indicates the type of message. Possible values are:
1 (Request)     - request for remote parties certificate(s).
2 (Response)    - response to a certificate request.

STATUS is used only in responses (i.e. ACTION = 2). Possible values are:
0 (OK)          - process the certificates sent. NUMBER-OF-CERTS must not
                  be zero.
1 (Unknown Error) - an error has occurred.
2 (Unknown Master Key-ID) - no certificates for the requested Master
                            Key-ID can be found in the local certificate
                            database.
NSID            - identifies the namespace that the Key-ID belongs to.
                  The values of this field are described in the assigned
                  numbers portion of this document.

NUMBER-OF-CERTS - if 0 then no certificates are present in the message
                  and the message is simply a request for all certificates
                  for the specified Master Key-ID or a response where the
                  STATUS octet indicates an error.

Master Key-ID   - this is the identifier as described in the section on
                  Master Key-IDs. It's length is dependent on the value
                  of the NSID field.

CERT-TYPE       - specifies the certificate type of the certificate that



draft-ietf-ipsec-skip-03.txt                       [Page 41]


INTERNET-DRAFT              SKIP            October 16, 1995



                  is to follow. Some well known types have been assigned
                  values below in the Assigned Numbers section.

CERT-LENGTH     - specifies the length of the certificate in bytes

CERTIFICATE     - the actual certificate.

Note that this allows for the initiator to not only request for all
certificates for a particular Master Key-ID but can also send in the same
message all the certificates it has. As certificates have the subjects
identity (i.e. specifies the certificate owner), this information does
not have to be sent to other party.

The Certificate Discovery Protocol allows certificate requests to be
made to any arbitrary IP-node. This feature allows the initiator to send
requests to, say, an IP-node which is acting as a DNS or NFS server (and
hence would have many certificates stored in its local certificate
database).


4.4  Algorithm to determine which Diffie-Hellman public value to use

There may be instances when an IP-node has more than one Diffie-Hellman
public value, or also support other key agreement algorithms (for
example, elliptic curves). In these situations the choice of the key
agreement algorithm and/or the choice of public value to use is
basically made by determining the fastest and the strongest
algorithm/value respectively.

For example, assume an IP-node I supports the Diffie-Hellman Key
Agreement algorithm and has two certificates issued by the same CA but
containing different public values. Assume that one certificate
(cert512) has a 512 bit modulus and the other certificate (cert1024) has
1024 bit modulus. Now, it wishes to communicate with an IP-node J. IP-
node J also uses Diffie-Hellman key agreement algorithm and has two
certificates one of 512 bit modulus and other with 1024 bit modulus. The
shared secret between the two nodes should be based on the stronger
value, that means, the Kij is calculated using the public values with
the 1024 bit modulus.









draft-ietf-ipsec-skip-03.txt                       [Page 42]


INTERNET-DRAFT              SKIP            October 16, 1995



5.  Assigned Numbers

5.1  SKIP protocol number

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

5.2  SKIP SPI value

For use with the AH & 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.

5.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 U.S. Social Security #  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


IANA will assign NSIDs in the range 20-250. The range 250-255 will
remain reserved for private use to implement proprietary naming schemes,
and will not be assigned by IANA. NSIDs in the range 250-255 will only
have local uniqueness properties.








draft-ietf-ipsec-skip-03.txt                       [Page 43]


INTERNET-DRAFT              SKIP            October 16, 1995



5.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 five categories. Algorithms for key-encryption (Kij
Alg), traffic encryption (Crypt Alg), traffic authentication (MAC Alg),
traffic compression (Comp. Alg) and certificate types used by the
certificate discovery protocol.






































draft-ietf-ipsec-skip-03.txt                       [Page 44]


INTERNET-DRAFT              SKIP            October 16, 1995



Key-Encryption Algorithms (Kij Alg)

1       DES-CBC         (IV = 0, random fill upto 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 upto multiple of 64-bits)

Traffic Encryption Algorithms (Crypt Alg)

1       DES-CBC         (64-bit IV, padding ESP transform RFC 1829)
2       40-bit RC2-CBC  (64-bit IV, PKCS # 7 padding algorithm)
3       40-bit RC4      (64-bit byte offset Message Indicator)
4       128-bit RC4     (64-bit byte offset Message Indicator)
5       2 key (k1, k2, k1) Triple DES (EDE-CBC) (64-bit IV, PKCS #7 padding)
6       3 key (k1, k2, k3) Triple DES (EDE-CBC) (64-bit IV, PKCS #7 padding)
7       IDEA-CBC        (64-bit IV, padding according to PKCS #7, FIPS 81)
8       DES-CBC         (64-bit IV, padding according to PKCS #7, FIPS 81)

MAC Algorithms (MAC Alg)

1       128-bit Keyed MD5       (RFC 1828)
2       DES-CBC MAC
3       Keyed SHA               (RFC 1852)

Compression Algorithms (Comp Alg)

        Currently Unassigned

Certificate Type        (CERT-TYPE)

1       X.509
2       PGP
3       Secure DNS
4       Unsigned DH Public Value (*)

(*) Unsigned DH Public Value encoding as specified in Section 4.1

IANA will assign the range 20-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.





draft-ietf-ipsec-skip-03.txt                       [Page 45]


INTERNET-DRAFT              SKIP            October 16, 1995



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
MUST 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).

5.5  SKIP ICMP message (SKIP_ICMP)

The SKIP algorithm discovery ICMP message has been assigned the type 39
(SKIP_ICMP) by IANA.

5.6  SKIP Certificate Discovery Protocol

The SKIP Certificate Discovery Protocol uses two UDP ports to exchange
certificates. "skip_cert_send" and "skip_cert_recv" have been assigned
the values 6456, 6455 respectively by IANA.

5.7  SKIP Multicast GIK request port

The SKIP multicast security protocol uses this port for sending the
request for the multicast GIK. This value is pending assignment by IANA.



6.  Recommended Parameters and Implementation Notes

6.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



draft-ietf-ipsec-skip-03.txt                       [Page 46]


INTERNET-DRAFT              SKIP            October 16, 1995



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.

6.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.

6.3  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 0h Jan 1, 1995. The time units of n
are hours since this start time. Therefore the "n" counter is
incremented once every hour.

Symbolically, n is computed locally as

local n = (current time) - (start time) normalized to hours




draft-ietf-ipsec-skip-03.txt                       [Page 47]


INTERNET-DRAFT              SKIP            October 16, 1995



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

Should future implementations of SKIP ever decide to use a different
update frequency for n, say once every minute or second, then this can
be communicated in a pairwise basis using the algorithm discovery ICMP
message specified above. All this requires for interoperability is that
SKIP implementations that use different n update frequency values also
support the use of the ICMP algorithm discovery message, to indicate the
use of their preferred n update frequency.

6.4  Recommended G & P values

For interoperability, the values g and p in g^i mod p are specified
here.

A 1024 bit modulus (p) is specified below. These values were computed
with a random seed using the BSAFE library from RSA Data Security, Inc.

[Note: This value will soon change to a value which has been initialized
with the help of hashes of numbers from pi and e. In addition a 2048 bit
prime modulus will also be specified.]

6.4.1  Parameters for 1024 bits Modulus:









draft-ietf-ipsec-skip-03.txt                       [Page 48]


INTERNET-DRAFT              SKIP            October 16, 1995




Base (g):
cf ca d9 90 8d 98 c1 c4 4e 4e 88 20 69 e8 7b fb
d0 ca e1 ee 24 64 a9 6c 89 70 a0 8c 86 00 30 c6
c2 83 4a 0d 82 bd a5 ba 10 cf 80 af 61 96 11 4b
3b 87 a9 7e 59 98 c4 aa 0c bd b7 2b 23 18 33 64
f3 b6 2e 1a 4d e8 86 85 aa de 78 a1 5d ce 65 33
75 7a 9d 00 b9 9e 05 26 ed 79 62 15 97 c4 06 26
fa 51 e1 5e f5 1d cb d2 23 e2 73 e5 f2 c7 3c c4
de 58 cd 3b b6 15 3c aa 84 7c fa 5f cb 6b 8d 78

Modulus (p):
dd c9 08 3e 8f ae ef 28 16 ad 50 a9 68 ac bd 04
8e 90 9e ab 5d 41 fc 0a 51 3f 86 0a c4 1b 22 b9
30 dc a3 0a 59 73 05 38 59 b7 85 66 df ff c6 5b
b9 1f fe 44 d9 d6 5e cb 9b 68 38 a1 fd 25 3f 01
51 88 9e 93 c3 22 24 f9 03 e6 9b 8b 07 34 9d 9f
9b 38 4b c0 97 03 dc e5 2e 92 47 4c 2c e1 59 26
14 82 49 dd 58 13 91 05 12 11 a1 45 06 ac 11 8f
b1 83 53 46 93 88 9a 46 b1 8a 01 50 cb 5e 82 55


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

A major advantage of this scheme is that establishing and changing
packet encrypting keys requires no prior communication between sending
and receiving nodes. In addition, no establishment of a pseudo-session
state between the two sides is required. This design permits
straightforward configurations that allow highly available and load-
balanced, protected IP communications.  In addition, there are no
complicated crash recovery considerations for intermediate or end nodes.

High availability of network services, load balancing to better utilize
the network's capacity and simple crash recovery considerations on
intermediate/end nodes are among some of the properties that have made



draft-ietf-ipsec-skip-03.txt                       [Page 49]


INTERNET-DRAFT              SKIP            October 16, 1995



IP successful as an internet protocol. SKIP preserves all these
properties of IP.

We have also described how this scheme may be used in conjunction with
datagram multicast protocols, both for transient and permanent multicast
groups. The SKIP multicast key-management scheme allows extreme
flexibility in terms of updating multicast traffic
encryption/authentication keys even for very large multicast groups. It
also allows all possible traffic encryption algorithms for multicast
data, including all stream ciphers.

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.

Tom Markson and Hemma Prafullchandra contributed substantial pieces of
this draft, and provided entensive critique and feedback of this, in
addition to doing sanity checks of the draft by implementing major
pieces of it.

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.

Jeff Schiller suggested many improvements to the draft in order to
facilitate building interoperable implementations, and his comments on
ipsec motivated the scheme to use the message digest of a public key as
a principal's name.




draft-ietf-ipsec-skip-03.txt                       [Page 50]


INTERNET-DRAFT              SKIP            October 16, 1995



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

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.

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. Oorschot, "Authentication and Authenticated
    Key Exchanges.", in Designs Codes and Cryptography, Kluwer Academic
    Publishers, 1991.

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

[5] S. E. Deering, "Host extensions for IP multicasting", RFC 1112

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

[7] "Public Key Cryptography Standards", PKCS#s 1-10 from RSA Data
    Security Inc., Redwood City, CA, ftp://ftp.rsa.com/pub/pkcs

[8] Atkinson, R., "Security Architecture for the Internet Protocol", RFC
    1825, August 1995

[9] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995

[10] Atkinson, R., "IP Encapsulating 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



draft-ietf-ipsec-skip-03.txt                       [Page 51]


INTERNET-DRAFT              SKIP            October 16, 1995



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

[13] R. Rivest, "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. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC
    1828, August 1995

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

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




Author Information:
Ashar Aziz
Distinguished Engineer
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Ave.,
Mountain View, CA 94043
e-mail: ashar.aziz@Eng.Sun.COM
alternate e-mail address: ashar@incog.com




















draft-ietf-ipsec-skip-03.txt                       [Page 52]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/