idnits 2.17.1 draft-ietf-ipsec-improveike-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-kaufman-ipsec-improveike-00', but the file name used is 'draft-ietf-ipsec-improveike-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 9, 2001) is 8317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IKE' is defined on line 237, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'PK00' -- Possible downref: Non-RFC (?) normative reference: ref. 'PK01' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Charlie Kaufman 3 IP Security Working Group Iris Associates 4 Internet Draft Radia Perlman 5 Sun Microsystems 6 Andrew Krywaniuk 7 Alcatel 8 July 9, 2001 10 Code-preserving Simplifications and 11 Improvements to IKE 12 14 Status of this Memo 16 This document is a submission to the IETF Internet Protocol Security 17 (IPsec) Working Group. Comments are solicited and should be addressed 18 to the working group mailing list (ipsec@lists.tislabs.com) or to the 19 editor. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or made obsolete by other documents at 30 any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 This document is a product of the IETF's IPsec Working Group. 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 Abstract 46 This internet draft recommends modifications to Phase 1 IKE that will 47 minimize code changes. We recommend simplification by removing some 48 of the options, and minimal changes, when they provide a large 49 increase in functionality, in the remaining portions of IKE. 51 Table of Contents 53 1. Introduction.................................................4 54 2. Specification of Requirements................................4 55 3. Get Rid of Aggressive Mode...................................4 56 4. Remove Public Key Encryption Variants........................4 57 5. Allow stateless operation....................................4 58 6. Change Parameter Negotiation to Allow Choices................5 59 7. Fix Main-Mode with Preshared Keys............................5 60 8. Invert Identity Protection...................................6 61 9. Additional Functionality.....................................6 62 9.1 Unidirectional Authentication................................6 63 9.2 Weak Preshared Secret Authentication.........................7 64 10. IANA Considerations..........................................7 65 11. Security Considerations......................................7 66 12. References...................................................7 68 1. Introduction 70 IKE has received criticism for being too complex. Rather than 71 starting over, we recommend changes to IKE that are as code 72 preserving as possible. For more analysis of these recommended 73 changes see [PK01] or [PK00]. The reader is assumed to have some 74 knowledge of IKE. Each section is a separate recommendation for 75 something that significantly simplifies IKE, fixes bugs, or adds 76 significant functionality. 78 2. Specification of Requirements 80 This document makes recommendations rather than specifying 81 requirements. 83 3. Get Rid of Aggressive Mode 85 If identity hiding is considered important, then use it all the time. 86 If smaller numbers of messages are important, then always use 87 aggressive mode. Users are unlikely to understand the choices in 88 order to decide which mode to use. The optimization of sometimes 89 being able to use fewer messages, in ill-defined cases, seems not 90 worth the complexity of doubling the number of permutations that need 91 to be designed and implemented. 93 4. Remove Public Key Encryption Variants 95 Signature-only public keys are useful because they are less likely to 96 be escrowed, it is unlikely that someone would have an encryption key 97 but not a signature key, and each side knows its own signature key. 98 IKE protocols using public encryption keys do not have significant 99 advantages over public signature key SA establishment. 101 Furthermore, the public encryption key variants are operationally 102 awkward because they require the initiator to already know the 103 responder's public key. Rather than fixing this flaw, which would 104 require significant redesign of the protocols, it seems better to 105 merely remove the public encryption variants. 107 5. Allow stateless operation 109 The idea of stateless cookies, as envisioned by Photuris, was that 110 Bob need not keep state until he is assured that the initiator can 111 receive from the IP address she claims to be coming from. IKE does 112 not allow Bob to be stateless, since he has to remember the 113 information (such as the crypto suites that Alice offers) from 114 message 1 in order to validate Alice's signature in message 5. If 115 Alice repeats all the information from message 1 in message 3, Bob 116 can be stateless until message 3. 118 6. Change Parameter Negotiation to Allow Choices 120 Sometimes several cryptographic algorithms work together. But IKE 121 currently requires every combination to be specified. There are four 122 types of crypto algorithms for each suggested suite (encryption 123 algorithm, hash algorithm, authentication algorithm, and Diffie- 124 Hellman group). 126 If in many cases several of them can be used interchangeably, this 127 causes an exponential explosion to specify all supported 128 combinations. Instead we suggest a set of proposals, where there is 129 allowed to be a choice of algorithms within a proposal. For instance: 131 proposal 1: ({Enc-A, Enc-B}, MD5, {RSA public signature keys, RSA 132 public keys with new protocol}, {DH group 1, DH group 2, DH group 3}) 134 proposal 2: ({Enc-C, Enc-D, Enc-E}, SHA, preshared keys, {DH group 1, 135 DH group 4}) 137 7. Fix Main-Mode with Preshared Keys 139 In IKE as currently specified, Alice sends her identity to Bob in a 140 key encrypted with a key which is a function of the pre-shared key. 141 So Bob can't decrypt the message to discover Alice's identity, unless 142 he knows Alice's identity. IKE's solution is to require Alice's 143 identity to be her IP address. 145 But then there's no reason to use the extra messages to do identity 146 hiding. Worse yet, it's useless in the "road warrior" case where 147 someone might configure a shared secret between their laptop and the 148 firewall, and attempt to connect from unpredictable locations on the 149 Internet, since their IP address will change. 151 The solution is to change the key used to encrypt Alice's identity to 152 be only a function of the Diffie-Hellman key. The protocol already 153 assures that Alice proves knowledge of the preshared key because she 154 transmits something to Bob that is a hash of information including 155 that key. This minimal change (changing the encryption key used for 156 encrypting messages 5 and 6 to not be a function of the shared key) 157 allows use of arbitrary identifiers and makes this mode work for the 158 road warrior case. 160 8. Invert Identity Protection 162 In the case of main mode with public key signatures, Bob's identity 163 is hidden even from an active attacker, but Alice's identity is 164 exposed to an active attacker impersonating Bob's address to Alice. 166 We argue that it is preferable to hide Alice's identity rather than 167 Bob's. The protocol could be modified to hide Alice's identity 168 instead of Bob's from an active attacker. This would be done by 169 moving the information from msg 6 into msg 4. This even completes the 170 protocol in one fewer message. 172 9. Additional Functionality 174 The previous sections are either suggested simplifications or fixing 175 problems. This section suggests two possible enhancements. 177 9.1 Unidirectional Authentication 179 In some cases only one side has a cryptographic identity. For 180 example, a common use case for SSL is where the server has a 181 certificate and the user does not. In this case SSL creates an 182 encrypted tunnel. The client side knows it is talking to the server, 183 but the server does not know to whom it is talking. If the server 184 needs to authenticate the user, the application typically asks for a 185 name and password. 187 The one-way authentication is vital in this case because the user has 188 to know he is sending his password to the correct server, and the 189 protocol also ensures that the password will be encrypted when 190 transmitted. In some cases security is useful even if it is only one- 191 way. For instance, a server might be disseminating public 192 information, and the client would like to know that it is receiving 193 this information from a reliable source, but the server does not need 194 to authenticate the client. 196 Since this is a useful case in SSL, it would be desirable to allow 197 for unidirectional authentication within IPSec. None of the IKE 198 protocols allow this. 200 9.2 Weak Preshared Secret Authentication 202 The IKE protocol for pre-shared secrets depends on the secret being 203 cryptographically strong. If the secret were weak, say because it was 204 a function of a password, an active attacker (someone impersonating 205 one side to the other) could obtain information with which to do an 206 off-line dictionary attack. Our suggested improvement to the protocol 207 still requires a strong pre-shared secret. 209 There is a family of protocols in which a weak secret, such as one 210 derived from a password, can be used in a cryptographic exchange in a 211 way that is invulnerable to dictionary attack, either by an 212 eavesdropper or someone impersonating either side. The original such 213 protocol, EKE, worked by encrypting a Diffie-Hellman exchange with a 214 hash of the weak secret, and then authenticating based on the strong 215 secret created by the Diffie-Hellman exchange. 217 The ability to use a weak secret such as a password in a secure way 218 is very powerful, in the case where it is a user being authenticated. 219 The current IKE pre-shared secret protocol could be replaced with one 220 of these protocols at no loss in security or performance. If an IKE 221 weak secret variant were designed, then the strong secret variant 222 should be dropped, since certainly a protocol that works with a weak 223 secret will work with a strong secret. 225 10. IANA Considerations 227 This document does not require any assigned numbers. 229 11. Security Considerations 231 The suggested changes simplify IKE considerably, at no loss in 232 security. Some changes, such as allowing stateless operation, enhance 233 the security of IKE. 235 12. References 237 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 238 RFC 2409, November 1998 240 [PK00] Perlman, R., Kaufman, C., "Key Exchange in IPSec: Analysis of 241 IKE", IEEE Internet Computing Journal special issue on 242 Security Solutions, Nov/Dec 2000. 244 [PK01] Perlman, R., Kaufman, C., "Analysis of the IPSec Key Exchange 245 Standard", WET-ICE security conference, MIT, 246 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf, 247 2001. 249 Authors' Addresses 251 Charlie Kaufman 252 Iris Associates 253 E-mail: ckaufman@iris.com 255 Radia Perlman 256 Sun Microsystems 257 E-mail: radia.perlman@sun.com 259 Andrew Krywaniuk 260 Alcatel Networks Corporation 261 600 March Road 262 Kanata, ON 263 Canada, K2K 2E6 264 +1 (613) 784-4237 265 E-mail: andrew.krywaniuk@alcatel.com 267 The IPsec working group can be contacted via the IPsec working 268 group's mailing list (ipsec@lists.tislabs.com) or through its chairs: 270 Theodore Y. Ts'o 271 tytso@MIT.EDU 272 Massachusetts Institute of Technology 274 Barbara Fraser 275 byfraser@cisco.com 276 Cisco Systems 278 Expiration 280 This document expires February 9th, 2002.