WDIFF

draft-ietf-ipsec-ipsec-doi-02.txt --> draft-ietf-ipsec-ipsec-doi-04.txt

Network Working Group Derrell Piper
INTERNET-DRAFT cisco Systems
draft-ietf-ipsec-ipsec-doi-02.txt February 28,
draft-ietf-ipsec-ipsec-doi-04.txt September 19, 1997

The Internet IP Security Domain of Interpretation for ISAKMP
<draft-ietf-ipsec-ipsec-doi-02.txt>
<draft-ietf-ipsec-ipsec-doi-04.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 working groups. Note that other groups may also distribute
working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months
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 (Australia), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited. This draft will expire six
months from date of issue.

1. Abstract

The Internet Security Association and Key Management Protocol
(ISAKMP) defines a framework for security association management and
cryptographic key establishment for the Internet. This framework
consists of defined exchanges and processing guidelines that occur
within a given Domain of Interpretation (DOI). This document details
the Internet IP Security DOI, which is defined to cover the IP
security protocols that use ISAKMP to negotiate their security
associations.

For a description of how the IPSEC DOI fits into the overall IP
Security Documentation framework, please see [ROADMAP].

For a list of changes since the previous version of the IPSEC DOI,
please see Section 5.

Piper Expires in 6 months [Page 1]

INTERNET DRAFT IPSEC DOI September 19, 1997

2. Introduction

Within ISAKMP, a Domain of Interpretation is used to group related
protocols using ISAKMP to negotiate security associations. Security
protocols sharing a DOI choose security protocol and cryptographic
transforms from a common namespace and share key exchange protocol

Piper Expires in 6 months [Page 1]

INTERNET DRAFT IPSEC DOI February 28, 1997
identifiers. They also share a common interpretation of DOI-specific
payload data content, including the Security Association and
Identification payloads.

Overall, ISAKMP places the following requirements on a DOI
definition:

o define the naming scheme for DOI-specific protocol identifiers
o define the interpretation for the Situation field
o define the set of applicable security policies
o define the syntax for DOI-specific SA Attributes (phase II)
o define the syntax for DOI-specific payload contents
o define additional mappings or Key Exchange types, if needed
o define additional Notification Message types, if needed

The remainder of this document details the instantiation of these
requirements for using the IP Security (IPSEC) protocols to provide
data origin authentication
authentication, integrity, and/or data confidentiality for IP packets sent
between cooperating host systems and/or firewalls.

3. Terms and Definitions

3.1 Requirements Terminology

In this document, the words that are used to define the significance
of each particular requirement are usually capitalised. capitalized. These words
are:

- MUST

This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification.

- SHOULD

This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before taking a different course.

- MAY

Piper Expires in 6 months [Page 2]

INTERNET DRAFT IPSEC DOI September 19, 1997

This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor might choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.

Piper Expires in 6 months [Page 2] 3]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

4.1 IPSEC Naming Scheme

Within ISAKMP, all DOI's must be registered with the IANA in the
``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the
Internet IP Security DOI is one (1). Within the IPSEC DOI, all
well-known identifiers MUST be registered with the IANA under the
Internet IP Security DOI. Unless otherwise noted, all tables within
this document refer to IANA Assigned Numbers for the IPSEC DOI.

All multi-octet binary values are stored in network byte order.

4.2 IPSEC Situation Definition

Within ISAKMP, the Situation provides information that can be used by
the responder to make a policy determination about how to process the
incoming Security Association request. For the IPSEC DOI, the
Situation field is a four (4) octet bitmask with the following
values.

Situation Value
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04

All other values are reserved to IANA.

4.2.1 SIT_IDENTITY_ONLY

The SIT_IDENTITY_ONLY type specifies that the security association
will be identified by source identity information present in an
associated Identification Payload. See Section 4.6.2 for a complete
description of the various Identification types. All IPSEC DOI
implementations MUST support SIT_IDENTITY_ONLY by including an
Identification Payload in at least one of the phase I Oakley
exchanges ([IO], Section 5) and MUST abort any association setup that
does not include an Identification Payload.

If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
situation consists only of the 4 octet situation bitmap and does not
include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
or any subsequent label information. Conversely, if the initiator
supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
Identifier MUST be included in the situation payload.

4.2.2 SIT_SECRECY

The SIT_SECRECY type specifies that the security association is being

Piper Expires in 6 months [Page 3] 4]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

negotiated in an environment that requires labeled secrecy. If
SIT_SECRECY is present in the Situation bitmap, the Situation field
will be followed by variable-length data that includes a sensitivity
level and compartment bitmask. See Section 4.6.1 for a complete
description of the Security Association Payload format.

If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
set in the Situation bitmap and no secrecy level or category bitmaps
shall be included.

If a responder does not support SIT_SECRECY, a SITUATION-NOT-
SUPPORTED Notification Payload SHOULD be returned and the security
association setup MUST be aborted.

4.2.3 SIT_INTEGRITY

The SIT_INTEGRITY type specifies that the security association is
being negotiated in an environment that requires labeled integrity.
If SIT_INTEGRITY is present in the Situation bitmap, the Situation
field will be followed by variable-length data that includes an
integrity level and compartment bitmask. If SIT_SECRECY is also in
use for the association, the integrity information immediately
follows the variable-length secrecy level and categories. See
section 4.6.1 for a complete description of the Security Association
Payload format.

If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
NOT be set in the Situation bitmap and no integrity level or category
bitmaps shall be included.

If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
SUPPORTED Notification Payload SHOULD be returned and the security
association setup MUST be aborted.

4.3 IPSEC Security Policy Requirement Requirements

The IPSEC DOI does not impose specific security policy requirements
on any implementation. Host system policy issues are outside of the
scope of this document.

However, the following sections touch on some of the issues that must
be considered when designing an IPSEC DOI host implementation. This
section should be considered only informational in nature.

4.3.1 Key Management Issues

It is expected that many systems choosing to implement ISAKMP will
strive to provide a protected domain of execution for a combined

Piper Expires in 6 months [Page 4] 5]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

ISAKMP/Oakley key management daemon. On protected-mode multiuser
operating systems, this key management daemon will likely exist as a
separate privileged process.

In such an environment, a formalized API to introduce keying material
into the TCP/IP kernel may be desirable. The PF_KEY API [PFKEY] is
an example of one such API that provides an abstracted key management
interface. The IP Security architecture does not place any
requirements for structure or flow between a host TCP/IP kernel and
its key management provider.

4.3.2 Static Keying Issues

Host systems that implement static keys, either for use directly by
IPSEC, or for authentication purposes (see [IO] Section 5.3), should
take steps to protect the static keying material when it is not
residing in a protected memory domain or actively in use by the
TCP/IP kernel.

For example, on a laptop, one might choose to store the static keys
in a configuration store that is, itself, encrypted under a private
password.

Depending on the operating system and utility software installed, it
may not be possible to protect the static keys once they've been
loaded into the TCP/IP kernel, however they should not be trivially
recoverable on initial system startup without having to satisfy some
additional form of authentication.

4.3.3 Host Policy Issues

It is not realistic to assume that the transition to IPSEC will occur
overnight. Host systems must be prepared to implement flexible
policy lists that describe which systems they desire to speak
securely with and which systems they require speak securely to them.
Some notion of proxy firewall addresses may also be required.

A minimal approach is probably a static list of IP addresses, network
masks, and a security required flag or flags.

A more flexible implementation might consist of a list of wildcard
DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
firewall address. The wildcard DNS name would be used to match
incoming or outgoing IP addresses, the in/out bitmask would be used
to determine whether or not security was to be applied and in which
direction, and the optional firewall address would be used to
indicate whether or not tunnel mode would be needed to talk to the
target system though an intermediate firewall.

4.3.4 Certificate Management

Piper Expires in 6 months [Page 5] 6]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

4.3.4 Certificate Management

Host systems implementing a certificate-based authentication scheme
will need a mechanism for obtaining and managing a database of
certificates.

Secure DNS is to be one certificate distribution mechanism, however
the pervasive availability of secure DNS zones, in the short term, is
doubtful for many reasons. What's far more likely is that hosts will
need an ability to import certificates that they acquire through
secure, out-of-band mechanisms, as well as an ability to export their
own certificates for use by other systems.

However, manual certificate management should not be done so as to
preclude the ability to introduce dynamic certificate discovery
mechanisms and/or protocols as they become available.

4.4 IPSEC Assigned Numbers

The following sections list the Assigned Numbers for the IPSEC DOI
Security Protocol Identifiers, Transform Identifiers, and Security
Association Attribute Types.

4.4.1 IPSEC Security Protocol Identifiers

The ISAKMP proposal syntax was specifically designed to allow for the
simultaneous negotiation of multiple security protocol suites within
a single negotiation. As a result, the protocol suites listed below
form the set of protocols that can be negotiated at the same time.
It is a host policy decision as to what protocol suites might be
negotiated together.

The following table lists the values for the Security Protocol
Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
DOI.

Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4

The size of this field is one octet. The values 4-248 5-248 are reserved
to IANA. Values 249-255 are reserved for private use.

4.4.1.1 PROTO_ISAKMP

Piper Expires in 6 months [Page 7]

INTERNET DRAFT IPSEC DOI September 19, 1997

The PROTO_ISAKMP type specifies message protection required during
Phase I of the ISAKMP protocol. The specific protection mechanism

Piper Expires in 6 months [Page 6]

INTERNET DRAFT IPSEC DOI February 28, 1997
used for the IPSEC DOI is described in [IO]. All implementations
within the IPSEC DOI MUST support PROTO_ISAKMP.

NB: ISAKMP reserves the value one (1) across all DOI definitions.

4.4.1.2 PROTO_IPSEC_AH

The PROTO_IPSEC_AH type specifies IP packet data origin authentication. The
default AH transform includes provides data origin
authentication authentication, integrity
protection, and replay prevention. For export control
considerations, confidentiality MUST NOT be provided by any
PROTO_IPSEC_AH transform.

4.4.1.3 PROTO_IPSEC_ESP

The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Data
origin authentication,
Authentication, if required, must be provided as part of the ESP
transform. The default ESP transform includes data origin
authentication, confidentiality, and integrity protection, replay prevention. prevention, and
confidentiality.

4.4.1.4 PROTO_IPCOMP

The PROTO_IPCOMP type specifies IP packet compression.

4.4.2 IPSEC ISAKMP Transform Values

As part of an ISAKMP Phase I negotiation, the initiator's choice of
Key Exchange offerings is made using some host system policy
description. The actual selection of Key Exchange mechanism is made
using the standard ISAKMP Proposal Payload. The following table
lists the defined ISAKMP Phase I Transform Identifiers for the
Proposal Payload for the IPSEC DOI.

Transform Value
--------- -----
RESERVED 0
KEY_OAKLEY 1
KEY_MANUAL 2
KEY_KDC 3

The size of this field is one octet. The values 4-248 2-248 are reserved
to IANA. Values 249-255 are reserved for private use.

Within the ISAKMP and IPSEC DOI framework it is possible to define
key establishment protocols other than Oakley. Previous versions of
this document defined types both for manual keying and for schemes
based on use of a generic Key Distribution Center (KDC). These

Piper Expires in 6 months [Page 8]

INTERNET DRAFT IPSEC DOI September 19, 1997

identifiers have been removed from the current document.

The IPSEC DOI can still be extended later to include values for
additional non-Oakley key establishment protocols for ISAKMP and
IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
Protocol (GKMP) [RFC-2093].

4.4.2.1 KEY_OAKLEY

The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
key exchange as defined in the [IO] document. All implementations
within the IPSEC DOI MUST support KEY_OAKLEY.

4.4.2.2 KEY_MANUAL

The KEY_MANUAL type specifies that a shared secret key mechanism is

Piper Expires in 6 months [Page 7]

INTERNET DRAFT IPSEC DOI February 28, 1997

to be used in lieu of a dynamic key mechanism. Specific details of a
static key establishment protocol will be described in a future
document.

4.4.2.3 KEY_KDC

The KEY_KDC type specifies that a secret-key based Key Distribution
Center will be used to provide dynamic key exchange through a
Kerberos-like ticket protocol. Specific details of a KDC-based key
establishment protocol will be described in a future document.

4.4.3 IPSEC AH Transform Values

The Authentication Header Protocol (AH) defines one mandatory and
several optional transforms used to provide data origin
authentication. authentication,
integrity, and replay detection. The following table lists the
defined AH Transform Identifiers for the ISAKMP Proposal Payload for
the IPSEC DOI.

Transform ID Value
------------ -----
RESERVED 0
AH_MD5_KPDK 1
AH_MD5 2
AH_SHA 3
AH_DES 4

The size of this field is one octet. The values 4-248 5-248 are reserved
to IANA. Values 249-255 are reserved for private use.

4.4.3.1 AH_MD5_KPDK

The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key)
described in RFC-1826 and RFC-1828. RFC-1826. This mode MAY be used negotiated for compatibility
with existing older implementations. Implementations are not required to
support this mode.

4.4.3.2 AH_MD5

The AH_MD5 type specifies a generic AH transform using MD5. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic MD5 transform is currently undefined.

All implementations within the IPSEC DOI MUST support AH_MD5 along
with the HMAC and REPLAY attributes. Auth(HMAC-MD5) attribute. This suite is defined as the
HMAC-MD5
HMAC-MD5-96 transform described in RFC-2085. [HMACMD5].

Piper Expires in 6 months [Page 9]

INTERNET DRAFT IPSEC DOI September 19, 1997

4.4.3.3 AH_SHA

The AH_SHA type specifies a generic AH transform using SHA-1. The

Piper Expires in 6 months [Page 8]

INTERNET DRAFT IPSEC DOI February 28, 1997
actual protection suite is determined in concert with an associated
SA attribute list. A generic SHA transform is currently undefined.

All implementations within the IPSEC DOI are strongly encouraged to
support AH_SHA along with the HMAC and REPLAY attributes. Auth(HMAC-SHA) attribute. This suite
is defined as the HMAC-SHA HMAC-SHA-1-96 transform described in [HMACSHA].

4.4.3.4 AH_DES

The AH_DES type specifies a generic AH transform using DES. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic DES transform is currently undefined.

The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
to be the DES-MAC transform described in [DESMAC]. Implementations
are not required to support this mode.

4.4.4 IPSEC ESP Transform Identifiers

The Encapsulating Security Protocol Payload (ESP) defines one mandatory and
several
many optional transforms used to provide data confidentiality. The
following table lists the defined ESP Transform Identifiers for the
ISAKMP Proposal Payload for the IPSEC DOI.

Transform ID Value
------------ -----
RESERVED
ESP_NULL 0
ESP_DES_CBC
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_ARCFOUR 10

The size of this field is one octet. The values 5-248 11-248 are reserved
to IANA. Values 249-255 are reserved for private use.

4.4.4.1 ESP_DES_CBC ESP_NULL

Piper Expires in 6 months [Page 10]

INTERNET DRAFT IPSEC DOI September 19, 1997

The ESP_NULL type specifies no confidentiality is to be provided by
ESP. ESP_NULL is used when ESP is being used to tunnel packets which
require only authentication and integrity protection. See the Auth
Algorithm attribute description in Section 4.5 for additional
requirements relating to the use of ESP_NULL.

4.4.4.2 ESP_DES_IV64

The ESP_DES_CBC ESP_DES_IV64 type specifies the DES-CBC transform defined in RFC-
1827
RFC-1827 and RFC-1829. RFC-1829 using a 64-bit IV. This mode MAY be used negotiated
for compatibility with
existing older implementations. Implementations are
not required to support this mode.

4.4.4.2

4.4.4.3 ESP_DES

The ESP_DES type specifies a generic DES transform using DES-CBC.
The actual protection suite is determined in concert with an
associated SA attribute list. A generic transform is currently
undefined.

All implementations within the IPSEC DOI MUST support ESP_DES along
with the HMAC and REPLAY attributes. Auth(HMAC-MD5) attribute. This suite is defined as the
[Hughes] transform.

4.4.4.3 ESP_3DES

The ESP_3DES type specifies a generic triple-DES
[DES] transform, with authentication and integrity provided by HMAC
MD5.

4.4.4.4 ESP_3DES

The ESP_3DES type specifies a generic triple-DES transform. The
actual protection suite is determined in concert with an associated
SA attribute list. The generic transform is currently undefined.

Piper Expires in 6 months [Page 9]

INTERNET DRAFT IPSEC DOI February 28, 1997

All implementations within the IPSEC DOI are strongly encouraged encourage to
support ESP_3DES along with the HMAC and REPLAY attributes. Auth(HMAC-MD5) attribute. This suite
is defined as the [Naganand] transform.

4.4.4.4 [3DES] transform, with authentication and integrity
provided by HMAC MD5.

4.4.4.5 ESP_RC5

The ESP_RC5 type specifies the RC5 transform defined in [RC5].

4.4.4.6 ESP_IDEA

The ESP_IDEA type specifies the IDEA transform defined in [IDEA].

4.4.4.7 ESP_CAST

The ESP_CAST type specifies the CAST transform defined in [CAST].

Piper Expires in 6 months [Page 11]

INTERNET DRAFT IPSEC DOI September 19, 1997

4.4.4.8 ESP_BLOWFISH

The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
[BLOW].

4.4.4.9 ESP_3IDEA

The ESP_3IDEA type is reserved for triple-IDEA.

4.4.4.10 ESP_DES_IV32

The ESP_DES_IV32 type specifies the DES-CBC transform defined in
RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated
for compatibility with older implementations. Implementations are
not required to support this mode.

4.4.4.11 ESP_ARCFOUR

The ESP_ARCFOUR type specifies the ARCFOUR transform defined in
[ARCFOUR].

4.4.5 IPSEC IPCOMP Transform Identifiers

The IP Compression (IPCOMP) transforms define optional compression
algorithms that can be negotiated to provide for IP compression
before ESP encryption. The following table lists the defined IPCOMP
Transform Identifiers for the ISAKMP Proposal Payload within the
IPSEC DOI.

Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLAT 2
IPCOMP_LZS 3
IPCOMP_V42BIS 4

The size of this field is one octet. The values 5-248 are reserved
to IANA. Values 249-255 are reserved for private use.

4.4.5.1 IPCOMP_OUI

The IPCOMP_OUI type specifies a proprietary compression transform.
The IPCOMP_OUI type must be accompanied by an attribute which further
identifies the specific vendor algorithm.

4.4.5.2 IPCOMP_DEFLATE

Piper Expires in 6 months [Page 12]

INTERNET DRAFT IPSEC DOI September 19, 1997

The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
algorithm.

4.4.5.3 IPCOMP_LZS

The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
algorithm.

4.4.5.4 IPCOMP_V42BIS

The IPCOMP_V42BIS type specifies the use of V42bis compression.

4.5 IPSEC Security Association Attributes

The following SA attribute definitions are used in phase II of an
ISAKMP/Oakley negotiation. Attribute types can be either Basic (B)
or Variable-Length (V). Encoding of these attributes is defined in
the base ISAKMP specification.

Attribute Classes Types

class value type
-------------------------------------------------
Auth Key
SA Life Type 1 B
Auth Key
SA Life Duration 2 B/V
Enc Key Life Type
Group Description 3 B
Enc Key Life Duration
Encapsulation Mode 4 B/V
SA Life Type 5 B
SA Life Duration
Authentication Algorithm 5 B
Key Length 6 B/V
Replay Protection B
Key Rounds 7 B
Group Description
Compress Dictionary Size 8 B
CA Distinguished Name 9 B
Encapsulation Mode 10 B
HMAC
Compress Private Algorithm 11 B

Class Values

Auth Key Life Type
Auth Key Duration

Specifies 9 B/V

The size of this field is two octets, with the time-to-live high bit reserved for
the authentication key(s)
used in the corresponding AH HMAC transform.

Enc Key Life Type
Enc Key Duration

Specifies the time-to-live ISAKMP B/V encoding. The values 10-32000 are reserved to IANA.
Values 32001-32767 are for the encryption key(s)
using in the corresponding ESP transform. experimental use.

Class Values

SA Life Type
SA Duration

Piper Expires in 6 months [Page 10]

INTERNET DRAFT IPSEC DOI February 28, 1997

Specifies the time-to-live for the overall security
association. When the SA expires, all keys negotiated
under the association (AH or ESP) must be renegotiated
regardless of the time-to-live remaining for the keys. renegotiated.
The life type values are:

RESERVED 0

Piper Expires in 6 months [Page 13]

INTERNET DRAFT IPSEC DOI September 19, 1997

seconds 1
kilobytes 2

Values 3-61439 are reserved to IANA. Values 61440-65535
are for experimental use. For a given "Life Type," Life Type, the
value of the "Life Duration" Life Duration attribute defines the actual
length of the component lifetime -- either a number of
seconds, or a number of Kbytes that can be protected.

If unspecified, the default value shall be assumed to be
28800 seconds (8 hours) for Auth, Enc, and hours).

An SA lifetime.

Replay Protection Life Duration attribute MUST always follow
an SA Life Type which describes the units of duration.

See Section 4.5.4 for additional information relating to
lifetime notification.

Group Description
RESERVED 0
required
768-bit Oakley group 1
disallowed
1024-bit Oakley group 2
2048-bit Oakley group 3

Values 3-61439 4-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.

There is no default value for Replay Protection, as it

This attribute must be specified to correctly identify the applicable
transform.

Group Description included in PFS QM negotiations.

Encapsulation Mode
RESERVED 0
default group
Tunnel 1
Transport 2

Values 2-61439 3-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.

If unspecified, the default value shall be assumed to be
the default Oakley group ([IO], Section 5.5.1).

CA Distinguished Name
unspecified (host-dependent).

Authentication Algorithm
RESERVED 0
DNS Security
HMAC-MD5 1
HMAC-SHA-1 2
DES-MAC 3

Values 2-61439 4-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.

If unspecified, the default value shall be assumed to be

Piper Expires in 6 months [Page 11] 14]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

DNS Security (Section 4.8).

Encapsulation Mode
RESERVED 0
Tunnel 1
Transport 2

Values 3-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.

If unspecified, the

There is no default value shall be assumed to be
unspecified (host-dependent).

HMAC for Auth Algorithm, as it
must be specified to correctly identify the applicable
AH or ESP transform, except in the following case.

When negotiating ESP without authentication, the Auth
Algorithm attribute MUST NOT be included in the proposal.

When negotiating ESP without confidentiality, the Auth
Algorithm attribute MUST be included in the proposal and
the ESP transform ID must be ESP_NULL.

Key Length
RESERVED 0
MD5 1
SHA-1 2

Values 3-61439 are reserved to IANA. Values 61440-65535
are

There is no default value for private use among mutually consenting parties. Key Length, as it must be
specified for transforms using ciphers with variable key
lengths.

Key Rounds
RESERVED 0

There is no default value for HMAC Algorithm, Key Rounds, as it must be
specified to correctly identify for transforms using ciphers with varying
numbers of rounds.

Compression Dictionary Size
RESERVED 0

Specifies the applicable
transform. log2 maximum size of the dictionary.

There is no default value for dictionary size.

Compression Private Algorithm

Specifies a private vendor compression algorithm. The
first three (3) octets must be an IEEE assigned company_id
(OUI). The next octet may be a vendor specific compression
subtype, followed by zero or more octets of vendor data.

4.5.1 Required Attribute Support

To ensure basic interoperability, all implementations MUST support be
prepared to negotiate all of the following attributes:

Auth Key Life Type
Auth Key Duration
Enc Key Life Type
Enc Key Duration attributes.

SA Life Type
SA Duration
Replay Protection
HMAC
Auth Algorithm (MD5 required, SHA-1 optional)

Piper Expires in 6 months [Page 15]

INTERNET DRAFT IPSEC DOI September 19, 1997

4.5.2 Attribute List Parsing Requirement

To allow for flexible semantics, the IPSEC DOI requires that a
conforming ISAKMP implementation MUST correctly parse an attribute
list that contains multiple instances of the same attribute class, so
long as the different attribute entries do not conflict with one
another.

To see why this is important, the following example shows the binary

Piper Expires in 6 months [Page 12]

INTERNET DRAFT IPSEC DOI February 28, 1997
encoding of a four entry attribute list that specifies an Encryption
Key SA Lifetime
of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a
complete description of the attribute encoding format.)

Attribute #1:
0x80030001
0x80010001 (AF = 1, type = Enc Key SA Life Type, value = seconds)

Attribute #2:
0x00040004
0x00020004 (AF = 0, type = Enc Key SA Duration, length = 4 bytes)
0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)

Attribute #3:
0x80030002
0x80010002 (AF = 1, type = Enc Key SA Life Type, value = KB)

Attribute #4:
0x00040004
0x00020004 (AF = 0, type = Enc Key SA Duration, length = 4 bytes)
0x000186A0 (value = 0x186A0 = 100000KB = 100MB)

If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
Notification Payload SHOULD be returned and the security association
setup MUST be aborted.

4.6

4.5.3 Attribute Negotiation

If an implementation receives a defined IPSEC Payload Content

The following sections describe those ISAKMP payloads whose data
representations are dependent on DOI attribute (or
attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
SHOULD be sent and the applicable DOI.

4.6.1 Security Association Payload

The following diagram illustrates security association setup MUST be aborted,
unless the content attribute value is in the reserved range.

If an implementation receives an attribute value in the reserved
range, an implementation MAY chose to continue based on local policy.

4.5.4 Lifetime Notification

When an initiator offers an SA lifetime greater than what the
responder desires based on their local policy, the responder has
three choices: 1) fail the negotiation entirely; 2) complete the
negotiation but use a shorter lifetime than what was offered; 3)
complete the negotiation and send an advisory notification to the

Piper Expires in 6 months [Page 16]

INTERNET DRAFT IPSEC DOI September 19, 1997

initiator with the responder's true lifetime.

In the latter case, the IPSEC DOI requires the following: if the
initiator offers an SA lifetime longer than the responder is willing
to accept, the responder SHOULD include an ISAKMP Notification
Payload in the exchange that includes the responder's IPSEC SA
payload. When present, the Notification Payload MUST have the
following format:

o Payload Length - set to length of payload + size of Notify Data
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to eight (8) (two four octet IPSEC SPI's)
o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
o SPI - set to the two IPSEC SPI's
o Notification Data - contains an ISAKMP attribute list with the
responder's actual SA lifetime(s)

Implementation Note: saying that the Notification Data field contains
an attribute list is equivalent to saying that the Notification Data
field has zero length and the Notification Payload has an associated
attribute list.

4.6 IPSEC Payload Content

The following sections describe those ISAKMP payloads whose data
representations are dependent on the applicable DOI.

4.6.1 Security Association Payload

The following diagram illustrates the content of the Security
Association Payload for the IPSEC DOI. See Section 4.2 for a
description of the Situation bitmap.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Labeled Domain Identifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Piper Expires in 6 months [Page 13] 17]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

! Secrecy Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Security Association Payload Format

The Security Association Payload is defined as follows:

o Next Payload (2 octets) - Identifier for the payload type of
the next payload in the message. If the current payload is
the last in the message, this field will be zero (0).

o RESERVED (1 octet) - Unused, must be zero (0).

o Payload Length (2 octets) - Length, in octets, of the current
payload, including the generic header.

o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
which has been assigned the value one (1).

o Situation (4 octets) - Bitmask used to interpret the
remainder of the Security Association Payload. See Section
4.2 for a complete list of values.

o Labeled Domain Identifier (4 octets) - IANA Assigned Number
used to interpret the Secrecy and Integrity information.

o Secrecy Length (2 octets) - Specifies the length, in octets,
of the secrecy level identifier.

o RESERVED (2 octets) - Unused, must be zero (0).

o Secrecy Category Length (2 octets) - Specifies the length, in
bits, of the secrecy category (compartment) bitmap. bitmap, excluding
pad bits.

o Secrecy Category RESERVED (2 octets) - Unused, must be zero (0).

o Secrecy Category Bitmap (variable length) - A bitmap used to

Piper Expires in 6 months [Page 18]

INTERNET DRAFT IPSEC DOI September 19, 1997

designate secrecy categories (compartments) that are
required. The bitmap MUST be padded with zero (0) to the
next 32-bit boundry.

o Integrity Length (2 octets) - Specifies the length, in
octets, of the integrity level identifier.

Piper Expires in 6 months [Page 14]

INTERNET DRAFT IPSEC DOI February 28, 1997

o RESERVED (2 octets) - Unused, must be zero (0).

o Integrity Category Length (2 octets) - Specifies the length,
in bits, of the integrity category (compartment) bitmap. bitmap,
excluding pad bits.

o RESERVED (2 octets) - Unused, must be zero (0).

o Integrity Category Bitmap (variable length) - A bitmap used
to designate integrity categories (compartments) that are
required. The bitmap MUST be padded with zero (0) to the
next 32-bit boundry.

4.6.1.1 Labeled Domain Identifier Values

The following table lists the assigned values for the Labeled Domain
Identifier field contained in the Situation field of the Security
Association Payload.

Domain Value
------- -----
RESERVED 0

The values 1-0x7fffffff are reserved to IANA. Values 0x8000000-
0xffffffff are reserved for private use.

4.6.2 Identification Payload Content

The Identification Payload is used to identify the initiator of the
Security Association. The identity of the initiator SHOULD be used
by the responder to determine the correct host system security policy
requirement for the association. For example, a host might choose to
require data origin authentication and integrity without confidentiality (AH)
from a certain set of IP addresses and full authentication with
confidentiality (Hughes) (ESP) from another range of IP addresses. The
Identification Payload provides information that can be used by the
responder to make this decision.

The following diagram illustrates the content of the Identification
Payload.

Piper Expires in 6 months [Page 19]

INTERNET DRAFT IPSEC DOI September 19, 1997

Figure 2: Identification Payload Format

The Identification Payload field is fields are defined as follows:

Piper Expires in 6 months [Page 15]

INTERNET DRAFT IPSEC DOI February 28, 1997

o Next Payload (2 octets) - Identifier for the payload type of
the next payload in the message. If the current payload is
the last in the message, this field will be zero (0).

o RESERVED (1 octet) - Unused, must be zero (0).

o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.

o Identification Type (1 octet) - Value describing the
identity information found in the Identification Data field.

o Protocol ID (1 octet) - Value specifying an associated
IP protocol ID (e.g. UDP/TCP). A value of zero means that the
Protocol ID field should be ignored.

o Port (2 octets) - Value specifying an associated port.
A value of zero means that the Port field should be ignored.

o RESERVED (1 octet) Identification Data (variable length) - Unused, must be zero (0). Value, as indicated
by the Identification Type.

4.6.2.1 Identification Type Values

The following table lists the assigned values for the Identification
Type field found in the Identification Payload.

ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5

Piper Expires in 6 months [Page 20]

INTERNET DRAFT IPSEC DOI September 19, 1997

ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11

The size of this field is one octet. The values 9-248 12-248 are reserved
to IANA. Values 249-255 are reserved for private use.

For types where the ID entity is variable length, the size of the ID
entity is computed from size in the ID payload header.

When an ISAKMP/Oakley exchange is authenticated using certificates
(of any format), any ID's used for input to local policy decisions
SHOULD be contained in the certificate used in the authentication of
the exchange.

4.6.2.2 ID_IPV4_ADDR

The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.

4.6.2.3 ID_FQDN

The ID_FQDN type specifies a fully-qualified domain name string. An

Piper Expires in 6 months [Page 16]

INTERNET DRAFT IPSEC DOI February 28, 1997
example of a ID_FQDN is, "foo.bar.com". The string should not
contain any terminators.

4.6.2.4 ID_USER_FQDN

The ID_USER_FQDN type specifies a fully-qualified username string, An
example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should
not contain any terminators.

4.6.2.5 ID_IPV4_ADDR_SUBNET

The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
represented by two four (4) octet values. The first value is an IPv4
address. The second is an IPv4 network mask. Note that ones (1s) in
the network mask indicate that the corresponding bit in the address
is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.6 ID_IPV6_ADDR

The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
address.

4.6.2.7 ID_IPV6_ADDR_SUBNET

Piper Expires in 6 months [Page 21]

INTERNET DRAFT IPSEC DOI September 19, 1997

The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
represented by two sixteen (16) octet values. The first value is an
IPv6 address. The second is an IPv6 network mask. Note that ones
(1s) in the network mask indicate that the corresponding bit in the
address is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.8 ID_IPV4_ADDR_RANGE

The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
represented by two four (4) octet values. The first value is the
beginning IPv4 address (inclusive) and the second value is the ending
IPv4 address (inclusive). All addresses falling between the two
specified addresses are considered to be within the list.

4.6.2.9 ID_IPV6_ADDR_RANGE

The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
represented by two sixteen (16) octet values. The first value is the
beginning IPv6 address (inclusive) and the second value is the ending
IPv6 address (inclusive). All addresses falling between the two
specified addresses are considered to be within the list.

4.7 IPSEC Security Parameter Index (SPI) Encoding

ISAKMP defines the SPI field as eight octets in length, however the
IPSEC transforms use only four octets.

Piper Expires in 6 months [Page 17]

INTERNET DRAFT IPSEC DOI February 28, 1997

All implementation MUST use

4.6.2.10 ID_DER_ASN1_DN

The ID_DER_ASN1_DN type specifies the following mapping for binary DER encoding of an ASN.1
X.500 Distinguished Name [X.501] of the ISAKMP SPI
field in principal whose certificates
are being exchanged to establish the IPSEC DOI.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: ISAKMP SPI Encoding SA.

4.6.2.11 ID_DER_ASN1_GN

The ISAKMP SPI field is defined as follows:

o SPI - Security Parameter Index (4 octets) - contains ID_DER_ASN1_GN type specifies the
SPI value which identifies binary DER encoding of an ASN.1
X.500 GeneralName [X.509] of the security association.

o RESERVED (4 octets) - Unused, must be zero (0).

4.8 IPSEC Certificate Authorities principal whose certificates are
being exchanged to establish the SA.

4.6.2.12 ID_KEY_ID

The ISAKMP Certificate Request Payload allows either side of ID_KEY_ID type specifies an
ISAKMP negotiation opaque byte stream which may be used
to request its peer pass vendor-specific information necessary to provide a certificate chain
needed identify which pre-
shared key should be used to authenticate itself. The Certificate Request Payload
includes a list of acceptable Certificate Types and Certificate
Authorities. Appropriate certificate chains are then returned in a
Certificate Payload response.

The Aggressive mode
negotiations.

4.6.3 IPSEC DOI Notify Message Types

ISAKMP defines the following Certificate Authorities for the
processing two blocks of Certificate Request Payloads. See Section 4.5 Notify Message codes, one for
details on the specific data attribute type values errors and
one for these CAs.

Certificate Authority
---------------------
DNS Security

4.8.1 DNS Security

This CA type represents the combination status. ISAKMP also allocates a portion of KEY and SIG records, as
defined in RFC-2065, that can be used each block for authentication.
private use within a DOI. The
particular encoding required to formulate the Certificate Payload
(response) is TBD.

4.9 IPSEC DOI defines the following
private message types.

Piper Expires in 6 months [Page 22]

INTERNET DRAFT IPSEC DOI September 19, 1997

Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192

Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576

4.7 IPSEC Key Exchange Requirements

The IPSEC DOI introduces no additional Key Exchange types.

5. Security Considerations

Piper Expires in 6 months [Page 18]

INTERNET DRAFT Changes

The following changes were made relative to the IPSEC DOI February 28, 1997 V3, that
was posted to the IPSEC mailing list prior to the Munich IETF:

o added ESP transform identifiers for NULL and ARCFOUR
o renamed HMAC Algorithm to Auth Algorithm to accommodate
DES-MAC and optional authentication/integrity for ESP
o added AH and ESP DES-MAC algorithm identifiers
o removed KEY_MANUAL and KEY_KDC identifier definitions
o added lifetime duration MUST follow lifetype attribute to
SA Life Type and SA Life Duration attribute definition
o added lifetime notification and IPSEC DOI message type table
o added optional authentication and confidentiality
restrictions to MAC Algorithm attribute definition
o corrected attribute parsing example (used obsolete attribute)
o corrected several Internet Draft document references
o added ID_KEY_ID per ipsec list discussion (18-Mar-97)
o removed Group Description default for PFS QM ([IO] MUST)

6. Security Considerations

This entire draft pertains to a hybrid negotiated key management protocol,
combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate which negotiates
and derive derives keying material for security associations in a secure and
authenticated manner. Specific discussion of the various security
protocols and transforms identified in this document can be found in
the associated base documents. documents and in the cipher references.

Acknowledgements

This document is derived, in part, from previous works by Douglas
Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran
Atkinson also contributed suggestions and, in many cases, text.

Piper Expires in 6 months [Page 23]

INTERNET DRAFT IPSEC DOI September 19, 1997

References

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

[RFC-1826]

[AH] Kent, S., Atkinson, R., "IP Authentication Header," RFC-1826, August
1995.

[RFC-1827] draft-ietf-
ipsec-auth-header-01.txt.

[ARCFOUR] Thayer, R., "The ESP ARCFOUR Algorithm," draft-ietf-ipsec-
ciph-arcfour-00.txt.

[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP),"
RFC-1827, August 1995.

[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
MD5," RFC-1828, August 1995.

[RFC-1829] Karn, P., Metzger, P., Simpson, W., draft-ietf-ipsec-esp-v2-00.txt.

[BLOW] Adams, R., "The ESP DES-CBC
Transform," RFC-1829, August 1995.

[RFC-2065] Eastlake 3rd, D., Kaufman, Blowfish-CBC Algorithm Using an Explicit
IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt.

[CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm,"
draft-ietf-ipsec-ciph-cast128-cbc-00.txt.

[DES] Madson, C., "Domain Name System
Security Extensions," RFC-2065, January 1997.

[RFC-2085] Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-00.txt.

[3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an
Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt.

[DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
bitan-auth-des-mac-00.txt.

[HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5 "HMAC-MD5-96 IP Authentication with
Replay Prevention," RFC-2085, February 1997. draft-ietf-ipsec-ah-hmac-md5-96-00.txt.

[HMACSHA] Chang, S., Glenn, R., "HMAC-SHA "HMAC-SHA-1-96 IP Authentication with
Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt.

[Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay
Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt. draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt.

[IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV,"
draft-ietf-ipsec-ciph-idea-cbc-00.txt.

[IO] Carrel, D., Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley,"
draft-ietf-ipsec-isakmp-oakley-03.txt.
draft-ietf-ipsec-isakmp-oakley-04.txt.

[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management Protocol (ISAKMP),"
draft-ietf-ipsec-isakmp-07.{ps,txt}.
draft-ietf-ipsec-isakmp-08.{ps,txt}.

[OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
draft-ietf-ipsec-oakley-01.txt.

[ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security
Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-00.txt.

Piper Expires in 6 months [Page 19] 24]

INTERNET DRAFT IPSEC DOI February 28, September 19, 1997

[Naganand] Daraswamy, N., "Combined 3DES-CBC, HMAC and Replay
Detection Security Transform," draft-ietf-ipsec-esp-3des-md5-00.txt.

[OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
draft-ietf-ipsec-oakley-01.txt.

[PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key
Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in
progress. draft-mcdonald-pf-key-v2-03.txt.

[RC5] Howard, B., Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft-
baldwin-esp-rc5-00.txt.
ietf-ipsec-ciph-rc5-cbc-00.txt.

[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
Interconnection - The Directory: Models", CCITT/ITU Recommendation
X.501, 1993.

[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication Framework",
CCITT/ITU Recommendation X.509, 1993.

Author's Address:

Derrell Piper <piper@cisco.com>
cisco Systems
101 Cooper St.
Santa Cruz, California, 95060
United States of America
+1 408 457-5384

Piper Expires in 6 months [Page 20] 25]

----