Updated IPSEC DOI draft

Derrell Piper <piper@tgv.com> Mon, 09 December 1996 17:11 UTC

Received: from cnri by ietf.org id aa10051; 9 Dec 96 12:11 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa13508; 9 Dec 96 12:11 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05478 for ipsec-outgoing; Mon, 9 Dec 1996 11:47:51 -0500 (EST)
Message-Id: <199612091649.IAA01400@fluffy.cisco.com>
To: ipsec@tis.com
Subject: Updated IPSEC DOI draft
Date: Mon, 09 Dec 1996 08:49:38 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Folks,

Here's an updated IPSEC DOI draft that incorporates most of the comments
I've received since its initial posting.

Derrell

------ cut here ------






Network Working Group                                      Derrell Piper
INTERNET-DRAFT                                             cisco Systems
draft-ietf-ipsec-ipsec-doi-02.txt                       December 9, 1996


      The Internet IP Security Domain of Interpretation for ISAKMP
                  <draft-ietf-ipsec-ipsec-doi-02.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 inapproporiate 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.

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                December 9, 1996


   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

   The remainder of this document details the instantiation of these
   requirements for using the IP Security (IPSEC) protocols to provide
   data origin authentication 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.  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

      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]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


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.

4.2.2 SIT_SECRECY

   The SIT_SECRECY type specifies that the security association is being
   negotiated in an environment that requires labeled secrecy.  If
   SIT_SECRECY is present in the Situation bitmap, the Situation field



Piper                     Expires in 6 months           	[Page 3]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   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

   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
   ISAKMP/Oakley key management daemon.  On protected-mode multiuser
   operating systems, this key management daemon will likely exist as a



Piper                     Expires in 6 months           	[Page 4]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   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.

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

   Host systems implementing a certificate-based authentication scheme



Piper                     Expires in 6 months           	[Page 5]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   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

   The values 4-15360 are reserved to IANA.  Values 15361-16384 are
   reserved for private use.

   4.4.1.1 PROTO_ISAKMP

   The PROTO_ISAKMP type specifies message protection required during
   Phase I of the ISAKMP protocol.  The specific protection mechanism
   used for the IPSEC DOI is described in [IO].  All implementations



Piper                     Expires in 6 months           	[Page 6]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   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.  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, if required, must be provided as part of the
   ESP transform.  The default ESP transform includes data origin
   authentication and replay prevention.

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 values 4-15360 are reserved to IANA.  Values 15361-16384 are
   reserved for private use.

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



Piper                     Expires in 6 months           	[Page 7]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


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.  The following table lists the defined AH Transform
   Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.

       Transform                           Value
       ---------                           -----
       RESERVED                            0
       AH_MD5_KPDK                         1
       AH_MD5_HMAC                         2
       AH_MD5_HMAC_REPLAY                  3
       AH_SHA_MHAC_REPLAY                  4

   The values 5-15360 are reserved to IANA.  Values 15361-16384 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.  This mode should be used only
   for compatibility with existing implementations.

4.4.3.2 AH_MD5_HMAC

   The AH_MD5_HMAC type specifies the transform described in [HMAC].
   This mode should be used only for compatibility with existing
   implementations.

4.4.3.3 AH_MD5_HMAC_REPLAY

   The AH_MD5_HMAC_REPLAY type specifies the transform described in
   [HMACMD5].  This transform MUST be supported by all implementations
   and is the preferred AH transform for the IPSEC DOI.

4.4.3.4 AH_SHA_HMAC_REPLAY

   The AH_SHA_HMAC_REPLAY type specifies the transform described in
   [HMACSHA]. While not required, it is strongly recommended that all
   implementations include the AH_SHA_HMAC_REPLAY transform in addition



Piper                     Expires in 6 months           	[Page 8]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   to AH_MD5_HMAC_REPLAY.

4.4.4 IPSEC ESP Transform Identifiers

   The Encapsulating Security Protocol (ESP) defines one mandatory and
   several 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                            0
       ESP_DES_CBC_TRANSPORT               1
       ESP_DES_CBC_TUNNEL                  2
       ESP_3DES_CBC                        3
       ESP_DES_CBC_HMAC_REPLAY             4

   The values 5-15360 are reserved to IANA.  Values 15361-16384 are
   reserved for private use.

4.4.4.1 ESP_DES_CBC_TRANSPORT

   The ESP_DES_CBC_TRANSPORT type specifies the ESP transform described
   in RFC-1827 and RFC-1829, operating in Transport Mode.  This mode
   should be used only for compatibility with existing implementations.

4.4.4.2 ESP_DES_CBC_TUNNEL

   The ESP_DES_CBC_TUNNEL type specifies the ESP transform described in
   RFC-1827 and RFC-1829, operating in Tunnel Mode.  This mode should be
   used only for compatibility with existing implementations.

4.4.4.3 ESP_3DES_CBC

   The ESP_3DES_CBC type specifies the transform described in RFC-1851.
   This mode should be used only for compatiblity with existing
   implementations.

4.4.4.4 ESP_DES_CBC_HMAC_REPLAY

   The ESP_DES_CBC_HMAC_REPLAY type specifies the transform described in
   [Hughes].  This transform MUST be supported by all implementations
   and is the preferred ESP transform for the IPSEC DOI.

4.5 IPSEC Security Association Atttributes

   The following SA attribute definitions are used in phase II of an
   ISAKMP/Oakley negotation.  Attribute types can be either Basic (B) or



Piper                     Expires in 6 months           	[Page 9]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   Variable-Length (V).  Encoding of these attributes is defined in the
   base ISAKMP specification.

       Attribute Classes

             class               value           type
       -------------------------------------------------
       Auth Key Life Type          1               B
       Auth Key Life Duration      2               B/V
       Enc Key Life Type           3               B
       Enc Key Life Duration       4               B/V
       SA Life Type                5               B
       SA Life Duration            6               B/V
       Replay Protection           7               B
       Group Description           8               B
       CA Distinguished Name       9               B

       Class Values

         Auth Key Life Type
         Enc Key Life Type
         SA Life Type
           seconds                 1
           kilobytes               2

           Values 3-65000 are reserved to IANA.  Values 65001-65535
           are for experimental use.  For a given "Life Type," the
           value of the "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.

         Replay Protection
           not required            0
           required                1

           Values 2-65000 are reserved to IANA.  Values 65001-65535
           are for experimental use.

         Group Description
           default group           1       ([IO], Section 5.5.1)

           Values 2-32767 are reserved to IANA.  Values 32768-65535
           are for private use among mutually consenting parties.

         CA Distinguished Name
           DNS Security            1       (Section 4.8)

           Values 2-32767 are reserved to IANA.  Values 32768-65535



Piper                     Expires in 6 months          	[Page 10]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


           are for private use among mutually consenting parties.

4.5.1 Attribute List Parsing Requirement

   In order 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
   encoding of a four entry attribute list that specifies an Encryption
   Key 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  (AF = 1, type = Enc Key Life Type, value = seconds)

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

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

     Attribute #4:
       0x00040004  (AF = 0, type = Enc Key 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 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         !



Piper                     Expires in 6 months          	[Page 11]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                Domain of Interpretation (IPSEC)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                       Situation (bitmap)                      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                    Labeled Domain Identifier                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Secrecy Length (in octets)   !           RESERVED            !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Secrecy Level                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! 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 Intepretation (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,



Piper                     Expires in 6 months          	[Page 12]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


        of the secrecy level identifier.

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

     o  Secrecy Category Bitmap (variable length) - A bitmap used to
        designate secrecy categories (compartments) that are
        required.

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

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

     o  Integrity Category Bitmap (variable length) - A bitmap used
        to designate integrity categories (compartments) that are
        required.

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 without confidentiality (AH) from
   a certain set of IP addresses and full authentication with
   confidentiality (Hughes) 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.

    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



Piper                     Expires in 6 months          	[Page 13]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload !   RESERVED    !        Payload Length         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !   ID Type     !                  RESERVED                     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Identification Data                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Identification Payload Format

   The Identification Payload field 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
        identification data, including the generic header.

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

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

4.6.2.1 Identifiction 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_RANGE                  4
       ID_IPV6_ADDR                        5
       ID_IPV6_ADDR_RANGE                  6

   The values 6-500 are reserved to IANA.  Values 501-512 are reserved
   for private use.

4.6.2.2 ID_IPV4_ADDR

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




Piper                     Expires in 6 months          	[Page 14]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


4.6.2.3 ID_FQDN

   The ID_FQDN type specifies a fully-qualified domain name string.  An
   example of a ID_FQDN is, "foo.bar.com".

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

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

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

   All implementation MUST use the following mapping for the ISAKMP SPI
   field in 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




Piper                     Expires in 6 months          	[Page 15]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   The ISAKMP SPI field is defined as follows:

     o  SPI - Security Paramater Index (4 octets) - contains the
        SPI value which identifies the security association.

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

4.8 IPSEC Certificate Authorities

   The ISAKMP Certificate Request Payload allows either side of an
   ISAKMP negotiation to request its peer to provide a certificate chain
   needed 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 IPSEC DOI defines the following Certificate Authorities for the
   processing of Certificate Request Payloads.  See Section 4.5 for
   details on the specific data attribute type values for these CAs.

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

   4.8.1 DNS Security

   This CA type represents the combination of KEY and SIG records, as
   defined in [DNSSEC], that can be used for authentication.  The
   particular encoding required to formulate the Certificate Payload
   (response) is TBD.

4.9 IPSEC Key Exchange Requirements

   The IPSEC DOI introduces no additional Key Exhange types.

5. Security Considerations

   This entire draft pertains to a hybrid protocol, combining Oakley
   ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive 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.

Acknowledgements

   This document is derived, in part, from previous works by Douglas
   Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,



Piper                     Expires in 6 months          	[Page 16]

INTERNET DRAFT                 IPSEC DOI                December 9, 1996


   and Dave Carrel.

References

   [DNSSEC] Eastlake, Donald E., Kaufman, Charles W., "Domain Name
   System Security Extensions", draft-ietf-dnssec-secext-10.txt.

   [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
   for Message Authentication", draft-ietf-ipsec-hmac-md5-01.txt.

   [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with
   Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-03.txt.

   [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA 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.

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

   [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol (ISAKMP),"
   draft-ietf-ipsec-isakmp-06.{ps,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.

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