idnits 2.17.1 draft-ietf-ipsec-antireplay-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-krywaniuk-ipsec-antireplay-00', but the file name used is 'draft-ietf-ipsec-antireplay-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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 8298 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 232, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- No information found for draft-krywaniuk-ipsec-properties - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PROP' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Andrew Krywaniuk 3 IP Security Working Group Alcatel 4 Internet Draft July 9, 2001 6 Using Isakmp Message Ids for Replay Protection 7 9 Status of this Memo 11 This document is a submission to the IETF Internet Protocol Security 12 (IPsec) Working Group. Comments are solicited and should be addressed 13 to the working group mailing list (ipsec@lists.tislabs.com) or to the 14 editor. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or made obsolete by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 This document is a product of the IETF's IPsec Working Group. 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document describes a method for adding explicit replay 42 protection to IKE messages by altering the use of the message id in 43 the ISAKMP header. 45 We suggest that this change could be applied as part of the next 46 revision of IKE. 48 Table of Contents 50 1. Introduction...................................................4 51 2. Specification of Requirements..................................4 52 3. Outline of the Problem.........................................4 53 4. Discussion of Proposed Solutions...............................5 54 5. Description of the new behaviour...............................6 55 6. Cryptographic Impact...........................................7 56 7. IANA Considerations............................................7 57 8. Security Considerations........................................7 58 9. References.....................................................7 60 1. Introduction 62 IKE has a number of small weaknesses that should be fixed in the next 63 version. Many of these weaknesses can be avoided through careful 64 software design, but they still exist as pitfalls for the unwary 65 implementer. An unfortunate side effect of these small weaknesses is 66 that different implementers have chosen to solve them in different 67 ways. 69 For example, the Initial Contact notification is not authenticated by 70 the phase 1 hash. Thus, some implementations will only send it in 71 encrypted phase 1 messages; others may always send it attached to a 72 quick mode or in a separate informational exchange. 74 Fortunately, many of these weaknesses are quite easy to fix. For 75 example, the problem of unauthenticated payloads is fixed simply by 76 redefining the phase 1 hash. In this memo, we discuss another 77 weakness of IKE which can be fixed with a fairly simple fix: the 78 problem of replay protection. 80 2. Specification of Requirements 82 This document shall use the keywords "MUST", "MUST NOT", 83 "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 84 "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They 85 are to be interpreted as described in [Bradner]. 87 3. Outline of the Problem 89 The ISAKMP message format does not provide explicit protection 90 against replay attacks. This does not necessarily mean that IKE is 91 vulnerable to replay attacks, but it does complicate the overall 92 protocol design because implementers must be vigilant in ensuring 93 that each individual IKE exchange is replay-resistant. 95 As described in [PROP], it takes a minimum of 3 messages before an 96 IKE exchange can be secured against replay. This is precisely the 97 reason why quick mode is 3 messages long when 2 messages would 98 otherwise appear to suffice. 100 An implementation that performs any time-consuming or memory- 101 consuming operation before the 3rd message has been exchanged does so 102 at its own risk. This caveat can often conflict with operational 103 needs, such as the desire for optimization. 105 For example, if PFS is used in quick mode, the responder may be 106 tempted to precompute the Diffie-Hellman secret before the exchange 107 is complete in order to set up the SA as quickly as possible. This 108 would introduce a security hole, because it allows an attacker to 109 replay the first packet of quick mode, causing DoS. 111 Replay of quick mode packets can be detected because the attacker 112 will be unable to forge the 3rd packet of the exchange. Replayed info 113 mode packets cannot be detected in this way because they are not part 114 of a 3-message exchange. However, replayed info modes will have 115 different potential weaknesses depending on the content of the 116 message. A replayed delete notification is unlikely to cause any harm 117 because the SA will have already been deleted. 119 On the other hand, if an implementation tried to avoid the 120 aforementioned phase 1 hash weakness by putting the Initial Contact 121 notification in a separate info mode message, an attacker could 122 capture this packet and replay it later, possibly causing the peer to 123 delete all his SAs. 125 The replay vulnerability also applies to proposed extensions to IKE. 126 For example, two separate proposals for adding a heartbeat protocol 127 to IKE each had to devote a section of the protocol design to 128 thwarting replay attacks. 130 4. Discussion of Proposed Solutions 132 There is a minor related problem, which is that the 32-bit number 133 space for message ids is not adequately collision resistant. It is 134 possible, although fairly unlikely, that two peers may simultaneously 135 initiate new exchanges using the same message id. If the messages 136 crossed on the wire, each side would interpret the newly received 137 message as a reply to the packet that it just sent. 139 Two categories of solutions have been proposed to fix these problems: 141 1. Turn the message id into an anti-replay counter. 143 2. Store all message ids that have been sent or received. 145 We believe that option 1 is a simpler and more elegant solution for 146 several reasons. Most notably, it preserves the property already 147 present in IKE that an IKE SA has a fixed memory footprint which does 148 not increase over time. 150 This property is of theoretical importance because it guarantees that 151 a properly designed implementation cannot be forced into an unstable 152 state under low memory conditions. In most applications, the memory 153 requirement for storing all these message ids is quite small. 154 However, some implementations may consume message ids more quickly 155 than this (for example, a host which negotiates multiple selector- 156 bound SAs or which sends frequent keep-alive packets). 158 Under option 2, an implementation may be forced to rekey its phase 1 159 SAs simply to free up some memory. The worse the memory problem gets, 160 the more frequently the host will need to rekey. This could cause an 161 implementation to enter an unstable (looping) state. 163 Solution 1 also prevents a message from being intercepted, stored, 164 and then sent at a later time. Why risk this potential vulnerability 165 when a simple, more elegant solution exists? 167 5. Description of the new behaviour 169 Instead of choosing a pseudorandom message id, the message id can be 170 converted into a counter. As in all counter-based anti-replay 171 schemes, each side should keep a record of the last message id it 172 received from the peer. (Obviously, this field should only be updated 173 after the packet has been authenticated) 175 The initiator (of the phase 1) uses 1 as his first message id, and he 176 increments this value by 1 on each subsequent exchange. The responder 177 (from the phase 1) does the same, but he always sets the high bit of 178 his message id to 1. This ensures that the initiator and responder 179 can never generate the same value. 181 Just as for the replay counters in [ARCH], an implementation should 182 keep a sliding window of which replay counters are acceptable. This 183 takes into account the possibility that some packets will be received 184 out of order. 186 We suggest that these packet-processing rules be incorporated into 187 the next version of IKE. They may also be enabled in the short term 188 by mutual exchange of the vendor id 0x325df29a2319f2dd. 190 This vendor id SHOULD NOT be used unless the two peers can 191 authenticate that the behaviour was agreed on (e.g. by the use of the 192 revised hash), due to the DoS attack that could occur if an attacker 193 caused only one peer to think that the new behaviour was being used. 195 6. Cryptographic Impact 197 This draft redefines the use of the message id field. The message id 198 is used as an input to a hash function in order to generate the 199 initial IV for an exchange. This IV is completely based on publicly 200 visible material and can be generated by a passive snooper. 202 The only consequence of this change is that subsequent inputs to the 203 hash will all have very low Hamming distance. Assuming that a good 204 hash function is used, this shouldn't affect the apparent randomness 205 of the IV. 207 If a preponderance of cryptographers believed that this reduction of 208 entropy was unacceptable, then the IV derivation could be changed in 209 order to increase the entropy in the input to the PRF. 211 7. IANA Considerations 213 This document does not require any assigned numbers. 215 8. Security Considerations 217 The focus of this document is security; hence security considerations 218 permeate this specification. 220 9. References 222 [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the 223 Internet Protocol", RFC 2401, November 1998. 225 [Bradner] Bradner, S., "Key Words for use in RFCs to indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and J. Turner, 229 "Internet Security Association and Key Management Protocol 230 (ISAKMP)", RFC 2408, November 1998. 232 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 233 RFC 2409, November 1998 235 [PROP] Krywaniuk, A., "Security Properties of the IPsec Protocol 236 Suite", draft-krywaniuk-ipsec-properties-00.txt, July 9, 2001 237 (work in progress) 239 Authors' Addresses 241 Andrew Krywaniuk 242 Alcatel Networks Corporation 243 600 March Road 244 Kanata, ON 245 Canada, K2K 2E6 246 +1 (613) 784-4237 247 E-mail: andrew.krywaniuk@alcatel.com 249 The IPsec working group can be contacted via the IPsec working 250 group's mailing list (ipsec@lists.tislabs.com) or through its chairs: 252 Theodore Y. Ts'o 253 tytso@MIT.EDU 254 Massachusetts Institute of Technology 256 Barbara Fraser 257 byfraser@cisco.com 258 Cisco Systems 260 Expiration 262 This document expires February 9th, 2002.