Internet Engineering Task Force Y. Dayan IP Security Working Group S. Bitan Internet Draft Radguard Expires in six months January 2000 IKE Base Mode 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),] Pubkey_r, Pubkey_r => HDR, SA, PubKey_i, <= 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),] Pubkey_r, Ke_i => HDR, SA, PubKey_i, <= Ke_r HDR, Ke_i, HASH_I => <= HDR, _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 Sara Bitan Radguard Ltd. Atidim Technology Park, Building 4 Tel Aviv 61561 Israel Phone: +972-3-765-7983 Dayan,Bitan [Page 6]