rfc2409.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,489 行 · 第 1/5 页

   Quick Mode, Informational, or New Group exchange. In other words, the
   cookies MUST NOT swap places when the direction of the ISAKMP SA
   changes.

   With the use of ISAKMP phases, an implementation can accomplish very
   fast keying when necessary.  A single phase 1 negotiation may be used
   for more than one phase 2 negotiation.  Additionally a single phase 2
   negotiation can request multiple Security Associations.  With these
   optimizations, an implementation can see less than one round trip per
   SA as well as less than one DH exponentiation per SA.  "Main Mode"
   for phase 1 provides identity protection.  When identity protection
   is not needed, "Aggressive Mode" can be used to reduce round trips
   even further.  Developer hints for doing these optimizations are
   included below. It should also be noted that using public key
   encryption to authenticate an Aggressive Mode exchange will still
   provide identity protection.

   This protocol does not define its own DOI per se. The ISAKMP SA,
   established in phase 1, MAY use the DOI and situation from a non-
   ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an
   implementation MAY choose to restrict use of the ISAKMP SA for
   establishment of SAs for services of the same DOI. Alternately, an
   ISAKMP SA MAY be established with the value zero in both the DOI and
   situation (see [MSST98] for a description of these fields) and in
   this case implementations will be free to establish security services
   for any defined DOI using this ISAKMP SA. If a DOI of zero is used
   for establishment of a phase 1 SA, the syntax of the identity
   payloads used in phase 1 is that defined in [MSST98] and not from any
   DOI-- e.g. [Pip97]-- which may further expand the syntax and
   semantics of identities.

   The following attributes are used by IKE and are negotiated as part
   of the ISAKMP Security Association.  (These attributes pertain only
   to the ISAKMP Security Association and not to any Security
   Associations that ISAKMP may be negotiating on behalf of other
   services.)



Harkins & Carrel            Standards Track                     [Page 6]

RFC 2409                          IKE                      November 1998


      - encryption algorithm

      - hash algorithm

      - authentication method

      - information about a group over which to do Diffie-Hellman.

   All of these attributes are mandatory and MUST be negotiated. In
   addition, it is possible to optionally negotiate a psuedo-random
   function ("prf").  (There are currently no negotiable pseudo-random
   functions defined in this document. Private use attribute values can
   be used for prf negotiation between consenting parties). If a "prf"
   is not negotiation, the HMAC (see [KBC96]) version of the negotiated
   hash algorithm is used as a pseudo-random function. Other non-
   mandatory attributes are described in Appendix A. The selected hash
   algorithm MUST support both native and HMAC modes.

   The Diffie-Hellman group MUST be either specified using a defined
   group description (section 6) or by defining all attributes of a
   group (section 5.6). Group attributes (such as group type or prime--
   see Appendix A) MUST NOT be offered in conjunction with a previously
   defined group (either a reserved group description or a private use
   description that is established after conclusion of a New Group Mode
   exchange).

   IKE implementations MUST support the following attribute values:

      - DES [DES] in CBC mode with a weak, and semi-weak, key check
      (weak and semi-weak keys are referenced in [Sch96] and listed in
      Appendix A). The key is derived according to Appendix B.

      - MD5 [MD5] and SHA [SHA}.

      - Authentication via pre-shared keys.

      - MODP over default group number one (see below).

   In addition, IKE implementations SHOULD support: 3DES for encryption;
   Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA]
   signatures and authentication with RSA public key encryption; and
   MODP group number 2.  IKE implementations MAY support any additional
   encryption algorithms defined in Appendix A and MAY support ECP and
   EC2N groups.

   The IKE modes described here MUST be implemented whenever the IETF
   IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes
   described here.



Harkins & Carrel            Standards Track                     [Page 7]

RFC 2409                          IKE                      November 1998


5. Exchanges

   There are two basic methods used to establish an authenticated key
   exchange: Main Mode and Aggressive Mode. Each generates authenticated
   keying material from an ephemeral Diffie-Hellman exchange. Main Mode
   MUST be implemented; Aggressive Mode SHOULD be implemented. In
   addition, Quick Mode MUST be implemented as a mechanism to generate
   fresh keying material and negotiate non-ISAKMP security services. In
   addition, New Group Mode SHOULD be implemented as a mechanism to
   define private groups for Diffie-Hellman exchanges. Implementations
   MUST NOT switch exchange types in the middle of an exchange.

   Exchanges conform to standard ISAKMP payload syntax, attribute
   encoding, timeouts and retransmits of messages, and informational
   messages-- e.g a notify response is sent when, for example, a
   proposal is unacceptable, or a signature verification or decryption
   was unsuccessful, etc.

   The SA payload MUST precede all other payloads in a phase 1 exchange.
   Except where otherwise noted, there are no requirements for ISAKMP
   payloads in any message to be in any particular order.

   The Diffie-Hellman public value passed in a KE payload, in either a
   phase 1 or phase 2 exchange, MUST be the length of the negotiated
   Diffie-Hellman group enforced, if necessary, by pre-pending the value
   with zeros.

   The length of nonce payload MUST be between 8 and 256 bytes
   inclusive.

   Main Mode is an instantiation of the ISAKMP Identity Protect
   Exchange: The first two messages negotiate policy; the next two
   exchange Diffie-Hellman public values and ancillary data (e.g.
   nonces) necessary for the exchange; and the last two messages
   authenticate the Diffie-Hellman Exchange. The authentication method
   negotiated as part of the initial ISAKMP exchange influences the
   composition of the payloads but not their purpose. The XCHG for Main
   Mode is ISAKMP Identity Protect.

   Similarly, Aggressive Mode is an instantiation of the ISAKMP
   Aggressive Exchange. The first two messages negotiate policy,
   exchange Diffie-Hellman public values and ancillary data necessary
   for the exchange, and identities.  In addition the second message
   authenticates the responder. The third message authenticates the
   initiator and provides a proof of participation in the exchange. The
   XCHG for Aggressive Mode is ISAKMP Aggressive.  The final message MAY
   NOT be sent under protection of the ISAKMP SA allowing each party to




Harkins & Carrel            Standards Track                     [Page 8]

RFC 2409                          IKE                      November 1998


   postpone exponentiation, if desired, until negotiation of this
   exchange is complete. The graphic depictions of Aggressive Mode show
   the final payload in the clear; it need not be.

   Exchanges in IKE are not open ended and have a fixed number of
   messages.  Receipt of a Certificate Request payload MUST NOT extend
   the number of messages transmitted or expected.

   Security Association negotiation is limited with Aggressive Mode. Due
   to message construction requirements the group in which the Diffie-
   Hellman exchange is performed cannot be negotiated. In addition,
   different authentication methods may further constrain attribute
   negotiation. For example, authentication with public key encryption
   cannot be negotiated and when using the revised method of public key
   encryption for authentication the cipher and hash cannot be
   negotiated. For situations where the rich attribute negotiation
   capabilities of IKE are required Main Mode may be required.

   Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG
   values for Quick Mode and New Group Mode are defined in Appendix A.

   Main Mode, Aggressive Mode, and Quick Mode do security association
   negotiation. Security Association offers take the form of Tranform
   Payload(s) encapsulated in Proposal Payload(s) encapsulated in
   Security Association (SA) payload(s). If multiple offers are being
   made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
   take the form of multiple Transform Payloads for a single Proposal
   Payload in a single SA payload. To put it another way, for phase 1
   exchanges there MUST NOT be multiple Proposal Payloads for a single
   SA payload and there MUST NOT be multiple SA payloads. This document
   does not proscribe such behavior on offers in phase 2 exchanges.

   There is no limit on the number of offers the initiator may send to
   the responder but conformant implementations MAY choose to limit the
   number of offers it will inspect for performance reasons.

   During security association negotiation, initiators present offers
   for potential security associations to responders. Responders MUST
   NOT modify attributes of any offer, attribute encoding excepted (see
   Appendix A).  If the initiator of an exchange notices that attribute
   values have changed or attributes have been added or deleted from an
   offer made, that response MUST be rejected.

   Four different authentication methods are allowed with either Main
   Mode or Aggressive Mode-- digital signature, two forms of
   authentication with public key encryption, or pre-shared key. The
   value SKEYID is computed seperately for each authentication method.




Harkins & Carrel            Standards Track                     [Page 9]

RFC 2409                          IKE                      November 1998


     For signatures:            SKEYID = prf(Ni_b | Nr_b, g^xy)
     For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
   CKY-R)
     For pre-shared keys:       SKEYID = prf(pre-shared-key, Ni_b |
   Nr_b)

   The result of either Main Mode or Aggressive Mode is three groups of
   authenticated keying material:

      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

   and agreed upon policy to protect further communications. The values
   of 0, 1, and 2 above are represented by a single octet. The key used
   for encryption is derived from SKEYID_e in an algorithm-specific
   manner (see appendix B).

   To authenticate either exchange the initiator of the protocol
   generates HASH_I and the responder generates HASH_R where:

    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

   For authentication with digital signatures, HASH_I and HASH_R are
   signed and verified; for authentication with either public key
   encryption or pre-shared keys, HASH_I and HASH_R directly
   authenticate the exchange.  The entire ID payload (including ID type,
   port, and protocol but excluding the generic header) is hashed into
   both HASH_I and HASH_R.

   As mentioned above, the negotiated authentication method influences
   the content and use of messages for Phase 1 Modes, but not their
   intent.  When using public keys for authentication, the Phase 1
   exchange can be accomplished either by using signatures or by using
   public key encryption (if the algorithm supports it). Following are
   Phase 1 exchanges with different authentication options.

5.1 IKE Phase 1 Authenticated With Signatures

   Using signatures, the ancillary information exchanged during the
   second roundtrip are nonces; the exchange is authenticated by signing
   a mutually obtainable hash. Main Mode with signature authentication
   is described as follows:







Harkins & Carrel            Standards Track                    [Page 10]

RFC 2409                          IKE                      November 1998


        Initiator                          Responder
       -----------                        -----------
        HDR, SA                     -->
                                    <--    HDR, SA
        HDR, KE, Ni                 -->
                                    <--    HDR, KE, Nr
        HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R

   Aggressive mode with signatures in conjunction with ISAKMP is
   described as follows:

        Initiator                          Responder
       -----------                        -----------
        HDR, SA, KE, Ni, IDii       -->
                                    <--    HDR, SA, KE, Nr, IDir,
                                                [ CERT, ] SIG_R
        HDR, [ CERT, ] SIG_I        -->

   In both modes, the signed data, SIG_I or SIG_R, is the result of the
   negotiated digital signature algorithm applied to HASH_I or HASH_R
   respectively.

   In general the signature will be over HASH_I and HASH_R as above
   using the negotiated prf, or the HMAC version of the negotiated hash
   function (if no prf is negotiated). However, this can be overridden
   for construction of the signature if the signature algorithm is tied
   to a particular hash algorithm (e.g. DSS is only defined with SHA's
   160 bit output). In this case, the signature will be over HASH_I and
   HASH_R as above, except using the HMAC version of the hash algorithm