Internet Engineering Task Force Charlie Kaufman IP Security Working Group Iris Associates Internet Draft Radia Perlman Sun Microsystems Andrew Krywaniuk Alcatel July 9, 2001 Code-preserving Simplifications and Improvements to IKE Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPsec) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 made obsolete 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. Copyright Notice This document is a product of the IETF's IPsec Working Group. Copyright (C) The Internet Society (2001). All Rights Reserved. Kaufman et al Expires February 9, 2002 [Page 1] Internet Draft IKE Improvements July 12, 2001 Abstract This internet draft recommends modifications to Phase 1 IKE that will minimize code changes. We recommend simplification by removing some of the options, and minimal changes, when they provide a large increase in functionality, in the remaining portions of IKE. IPsec Working Group [Page 2] Internet Draft IKE Improvements July 12, 2001 Table of Contents 1. Introduction.................................................4 2. Specification of Requirements................................4 3. Get Rid of Aggressive Mode...................................4 4. Remove Public Key Encryption Variants........................4 5. Allow stateless operation....................................4 6. Change Parameter Negotiation to Allow Choices................5 7. Fix Main-Mode with Preshared Keys............................5 8. Invert Identity Protection...................................6 9. Additional Functionality.....................................6 9.1 Unidirectional Authentication................................6 9.2 Weak Preshared Secret Authentication.........................7 10. IANA Considerations..........................................7 11. Security Considerations......................................7 12. References...................................................7 IPsec Working Group [Page 3] Internet Draft IKE Improvements July 12, 2001 1. Introduction IKE has received criticism for being too complex. Rather than starting over, we recommend changes to IKE that are as code preserving as possible. For more analysis of these recommended changes see [PK01] or [PK00]. The reader is assumed to have some knowledge of IKE. Each section is a separate recommendation for something that significantly simplifies IKE, fixes bugs, or adds significant functionality. 2. Specification of Requirements This document makes recommendations rather than specifying requirements. 3. Get Rid of Aggressive Mode If identity hiding is considered important, then use it all the time. If smaller numbers of messages are important, then always use aggressive mode. Users are unlikely to understand the choices in order to decide which mode to use. The optimization of sometimes being able to use fewer messages, in ill-defined cases, seems not worth the complexity of doubling the number of permutations that need to be designed and implemented. 4. Remove Public Key Encryption Variants Signature-only public keys are useful because they are less likely to be escrowed, it is unlikely that someone would have an encryption key but not a signature key, and each side knows its own signature key. IKE protocols using public encryption keys do not have significant advantages over public signature key SA establishment. Furthermore, the public encryption key variants are operationally awkward because they require the initiator to already know the responder's public key. Rather than fixing this flaw, which would require significant redesign of the protocols, it seems better to merely remove the public encryption variants. 5. Allow stateless operation The idea of stateless cookies, as envisioned by Photuris, was that Bob need not keep state until he is assured that the initiator can IPsec Working Group [Page 4] Internet Draft IKE Improvements July 12, 2001 receive from the IP address she claims to be coming from. IKE does not allow Bob to be stateless, since he has to remember the information (such as the crypto suites that Alice offers) from message 1 in order to validate Alice's signature in message 5. If Alice repeats all the information from message 1 in message 3, Bob can be stateless until message 3. 6. Change Parameter Negotiation to Allow Choices Sometimes several cryptographic algorithms work together. But IKE currently requires every combination to be specified. There are four types of crypto algorithms for each suggested suite (encryption algorithm, hash algorithm, authentication algorithm, and Diffie- Hellman group). If in many cases several of them can be used interchangeably, this causes an exponential explosion to specify all supported combinations. Instead we suggest a set of proposals, where there is allowed to be a choice of algorithms within a proposal. For instance: proposal 1: ({Enc-A, Enc-B}, MD5, {RSA public signature keys, RSA public keys with new protocol}, {DH group 1, DH group 2, DH group 3}) proposal 2: ({Enc-C, Enc-D, Enc-E}, SHA, preshared keys, {DH group 1, DH group 4}) 7. Fix Main-Mode with Preshared Keys In IKE as currently specified, Alice sends her identity to Bob in a key encrypted with a key which is a function of the pre-shared key. So Bob can't decrypt the message to discover Alice's identity, unless he knows Alice's identity. IKE's solution is to require Alice's identity to be her IP address. But then there's no reason to use the extra messages to do identity hiding. Worse yet, it's useless in the "road warrior" case where someone might configure a shared secret between their laptop and the firewall, and attempt to connect from unpredictable locations on the Internet, since their IP address will change. The solution is to change the key used to encrypt Alice's identity to be only a function of the Diffie-Hellman key. The protocol already assures that Alice proves knowledge of the preshared key because she transmits something to Bob that is a hash of information including that key. This minimal change (changing the encryption key used for encrypting messages 5 and 6 to not be a function of the shared key) IPsec Working Group [Page 5] Internet Draft IKE Improvements July 12, 2001 allows use of arbitrary identifiers and makes this mode work for the road warrior case. 8. Invert Identity Protection In the case of main mode with public key signatures, Bob's identity is hidden even from an active attacker, but Alice's identity is exposed to an active attacker impersonating Bob's address to Alice. We argue that it is preferable to hide Alice's identity rather than Bob's. The protocol could be modified to hide Alice's identity instead of Bob's from an active attacker. This would be done by moving the information from msg 6 into msg 4. This even completes the protocol in one fewer message. 9. Additional Functionality The previous sections are either suggested simplifications or fixing problems. This section suggests two possible enhancements. 9.1 Unidirectional Authentication In some cases only one side has a cryptographic identity. For example, a common use case for SSL is where the server has a certificate and the user does not. In this case SSL creates an encrypted tunnel. The client side knows it is talking to the server, but the server does not know to whom it is talking. If the server needs to authenticate the user, the application typically asks for a name and password. The one-way authentication is vital in this case because the user has to know he is sending his password to the correct server, and the protocol also ensures that the password will be encrypted when transmitted. In some cases security is useful even if it is only one- way. For instance, a server might be disseminating public information, and the client would like to know that it is receiving this information from a reliable source, but the server does not need to authenticate the client. Since this is a useful case in SSL, it would be desirable to allow for unidirectional authentication within IPSec. None of the IKE protocols allow this. IPsec Working Group [Page 6] Internet Draft IKE Improvements July 12, 2001 9.2 Weak Preshared Secret Authentication The IKE protocol for pre-shared secrets depends on the secret being cryptographically strong. If the secret were weak, say because it was a function of a password, an active attacker (someone impersonating one side to the other) could obtain information with which to do an off-line dictionary attack. Our suggested improvement to the protocol still requires a strong pre-shared secret. There is a family of protocols in which a weak secret, such as one derived from a password, can be used in a cryptographic exchange in a way that is invulnerable to dictionary attack, either by an eavesdropper or someone impersonating either side. The original such protocol, EKE, worked by encrypting a Diffie-Hellman exchange with a hash of the weak secret, and then authenticating based on the strong secret created by the Diffie-Hellman exchange. The ability to use a weak secret such as a password in a secure way is very powerful, in the case where it is a user being authenticated. The current IKE pre-shared secret protocol could be replaced with one of these protocols at no loss in security or performance. If an IKE weak secret variant were designed, then the strong secret variant should be dropped, since certainly a protocol that works with a weak secret will work with a strong secret. 10. IANA Considerations This document does not require any assigned numbers. 11. Security Considerations The suggested changes simplify IKE considerably, at no loss in security. Some changes, such as allowing stateless operation, enhance the security of IKE. 12. References [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [PK00] Perlman, R., Kaufman, C., "Key Exchange in IPSec: Analysis of IKE", IEEE Internet Computing Journal special issue on Security Solutions, Nov/Dec 2000. [PK01] Perlman, R., Kaufman, C., "Analysis of the IPSec Key Exchange IPsec Working Group [Page 7] Internet Draft IKE Improvements July 12, 2001 Standard", WET-ICE security conference, MIT, http://sec.femto.org/wetice-2001/papers/radia-paper.pdf, 2001. Authors' Addresses Charlie Kaufman Iris Associates E-mail: ckaufman@iris.com Radia Perlman Sun Microsystems E-mail: radia.perlman@sun.com Andrew Krywaniuk Alcatel Networks Corporation 600 March Road Kanata, ON Canada, K2K 2E6 +1 (613) 784-4237 E-mail: andrew.krywaniuk@alcatel.com The IPsec working group can be contacted via the IPsec working group's mailing list (ipsec@lists.tislabs.com) or through its chairs: Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology Barbara Fraser byfraser@cisco.com Cisco Systems Expiration This document expires February 9th, 2002. IPsec Working Group [Page 8]