rfc2407.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   requirement for the association.  For example, a host might choose to
   require authentication and integrity without confidentiality (AH)
   from a certain set of IP addresses and full authentication with
   confidentiality (ESP) from another range of IP addresses.  The
   Identification Payload provides information that can be used by the
   responder to make this decision.

   During Phase I negotiations, the ID port and protocol fields MUST be
   set to zero or to UDP port 500.  If an implementation receives any
   other values, this MUST be treated as an error and the security
   association setup MUST be aborted.  This event SHOULD be auditable.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload !   RESERVED    !        Payload Length         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !   ID Type     !  Protocol ID  !             Port              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Identification Data                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Identification Payload Format

   The Identification Payload fields are defined as follows:

     o  Next Payload (1 octet) - 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.



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


     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  Identification Data (variable length) - 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
       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

   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 IKE 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
   example of a ID_FQDN is, "foo.bar.com".  The string should not
   contain any terminators.




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


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, "[e-mail]".  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

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

   The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1
   X.500 Distinguished Name [X.501] of the principal whose certificates
   are being exchanged to establish the SA.



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


4.6.2.11 ID_DER_ASN1_GN

   The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1
   X.500 GeneralName [X.509] of the principal whose certificates are
   being exchanged to establish the SA.

4.6.2.12 ID_KEY_ID

   The ID_KEY_ID type specifies an opaque byte stream which may be used
   to pass vendor-specific information necessary to identify which pre-
   shared key should be used to authenticate Aggressive mode
   negotiations.

4.6.3 IPSEC Notify Message Types

   ISAKMP defines two blocks of Notify Message codes, one for errors and
   one for status messages.  ISAKMP also allocates a portion of each
   block for private use within a DOI.  The IPSEC DOI defines the
   following private message types for its own use.

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

       Notify Messages - Status Types      Value
       ------------------------------      -----
       RESPONDER-LIFETIME                  24576
       REPLAY-STATUS                       24577
       INITIAL-CONTACT                     24578

   Notification Status Messages MUST be sent under the protection of an
   ISAKMP SA: either as a payload in the last Main Mode exchange; in a
   separate Informational Exchange after Main Mode or Aggressive Mode
   processing is complete; or as a payload in any Quick Mode exchange.
   These messages MUST NOT be sent in Aggressive Mode exchange, since
   Aggressive Mode does not provide the necessary protection to bind the
   Notify Status Message to the exchange.

   Nota Bene: a Notify payload is fully protected only in Quick Mode,
   where the entire payload is included in the HASH(n) digest.  In Main
   Mode, while the notify payload is encrypted, it is not currently
   included in the HASH(n) digests.  As a result, an active substitution
   attack on the Main Mode ciphertext could cause the notify status
   message type to be corrupted.  (This is true, in general, for the
   last message of any Main Mode exchange.)  While the risk is small, a
   corrupt notify message might cause the receiver to abort the entire
   negotiation thinking that the sender encountered a fatal error.




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


   Implementation Note: the ISAKMP protocol does not guarantee delivery
   of Notification Status messages when sent in an ISAKMP Informational
   Exchange.  To ensure receipt of any particular message, the sender
   SHOULD include a Notification Payload in a defined Main Mode or Quick
   Mode exchange which is protected by a retransmission timer.

4.6.3.1 RESPONDER-LIFETIME

   The RESPONDER-LIFETIME status message may be used to communicate the
   IPSEC SA lifetime chosen by the responder.

   When present, the Notification Payload MUST have the following
   format:

     o  Payload Length - set to length of payload + size of data (var)
     o  DOI - set to IPSEC DOI (1)
     o  Protocol ID - set to selected Protocol ID from chosen SA
     o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
        cookies) or four (4) (one IPSEC SPI)
     o  Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
     o  SPI - set to the two ISAKMP cookies or to the sender's inbound
        IPSEC SPI
     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.3.2 REPLAY-STATUS

   The REPLAY-STATUS status message may be used for positive
   confirmation of the responder's election on whether or not he is to
   perform anti-replay detection.

   When present, the Notification Payload MUST have the following
   format:

     o  Payload Length - set to length of payload + size of data (4)
     o  DOI - set to IPSEC DOI (1)
     o  Protocol ID - set to selected Protocol ID from chosen SA
     o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
        cookies) or four (4) (one IPSEC SPI)
     o  Notify Message Type - set to REPLAY-STATUS
     o  SPI - set to the two ISAKMP cookies or to the sender's inbound
        IPSEC SPI
     o  Notification Data - a 4 octet value:



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


          0 = replay detection disabled
          1 = replay detection enabled

4.6.3.3 INITIAL-CONTACT

   The INITIAL-CONTACT status message may be used when one side wishes
   to inform the other that this is the first SA being established with
   the remote system.  The receiver of this Notification Message might
   then elect to delete any existing SA's it has for the sending system
   under the assumption that the sending system has rebooted and no
   longer has access to the original SA's and their associated keying
   material.  When used, the content of the Notification Data field
   SHOULD be null (i.e. the Payload Length should be set to the fixed
   length of Notification Payload).

   When present, the Notification Payload MUST have the following
   format:

     o  Payload Length - set to length of payload + size of data (0)
     o  DOI - set to IPSEC DOI (1)
     o  Protocol ID - set to selected Protocol ID from chosen SA
     o  SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
     o  Notify Message Type - set to INITIAL-CONTACT
     o  SPI - set to the two ISAKMP cookies
     o  Notification Data - <not included>

4.7 IPSEC Key Exchange Requirements

   The IPSEC DOI introduces no additional Key Exchange types.

5. Security Considerations

   This entire memo pertains to the Internet Key Exchange protocol
   ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to
   provide for the derivation of cryptographic keying material 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 and in the cipher references.

6. IANA Considerations

   This document contains many "magic" numbers to be maintained by the
   IANA.  This section explains the criteria to be used by the IANA to
   assign additional numbers in each of these lists.  All values not
   explicitly defined in previous sections are reserved to IANA.






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


6.1 IPSEC Situation Definition

   The Situation Definition is a 32-bit bitmask which represents the
   environment under which the IPSEC SA proposal and negotiation is
   carried out.  Requests for assignments of new situations must be
   accompanied by an RFC which describes the interpretation for the
   associated bit.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The upper two bits are reserved for private use amongst cooperating