rfc2409.txt

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

   associated with the signature method.  The negotiated prf and hash
   function would continue to be used for all other prescribed pseudo-
   random functions.

   Since the hash algorithm used is already known there is no need to
   encode its OID into the signature. In addition, there is no binding
   between the OIDs used for RSA signatures in PKCS #1 and those used in
   this document. Therefore, RSA signatures MUST be encoded as a private
   key encryption in PKCS #1 format and not as a signature in PKCS #1
   format (which includes the OID of the hash algorithm). DSS signatures
   MUST be encoded as r followed by s.

   One or more certificate payloads MAY be optionally passed.








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


5.2 Phase 1 Authenticated With Public Key Encryption

   Using public key encryption to authenticate the exchange, the
   ancillary information exchanged is encrypted nonces. Each party's
   ability to reconstruct a hash (proving that the other party decrypted
   the nonce) authenticates the exchange.

   In order to perform the public key encryption, the initiator must
   already have the responder's public key. In the case where the
   responder has multiple public keys, a hash of the certificate the
   initiator is using to encrypt the ancillary information is passed as
   part of the third message. In this way the responder can determine
   which corresponding private key to use to decrypt the encrypted
   payloads and identity protection is retained.

   In addition to the nonce, the identities of the parties (IDii and
   IDir) are also encrypted with the other party's public key. If the
   authentication method is public key encryption, the nonce and
   identity payloads MUST be encrypted with the public key of the other
   party. Only the body of the payloads are encrypted, the payload
   headers are left in the clear.

   When using encryption for authentication, Main Mode is defined as
   follows.

        Initiator                        Responder
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, KE, [ HASH(1), ]
          <IDii_b>PubKey_r,
            <Ni_b>PubKey_r        -->
                                         HDR, KE, <IDir_b>PubKey_i,
                                  <--            <Nr_b>PubKey_i
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R

   Aggressive Mode authenticated with encryption is described as
   follows:

        Initiator                        Responder
       -----------                      -----------
        HDR, SA, [ HASH(1),] KE,
          <IDii_b>Pubkey_r,
           <Ni_b>Pubkey_r         -->
                                         HDR, SA, KE, <IDir_b>PubKey_i,
                                  <--         <Nr_b>PubKey_i, HASH_R
        HDR, HASH_I               -->



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


   Where HASH(1) is a hash (using the negotiated hash function) of the
   certificate which the initiator is using to encrypt the nonce and
   identity.

   RSA encryption MUST be encoded in PKCS #1 format. While only the body
   of the ID and nonce payloads is encrypted, the encrypted data must be
   preceded by a valid ISAKMP generic header. The payload length is the
   length of the entire encrypted payload plus header. The PKCS #1
   encoding allows for determination of the actual length of the
   cleartext payload upon decryption.

   Using encryption for authentication provides for a plausably deniable
   exchange. There is no proof (as with a digital signature) that the
   conversation ever took place since each party can completely
   reconstruct both sides of the exchange. In addition, security is
   added to secret generation since an attacker would have to
   successfully break not only the Diffie-Hellman exchange but also both
   RSA encryptions. This exchange was motivated by [SKEME].

   Note that, unlike other authentication methods, authentication with
   public key encryption allows for identity protection with Aggressive
   Mode.

5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption

   Authentication with Public Key Encryption has significant advantages
   over authentication with signatures (see section 5.2 above).
   Unfortunately, this is at the cost of 4 public key operations-- two
   public key encryptions and two private key decryptions. This
   authentication mode retains the advantages of authentication using
   public key encryption but does so with half the public key
   operations.

   In this mode, the nonce is still encrypted using the public key of
   the peer, however the peer's identity (and the certificate if it is
   sent) is encrypted using the negotiated symmetric encryption
   algorithm (from the SA payload) with a key derived from the nonce.
   This solution adds minimal complexity and state yet saves two costly
   public key operations on each side. In addition, the Key Exchange
   payload is also encrypted using the same derived key. This provides
   additional protection against cryptanalysis of the Diffie-Hellman
   exchange.

   As with the public key encryption method of authentication (section
   5.2), a HASH payload may be sent to identify a certificate if the
   responder has multiple certificates which contain useable public keys
   (e.g. if the certificate is not for signatures only, either due to
   certificate restrictions or algorithmic restrictions). If the HASH



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


   payload is sent it MUST be the first payload of the second message
   exchange and MUST be followed by the encrypted nonce. If the HASH
   payload is not sent, the first payload of the second message exchange
   MUST be the encrypted nonce. In addition, the initiator my optionally
   send a certificate payload to provide the responder with a public key
   with which to respond.

   When using the revised encryption mode for authentication, Main Mode
   is defined as follows.

        Initiator                        Responder
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, [ HASH(1), ]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i,
          <IDii_b>Ke_i,
          [<<Cert-I_b>Ke_i]       -->
                                         HDR, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r,
                                  <--         <IDir_b>Ke_r,
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R

   Aggressive Mode authenticated with the revised encryption method is
   described as follows:

        Initiator                        Responder
       -----------                      -----------
        HDR, SA, [ HASH(1),]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i, <IDii_b>Ke_i
          [, <Cert-I_b>Ke_i ]     -->
                                         HDR, SA, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r, <IDir_b>Ke_r,
                                  <--         HASH_R
        HDR, HASH_I               -->

   where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to
   the symmetric encryption algorithm negotiated in the SA payload
   exchange. Only the body of the payloads are encrypted (in both public
   key and symmetric operations), the generic payload headers are left
   in the clear. The payload length includes that added to perform
   encryption.

   The symmetric cipher keys are derived from the decrypted nonces as
   follows.  First the values Ne_i and Ne_r are computed:



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


      Ne_i = prf(Ni_b, CKY-I)
      Ne_r = prf(Nr_b, CKY-R)

   The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively
   in the manner described in Appendix B used to derive symmetric keys
   for use with the negotiated encryption algorithm. If the length of
   the output of the negotiated prf is greater than or equal to the key
   length requirements of the cipher, Ke_i and Ke_r are derived from the
   most significant bits of Ne_i and Ne_r respectively. If the desired
   length of Ke_i and Ke_r exceed the length of the output of the prf
   the necessary number of bits is obtained by repeatedly feeding the
   results of the prf back into itself and concatenating the result
   until the necessary number has been achieved. For example, if the
   negotiated encryption algorithm requires 320 bits of key and the
   output of the prf is only 128 bits, Ke_i is the most significant 320
   bits of K, where

      K = K1 | K2 | K3 and
      K1 = prf(Ne_i, 0)
      K2 = prf(Ne_i, K1)
      K3 = prf(Ne_i, K2)

   For brevity, only derivation of Ke_i is shown; Ke_r is identical. The
   length of the value 0 in the computation of K1 is a single octet.
   Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be
   discarded after use.

   Save the requirements on the location of the optional HASH payload
   and the mandatory nonce payload there are no further payload
   requirements. All payloads-- in whatever order-- following the
   encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the
   direction.

   If CBC mode is used for the symmetric encryption then the
   initialization vectors (IVs) are set as follows. The IV for
   encrypting the first payload following the nonce is set to 0 (zero).
   The IV for subsequent payloads encrypted with the ephemeral symmetric
   cipher key, Ke_i, is the last ciphertext block of the previous
   payload. Encrypted payloads are padded up to the nearest block size.
   All padding bytes, except for the last one, contain 0x00. The last
   byte of the padding contains the number of the padding bytes used,
   excluding the last one. Note that this means there will always be
   padding.








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


5.4 Phase 1 Authenticated With a Pre-Shared Key

   A key derived by some out-of-band mechanism may also be used to
   authenticate the exchange. The actual establishment of this key is
   out of the scope of this document.

   When doing a pre-shared key authentication, Main Mode is defined as
   follows:

              Initiator                        Responder
             ----------                       -----------
              HDR, SA             -->
                                  <--    HDR, SA
              HDR, KE, Ni         -->
                                  <--    HDR, KE, Nr
              HDR*, IDii, HASH_I  -->
                                  <--    HDR*, IDir, HASH_R

   Aggressive mode with a pre-shared key is described as follows:

            Initiator                        Responder
           -----------                      -----------
            HDR, SA, KE, Ni, IDii -->
                                  <--    HDR, SA, KE, Nr, IDir, HASH_R
            HDR, HASH_I           -->

   When using pre-shared key authentication with Main Mode the key can
   only be identified by the IP address of the peers since HASH_I must
   be computed before the initiator has processed IDir. Aggressive Mode
   allows for a wider range of identifiers of the pre-shared secret to
   be used. In addition, Aggressive Mode allows two parties to maintain
   multiple, different pre-shared keys and identify the correct one for
   a particular exchange.

5.5 Phase 2 - Quick Mode

   Quick Mode is not a complete exchange itself (in that it is bound to
   a phase 1 exchange), but is used as part of the SA negotiation
   process (phase 2) to derive keying material and negotiate shared
   policy for non-ISAKMP SAs. The information exchanged along with Quick
   Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except
   the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST
   immediately follow the ISAKMP header and a SA payload MUST
   immediately follow the HASH. This HASH authenticates the message and
   also provides liveliness proofs.