rfc2407.txt

RFC 的详细文档！

Network Working Group                                           D. Piper
Request for Comments: 2407                               Network Alchemy
Category: Standards Track                                  November 1998


      The Internet IP Security Domain of Interpretation for ISAKMP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

IESG Note

   Section 4.4.4.2 states, "All implememtations within the IPSEC DOI
   MUST support ESP_DES...".  Recent work in the area of cryptanalysis
   suggests that DES may not be sufficiently strong for many
   applications.  Therefore, it is very likely that the IETF will
   deprecate the use of ESP_DES as a mandatory cipher suite in the near
   future.  It will remain as an optional use protocol.  Although the
   IPsec working group and the IETF in general have not settled on an
   alternative algorithm (taking into account concerns of security and
   performance), implementers may want to heed the recommendations of
   section 4.4.4.3 on the use of ESP_3DES.

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, payloads, and processing guidelines
   that occur within a given Domain of Interpretation (DOI).  This
   document defines the Internet IP Security DOI (IPSEC DOI), which
   instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate
   security associations.

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






Piper                       Standards Track                     [Page 1]

RFC 2407          IP Security Domain of Interpretation     November 1998


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
   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 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
   authentication, integrity, and/or confidentiality for IP packets sent
   between cooperating host systems and/or firewalls.

   For a description of the overall IPSEC architecture, see [ARCH],
   [AH], and [ESP].

3. Terms and Definitions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC 2119].

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 (IPSEC DOI) is one (1).  Within the IPSEC
   DOI, all well-known identifiers MUST be registered with the IANA
   under the IPSEC DOI.  Unless otherwise noted, all tables within this
   document refer to IANA Assigned Numbers for the IPSEC DOI.  See
   Section 6 for further information relating to the IANA registry for
   the IPSEC DOI.

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




Piper                       Standards Track                     [Page 2]

RFC 2407          IP Security Domain of Interpretation     November 1998


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

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 ([IKE], 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
   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.



Piper                       Standards Track                     [Page 3]

RFC 2407          IP Security Domain of Interpretation     November 1998


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 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 IKE
   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 IP Security
   architecture does not place any requirements for structure or flow
   between a host TCP/IP kernel and its key management provider.









Piper                       Standards Track                     [Page 4]

RFC 2407          IP Security Domain of Interpretation     November 1998


4.3.2 Static Keying Issues

   Host systems that implement static keys, either for use directly by
   IPSEC, or for authentication purposes (see [IKE] Section 5.4), 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
   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




Piper                       Standards Track                     [Page 5]

RFC 2407          IP Security Domain of Interpretation     November 1998


   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:
   Situation Identifiers, Protocol Identifiers, Transform Identifiers,
   AH, ESP, and IPCOMP Transform Identifiers, Security Association
   Attribute Type Values, Labeled Domain Identifiers, ID Payload Type
   Values, and Notify Message Type Values.

4.4.1 IPSEC Security Protocol Identifier

   The ISAKMP proposal syntax was specifically designed to allow for the
   simultaneous negotiation of multiple Phase II 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

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 [IKE].  All implementations
   within the IPSEC DOI MUST support PROTO_ISAKMP.

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