[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                 Y. Dayan
IP Security Working Group                                       S. Bitan
Internet Draft                                                  Radguard
Expires in six months                                       January 2000



                             IKE Base Mode
                <draft-ietf-ipsec-ike-base-mode-02.txt>

Status of this Memo

   This document is a submission to the IETF IP Security Protocol
   (IPSEC) Working Group.  Comments are solicited and should be
   addressed to the working group mailing list (ipsec@lists.tislab.com)
   or to the editor.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes a new Phase I mode for IKE [RFC-2409] based
   on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new
   exchange is to allow support of all authentication methods with fixed
   and non-fixed IP addresses, while offering protection against a
   denial of service attack aimed at costly operations. It also enables
   negotiation capabilities beyond those offered by Aggressive Mode
   (DH/EC group). The exchange consists of only four messages and
   therefor is useful when performance is crucial.





Dayan,Bitan                                                     [Page 1]


Internet Draft               IKE Base Mode                  January 2000


1.  Introduction

   The IKE [RFC-2409] protocol offers two modes in which to execute
   Phase I - Main Mode and Aggressive Mode.  Main Mode offers identity
   protection and the cookie mechanism that provides some protection for
   the exchange. Main Mode with pre-shared key authentication requires
   knowledge of the peer's pre-shared key prior to the knowledge of the
   peers identity. Therefore, Main Mode with pre-shared keys can only be
   used when the IP address of the peer is the identifier of the peer.
   Hence, when using pre-shared keys in an environment where the IP
   address does not identify the peer, Main Mode cannot be used.

   In Aggressive Mode, the identities appear in the first two messages.
   Aggressive Mode is the only mode possible in the above scenario. It
   consists of fewer messages and as a result, the cookies are of little
   use to the responder. The keying material payload appears in the
   first message of Aggressive Mode and therefore an agreement on the
   Diffie-Hellman group id cannot take place.

   In both modes, the responder MUST always supply the key exchange
   payload prior to any authentication of the initiating peer. Creation
   of the key exchange payload requires a costly calculation. This
   leaves the responder exposed to denial of service attacks. Although
   implementation notes have addressed this to some extent, this can
   still be seen as a security risk.

   This document describes a new Phase I mode that is based on the
   ISAKMP Base Exchange. Its purpose is to offer an alternative exchange
   that eliminates the above mentioned issues. The initiator's
   authentication data is sent along with the key exchange payload,
   allowing the responder to verify the identity before replying with a
   KE payload. This mode allows the shared secret calculation to be
   postponed untill after the exchange is complete. It provides a short
   exchange with negotiation capabilities for the Diffie-Hellman (or EC)
   group id and security benefits that are discussed in details in
   section 4. In an environment with pre-shared keys and addresses which
   do not identify the initiator, this is the only alternative to
   Aggressive Mode.

   The reader is assumed to be familiar with most of the terms and
   concepts described in the ISAKMP  [RFC-2408] and IKE [RFC-2409]
   documents.


2. Specification of Requirements

   This document shall use the keywords "MUST", "MUST NOT",
   "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",



Dayan,Bitan                                                     [Page 2]


Internet Draft               IKE Base Mode                  January 2000


   "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They
   are to be interpreted as described in [RFC-2119] document.


3. The Base Mode Exchange

   Base Mode is an instantiation of the ISAKMP Base Exchange with the
   minor change of the identity payload location. The first two messages
   negotiate policy, exchange ancillary data necessary for the exchange,
   and identities. The third and fourth messages exchange Diffie-Hellman
   public values and authenticate the peers.
   The XCHG for Base Mode is ISAKMP Base.
   The final messages are not sent under protection of the ISAKMP SA,
   and HASH_I and HASH_R have been changed to allow each party to
   postpone exponentiation, if desired, until negotiation of this
   exchange is complete. The shared secret will only be required in the
   following exchange.
   Unlike Aggressive Mode, Security Association negotiation is not
   limited and the responder provides a Diffie-Hellman public value only
   after the initiator authenticates itself.
   The value HASH_I needs to be redefined because the initiator must
   calculate it before receiving the Diffie-Hellman public value of the
   responder. HASH_I is calculated separately for the different
   authentication methods.

   For signatures:
   HASH_I = prf(hash(Ni_b | Nr_b), g^xi | CKY-I | CKY-R | SAi_b |
   IDii_b|IDir_b)
   For public key encryption and pre-shared keys:
   HASH_I = prf(SKEYID, g^xi | CKY-I | CKY-R | SAi_b | IDii_b)


   To enable postponing of the calculation of g^xy with the signature
   authentication method, we redefine HASH_R for signatures and leave it
   unchanged for all other authentication methods.  For signatures:
   HASH_R = prf(hash(Ni_b | Nr_b), g^xr | g^xi | CKY-R | CKY-I | SAi_b |
   IDir_b | IDii_b)



3.1. Base Mode Authenticated with Signatures

   Signing a mutually obtained hash authenticates this exchange. This
   signatures provide a proof of participation in the exchange.







Dayan,Bitan                                                     [Page 3]


Internet Draft               IKE Base Mode                  January 2000


   Initiator                       Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, [CERT,] SIG_I  =>
                           <= HDR, KE, [CERT,] SIG_R



   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.
   The hash function to be used with the signature is as defined in IKE,
   as is the signature encoding. One or more certificate payloads MAY be
   optionally passed. If necessary, a certificate request payload can be
   passed in any of the first three messages.



3.2. Base Mode Authenticated with Public Key Encryption

   Using public key encryption, the peer authenticates by being able to
   decrypt the encrypted nonce, and produce the correct HASH_I/HASH_R.
   The verification process in itself requires a public key operation.
   The advantage is that the identities are protected. There is an
   underlying assumption that the initiator has the responder's public
   key from the beginning of the exchange.

   Initiator                        Responder

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

   All details concerning HASH(1) and the encryption are the same as in
   Main and Aggressive Mode.

   There is no proof that the exchange ever took place since each party
   can completely reconstruct both sides of the exchange. The responder
   MUST perform four public key operations and these operations take
   place before it can verify the initiator's identity.







Dayan,Bitan                                                     [Page 4]


Internet Draft               IKE Base Mode                  January 2000


3.3. Base Mode Authenticated with Revised Public Key Encryption

   This method is much like the previous one. Its two main advantages
   are that there are only two public key operations and that extra
   protection is added by encrypting the keying material payload.

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <Ni_b>Pubkey_r,
   <IDii_b>Ke_i            =>
                              HDR, SA, <Nr_b>PubKey_i,
                           <= <IDir_b>Ke_r
   HDR, <KE>Ke_i, HASH_I   =>
                           <= HDR, <KE>_Ke_r, HASH_R


   All details concerning HASH(1) the public key operation details and
   Ke_i/r, are the same as in Main and Aggressive Mode. In this method
   the responder has to perform two public key operations prior to
   verifying the initiator's identity.



3.4. Base Mode Authenticated with Pre-Shared Keys

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


   Initiator                       Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, HASH_I         =>
                           <= HDR, KE, HASH_R

   The responder has no costly operations to perform prior to
   verification of the initiator's identity. The identity payload can be
   used as a pre-shared key identifier. This enables two parties to use
   more than one key for authentication. This exchange does not provide
   proof that it ever took place since both peers have knowledge of the
   pre-shared key(s).


4. Security Considerations

   Base Mode with public key signatures or pre-shared keys SHOULD NOT be



Dayan,Bitan                                                     [Page 5]


Internet Draft               IKE Base Mode                  January 2000


   used when identity protection is required. An exception might be when
   the ID payload is used as a key identifier, and the identity is not
   explicitly transmitted.  In all authentication methods there is no
   need to calculate g^xy prior to verification of the peer's identity,
   authentication and completion of the exchange.

   In all authentication methods, the responder's Diffie-Hellman public
   value is used only after verification. This feature is not offered by
   Aggressive Mode and Main mode offers it, only to an extent, by the
   cookie mechanism. Therefore, for pre-shared key authentication, when
   the IP address is not an identifier, this exchange is the only one
   that offers some protection from denial of service attacks.

   The signatures, in Base Mode with signatures, are over data that was
   sent in the exchange in the clear. This makes the public key pair
   more vulnerable to known plaintext attacks.


   Note that although Base Mode offers more protection from DoS in terms
   of costly computations, the responder still needs to create a state
   after receiving the first message.

5. Acknowledgements

   We would like to thank Hugo Krawczyk for pointing out and fixing the
   vulnerability to the "STS attack" in signature mode.

6. References

   [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J.,
   "Internet Security Association and Key Management Protocol (ISAKMP)",
   November 1998.

   [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
   November 1998

   [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
   Requirement Levels", March 1997

7. Authors' Addresses
   Yael Dayan <yael@radguard.com>
   Sara Bitan <sarab@radguard.com>
   Radguard Ltd.
   Atidim Technology Park, Building 4
   Tel Aviv 61561
   Israel
   Phone: +972-3-765-7983




Dayan,Bitan                                                     [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/