rfc2409.txt

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

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


   The message ID in the ISAKMP header identifies a Quick Mode in
   progress for a particular ISAKMP SA which itself is identified by the
   cookies in the ISAKMP header. Since each instance of a Quick Mode
   uses a unique initialization vector (see Appendix B) it is possible
   to have multiple simultaneous Quick Modes, based off a single ISAKMP
   SA, in progress at any one time.

   Quick Mode is essentially a SA negotiation and an exchange of nonces
   that provides replay protection. The nonces are used to generate
   fresh key material and prevent replay attacks from generating bogus
   security associations.  An optional Key Exchange payload can be
   exchanged to allow for an additional Diffie-Hellman exchange and
   exponentiation per Quick Mode. While use of the key exchange payload
   with Quick Mode is optional it MUST be supported.

   Base Quick Mode (without the KE payload) refreshes the keying
   material derived from the exponentiation in phase 1. This does not
   provide PFS.  Using the optional KE payload, an additional
   exponentiation is performed and PFS is provided for the keying
   material.

   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.  If the client identities are not acceptable to the Quick
   Mode responder (due to policy or other reasons), a Notify payload
   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.

   The client identities are used to identify and direct traffic to the
   appropriate tunnel in cases where multiple tunnels exist between two
   peers and also to allow for unique and shared SAs with different
   granularities.

   All offers made during a Quick Mode are logically related and must be
   consistant. For example, if a KE payload is sent, the attribute
   describing the Diffie-Hellman group (see section 6.1 and [Pip97])
   MUST be included in every transform of every proposal of every SA
   being negotiated. Similarly, if client identities are used, they MUST
   apply to every SA in the negotiation.

   Quick Mode is defined as follows:






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


        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), SA, Ni
          [, KE ] [, IDci, IDcr ] -->
                                  <--    HDR*, HASH(2), SA, Nr
                                               [, KE ] [, IDci, IDcr ]
        HDR*, HASH(3)             -->

   Where:
   HASH(1) is the prf over the message id (M-ID) from the ISAKMP header
   concatenated with the entire message that follows the hash including
   all payload headers, but excluding any padding added for encryption.
   HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
   minus the payload header-- is added after M-ID but before the
   complete message.  The addition of the nonce to HASH(2) is for a
   liveliness proof. HASH(3)-- for liveliness-- is the prf over the
   value zero represented as a single octet, followed by a concatenation
   of the message id and the two nonces-- the initiator's followed by
   the responder's-- minus the payload header. In other words, the
   hashes for the above exchange are:

   HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
   HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
   IDcr )
   HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

   With the exception of the HASH, SA, and the optional ID payloads,
   there are no payload ordering restrictions on Quick Mode. HASH(1) and
   HASH(2) may differ from the illustration above if the order of
   payloads in the message differs from the illustrative example or if
   any optional payloads, for example a notify payload, have been
   chained to the message.

   If PFS is not needed, and KE payloads are not exchanged, the new
   keying material is defined as

       KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

   If PFS is desired and KE payloads were exchanged, the new keying
   material is defined as

       KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

   where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
   exchange of this Quick Mode.

   In either case, "protocol" and "SPI" are from the ISAKMP Proposal
   Payload that contained the negotiated Transform.



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


   A single SA negotiation results in two security assocations-- one
   inbound and one outbound. Different SPIs for each SA (one chosen by
   the initiator, the other by the responder) guarantee a different key
   for each direction.  The SPI chosen by the destination of the SA is
   used to derive KEYMAT for that SA.

   For situations where the amount of keying material desired is greater
   than that supplied by the prf, KEYMAT is expanded by feeding the
   results of the prf back into itself and concatenating results until
   the required keying material has been reached. In other words,

      KEYMAT = K1 | K2 | K3 | ...
      where
        K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
        K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
        Nr_b)
        K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
        Nr_b)
        etc.

   This keying material (whether with PFS or without, and whether
   derived directly or through concatenation) MUST be used with the
   negotiated SA. It is up to the service to define how keys are derived
   from the keying material.

   In the case of an ephemeral Diffie-Hellman exchange in Quick Mode,
   the exponential (g(qm)^xy) is irretreivably removed from the current
   state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation)
   continue to protect and authenticate the ISAKMP SA and SKEYID_d
   continues to be used to derive keys.

   Using Quick Mode, multiple SA's and keys can be negotiated with one
   exchange as follows:

        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), SA0, SA1, Ni,
          [, KE ] [, IDci, IDcr ] -->
                                  <--    HDR*, HASH(2), SA0, SA1, Nr,
                                            [, KE ] [, IDci, IDcr ]
        HDR*, HASH(3)             -->

   The keying material is derived identically as in the case of a single
   SA. In this case (negotiation of two SA payloads) the result would be
   four security associations-- two each way for both SAs.






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


5.6 New Group Mode

   New Group Mode MUST NOT be used prior to establishment of an ISAKMP
   SA. The description of a new group MUST only follow phase 1
   negotiation.  (It is not a phase 2 exchange, though).

        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), SA        -->
                                 <--     HDR*, HASH(2), SA

   where HASH(1) is the prf output, using SKEYID_a as the key, and the
   message-ID from the ISAKMP header concatenated with the entire SA
   proposal, body and header, as the data; HASH(2) is the prf output,
   using SKEYID_a as the key, and the message-ID from the ISAKMP header
   concatenated with the reply as the data. In other words the hashes
   for the above exchange are:

      HASH(1) = prf(SKEYID_a, M-ID | SA)
      HASH(2) = prf(SKEYID_a, M-ID | SA)

   The proposal will specify the characteristics of the group (see
   appendix A, "Attribute Assigned Numbers"). Group descriptions for
   private Groups MUST be greater than or equal to 2^15.  If the group
   is not acceptable, the responder MUST reply with a Notify payload
   with the message type set to ATTRIBUTES-NOT-SUPPORTED (13).

   ISAKMP implementations MAY require private groups to expire with the
   SA under which they were established.

   Groups may be directly negotiated in the SA proposal with Main Mode.
   To do this the component parts-- for a MODP group, the type, prime
   and generator; for a EC2N group the type, the Irreducible Polynomial,
   Group Generator One, Group Generator Two, Group Curve A, Group Curve
   B and Group Order-- are passed as SA attributes (see Appendix A).
   Alternately, the nature of the group can be hidden using New Group
   Mode and only the group identifier is passed in the clear during
   phase 1 negotiation.

5.7 ISAKMP Informational Exchanges

   This protocol protects ISAKMP Informational Exchanges when possible.
   Once the ISAKMP security association has been established (and
   SKEYID_e and SKEYID_a have been generated) ISAKMP Information
   Exchanges, when used with this protocol, are as follows:






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


        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), N/D      -->

   where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete
   Payload and HASH(1) is the prf output, using SKEYID_a as the key, and
   a M-ID unique to this exchange concatenated with the entire
   informational payload (either a Notify or Delete) as the data. In
   other words, the hash for the above exchange is:

      HASH(1) = prf(SKEYID_a, M-ID | N/D)

   As noted the message ID in the ISAKMP header-- and used in the prf
   computation-- is unique to this exchange and MUST NOT be the same as
   the message ID of another phase 2 exchange which generated this
   informational exchange. The derivation of the initialization vector,
   used with SKEYID_e to encrypt this message, is described in Appendix
   B.

   If the ISAKMP security association has not yet been established at
   the time of the Informational Exchange, the exchange is done in the
   clear without an accompanying HASH payload.

6 Oakley Groups

   With IKE, the group in which to do the Diffie-Hellman exchange is
   negotiated. Four groups-- values 1 through 4-- are defined below.
   These groups originated with the Oakley protocol and are therefore
   called "Oakley Groups". The attribute class for "Group" is defined in
   Appendix A. All values 2^15 and higher are used for private group
   identifiers. For a discussion on the strength of the default Oakley
   groups please see the Security Considerations section below.

   These groups were all generated by Richard Schroeppel at the
   University of Arizona. Properties of these groups are described in
   [Orm96].

6.1 First Oakley Default Group

   Oakley implementations MUST support a MODP group with the following
   prime and generator. This group is assigned id 1 (one).

      The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
      Its hexadecimal value is







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


         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

      The generator is: 2.

6.2 Second Oakley Group

   IKE implementations SHOULD support a MODP group with the following