idnits 2.17.1 draft-ietf-ipsec-jfk-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1323 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 28 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '...m bit-string. The Initiator MUST pick...' RFC 2119 keyword, line 204: '...m bit-string. The Responder MUST pick...' RFC 2119 keyword, line 641: '... Such hosts MAY decline any proposed...' RFC 2119 keyword, line 786: '...Nonces Ni and Nr MUST be 8 octets or l...' RFC 2119 keyword, line 856: '... implementations MUST NOT treat them a...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2409' on line 1233 looks like a reference -- Missing reference section? 'RFC2522' on line 1236 looks like a reference -- Missing reference section? 'K01' on line 1222 looks like a reference -- Missing reference section? 'IKEv2' on line 1218 looks like a reference -- Missing reference section? 'RFC2104' on line 1227 looks like a reference -- Missing reference section? 'BDJR97' on line 1203 looks like a reference -- Missing reference section? 'CK01' on line 1211 looks like a reference -- Missing reference section? 'BR93' on line 1207 looks like a reference -- Missing reference section? 'CK02' on line 1215 looks like a reference -- Missing reference section? 'RFC2401' on line 1230 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Aiello 2 Internet Draft S.M. Bellovin 3 draft-ietf-ipsec-jfk-04.txt M. Blaze 4 Expires in 6 months R. Canetti 5 J. Ioannidis 6 A.D. Keromytis 7 O. Reingold 9 Just Fast Keying (JFK) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This draft discusses JFK, a key management protocol. 32 1. Introduction 34 Many public-key-based key setup and key agreement protocols already 35 exist and have been implemented for a variety of applications and 36 environments. Several have been proposed for the IPsec protocol, 37 and one, IKE [RFC2409], is the current standard. IKE has a number 38 of deficiencies, the three most important being that the number of 39 rounds is high, that it is vulnerable to denial-of-service attacks, 40 and the complexity of its specification. (This complexity has led 41 to interoperability problems, so much so that, several years after 42 its initial adoption by the IETF, there are still completely 43 non-interoperating implementations.) 45 While it may be possible to ``patch'' the protocol to fix some of 46 these problems, we would prefer to replace IKE with something 47 better. With that in mind, we set out to engineer a new key 48 exchange protocol specifically for Internet security applications. 49 With a view toward its possible role as a successor to IKE, we call 50 our new protocol ``JFK,'' which stands for ``Just Fast Keying.'' 52 1.1 Design Goals 54 We seek a protocol with the following characteristics (in no 55 particular order): 57 o Security: The resulting key should be cryptographically secure, 58 according to standard measures of cryptographic security for 59 key-exchange. 61 o Simplicity: It must be as simple as possible. 63 o Memory-DoS: It must resist memory exhaustion attacks on the 64 responder. 66 o Computation-DoS: It must resist CPU exhaustion attacks on the 67 responder. 69 o Privacy: It must provide protection for the privacy of the parties. 70 (Different variants are considered within.) 72 o Efficiency: It must be efficient with respect to computation, 73 bandwidth, and number of rounds. 75 o Non-Negotiated: It must avoid complex negotiations over 76 capabilities. 78 o PFS: It must approach perfect forward secrecy. 80 The Security property is obvious enough; the rest, however, require 81 some discussion. 83 The Simplicity property is motivated by several factors. 84 Efficiency is one; increased likelihood of correctness is another. 85 But our motivation is especially colored by our experience with 86 IKE. Even if the protocol is defined correctly, it must be 87 implemented correctly; if a protocol definition is too complex, 88 implementors will get it wrong. This hinders both security and 89 interoperability. 91 Let us highlight two ways in which the simplicity requirement is 92 met by the proposed protocol. First, we avoid the complex two-phase 93 structure of IKE. This buys us a great deal in terms of simplicity, 94 with little to no cost in terms of functionality. (See more details 95 within.) Second, we restrict the protocol to a small and fixed number 96 of rounds: two rounds trips, always, with no optional additional 97 rounds. This results in greater simplicity in implementation, 98 debugging, customization, and operation. 100 The Memory-DoS and Computation-DoS properties have become more 101 important in the context of recent Internet denial-of-service 102 attacks. Photuris [RFC2522] was the first published key management 103 protocol for which DoS-resistance was a design consideration; we 104 suggest that these properties are at least as important today. 105 Photuris first introduced the concept of cookies to counter 106 ``blind'' denial of service attacks. Although the concept of the 107 cookie was adopted by IKE, its use in that protocol did not follow 108 the guidelines established by Photuris and left it open to DoS 109 attacks. 111 The Privacy property means that the protocol does not reveal the 112 identities of the parties to an attacker. There are several variants 113 here: First, the protection can cover the initiator, or the responder 114 or both. Second, the protection can be valid either against active 115 attackers or alternatively only against passive eavesdroppers. We 116 present two protocol variants: One variant provides identity protection 117 for the initiator against active attacks, and no protection for the 118 responder. This variant seems more suitable for a client-server scenario 119 where the initiator (the client) needs full identity protection while 120 the responder (the server) needs no identity protection. The other 121 variant protects the identity of the responder from active attackers, 122 and in addition protects the identity of the initiator from 123 eavesdroppers. This variant seems more suitable for peer-to-peer 124 scenarios where both parties need identity protection but the 125 responder is more vulnerable to active attacks. We leave it to the 126 working group to choose the variant that best suites the needs of 127 IPSEC. (Potentially, one could design a protocol where the parties 128 negotiate whose identity needs to be protected against active 129 attackers. However we believe this would result in an unnecessarily 130 complex protocol.) 132 The Efficiency property is worth discussing. In many protocols, 133 key setup is must be performed frequently enough that it can become 134 a bottleneck to communication. The key exchange protocol must 135 minimize both computation as well total bandwidth and round trips. 136 Round trips can be an especially important factor over unreliable 137 media. 139 The Non-Negotiation property is necessary for several reasons. The 140 first, of course, is as a corollary to Simplicity and Efficiency. 141 Negotiations create complexity and round trips, and hence should be 142 avoided. Denial of service resistance is also relevant here; a 143 partially-negotiated security association is consuming resources. 145 The PFS property is perhaps the most controversial. Rather than 146 assert that ``we must have perfect forward secrecy at all costs'', 147 we treat the amount of forward secrecy as an engineering parameter 148 that can be traded off against other necessary functions, such as 149 resistance to denial-of-service attacks. In fact, this corresponds 150 quite nicely to the reality of today's Internet systems, where a 151 compromise during the existence of a security association will 152 reveal the plaintext of any ongoing transmissions. JFK has the 153 concept of a ``forward secrecy interval''; associations are 154 protected against compromises that occur outside of that interval. 156 Protocol design is, to some extent, an engineering activity, and we 157 need to provide for trade-offs between different types of security. 158 There are trade-offs that we made during the protocol design, and 159 others, such as the trade-off between forward secrecy and 160 computational effort, that are left to the implementation and to 161 the user, e.g., selected as parameters during configuration and 162 session negotiation. 164 We present two protocols (or, rather, two variants of the protocol). 165 The variants, denoted JFKi and JFKr, are very similar in many respects, 166 with two main differences: JFKi provides active identity protection for 167 the initiator and no identity protection for the responder, whereas 168 JFKr provides active identity protection for the responder and passive 169 identity protection for the initiator. In addition, JFKi contains 170 an additional (amortizable) signature. We note that the cryptographic 171 core of JFKr follows that of SIGMA [K01] and IKEv2 [IKEv2]. 173 2. The JFK Protocol 175 2.1 Notation 177 E{K}(M): encryption of M with symmetric key K. 179 HMAC{K}(M): keyed hash of M using key K in an HMAC scheme [RFC2104]. 181 SIG{x}(M): digital signature of M using the private key belonging 182 to principal x (Initiator or Responder). It is not 183 assumed to be a message-recovering signature (but it can 184 be). 186 The message components used in JFK are as follows: 188 g^x: Diffie-Hellman exponentials, also identifying the group-ID. 189 The Diffie-Hellman groups identified in [RFC2409] are used. 191 g^i, g^r: Initiator and Responder exponentials. 193 Ni: Initiator nonce, a random bit-string. The Initiator MUST pick 194 a fresh nonce at each invocation of the JFK protocol. The 195 first few bytes (2 or 4, for IPv4 or IPv6 respectively) of this 196 nonce may contain a cookie used by the Responder to help the 197 Initiator avoid fragmentation-based DoS attacks (see Appendix 198 B). 200 IPi: The Initiator's network identifier (IPv4 or IPv6 address). It 201 is used by the Responder to counter a "cookie-jar" attack, when 202 verifying the authenticator upon receipt of Message 3. 204 Nr: Responder nonce, a random bit-string. The Responder MUST pick 205 a fresh nonce at each invocation of the JFK protocol. The 206 nonces are used in the session key computation, to provide key 207 independence when one or both parties reuse the same 208 Diffie-Hellman exponential; the session key will be different 209 different between independent runs of the protocol, as long as 210 one of the nonces or exponentials changes. The first few bytes 211 (2 or 4, for IPv4 or IPv6 respectively) of this nonce may 212 contain a cookie used by the Initiator to help the Responder 213 avoid fragmentation-based DoS attacks (see Appendix B). 215 sa: Defines the cryptographic and other properties of the Security 216 Association (SA) the Initiator wants to establish. It contains 217 a Domain-of-Interpretation, which JFK understands, and an 218 application-specific bit-string. 220 sa': Any information that the Responder needs to provide to the 221 Initiator with respect to the application SA (e.g., the 222 Responder's SPI, in IPsec). 224 HKr: A transient hash key private to the Responder; this is a 225 global parameter for the Responder (i.e., it is not different 226 for every different protocol run), which changes periodically: 227 the Responder must pick a new g^r every time HKr changes. The 228 use of HKr and the implications of changing it periodically 229 will be explained later in this section. 231 Kir: A shared key derived from g^ir, Ni, and Nr, used as part of 232 the application SA (e.g., IPsec SA). 234 Ke: A shared key derived from g^ir, Ni, and Nr, used to protect the 235 secrecy of messages 3 and 4 of the protocol. Although the 236 input parameters are the same with Kir, a different key 237 derivation mechanism is used to ensure key independence. 239 Ka: A shared key derived from g^ir, Ni, and Nr, used to 240 integrity-protect messages 3 and 4 of the protocol. Although 241 the input parameters are the same with Kir and Ke, a different 242 key derivation mechanism is used to ensure key independence. 244 Ks: A shared key derived from g^ir, Ni, and Nr, used to 245 authenticate subsequent runs of the protocol. Although the 246 input parameters are the same with Kir, Ke, and Ka, a different 247 key derivation mechanism is used to ensure key independence. 249 IDi, IDr: Initiator and Responder certificates, or public-key 250 identifying information, or previous-state identifying 251 information. Multiple such payloads may appear in a 252 message, to indicate multiple certificates, CRLs, etc. 253 For simplicity and clarity, the notation in this draft 254 shows only one such payload per message. 256 IDr': an indication by the Initiator to the Responder as to what 257 identity (and corresponding key material) the latter should use 258 to authenticate to the former. The Responder may ignore this 259 hint. This field may contain the certificate of a CA trusted 260 by the Initiator (which means that the Initiator is requesting 261 that the Responder authenticate with a certificate chain 262 "rooted" at that CA), or the certificate of the Responder 263 (effectively identifying the public, and corresponding private, 264 key of the Responder). 266 GRPINFOr: A list of all Diffie-Hellman groups supported by the 267 Responder, the symmetric algorithm used to protect 268 messages 3 and 4, and the hash function used for key 269 generation. 271 2.2 Protocol JFKr 273 This variant of the JFK protocol provides the same DoS protection 274 and identity protection against passive attackers for both the 275 Initiator and the Responder, but no protection against active 276 identity discovery attacks for the Initiator (the Responder is 277 protected against active identity discovery). 279 Using the same notation as in section 2, the JFKr protocol is: 281 Message 1, I->R: Ni, g^i 283 Message 2, R->I: Ni, Nr, g^r, GRPINFOr, 284 HMAC{HKr}(g^r, Nr, Ni, IPi) 286 Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi), 287 E{Ke}(IDi, IDr' sa, SIG{i}(Ni, Nr, g^i, g^r, GRPINFOr)), 288 HMAC{Ka}('I', E{Ke}(IDi, IDr', sa, SIG{i}(Ni, Nr, g^i, g^r, GRPINFOr))) 290 Message 4, R->I: Ni, Nr, E{Ke}(IDr, sa', SIG{r}(g^r, Nr, g^i, Ni)), 291 HMAC{Ka}('R', E{Ke}(IDr, sa', SIG{r}(g^r, Nr, g^i, Ni))) 293 The keys used to protect Messages (3) and (4), Ke and Ka, are 294 computed as HMAC{g^ir}(Ni, Nr, 1) and HMAC{g^ir}(Ni, Nr, 2) 295 respectively. The session key used by IPsec (or any other 296 application), Kir, is HMAC{g^ir}(Ni, Nr, 0). Key Ks, used for 297 lightweight mode authentication (see Section 3), is computed as 298 HMAC{g^ir}{Ni, Nr, 3}. 300 If more key material is needed, the same mechanism for "key 301 stretching" as specified in [IKEv2] may be used. 303 Message (1) is straightforward; note that it assumes that the 304 Initiator already knows a group and generator that is acceptable to 305 the Responder. The Initiator can reuse a g^i value in multiple 306 instances of the protocol with the Responder or other responders 307 that accept the same group, for as long as she wishes her forward 308 secrecy interval to be. We discuss how the Initiator can discover 309 what groups to use later. 311 In Message (2), the Responder replies with his own exponential (in 312 the same group), information on what secret key algorithms are 313 acceptable for the next message, a random nonce, and an 314 authenticator calculated from a secret, HKr, known to the 315 Responder; the authenticator is computed over the Responder 316 exponential, the two nonces, and the Initiator's network address. 317 The Responder's exponential may also be reused; again, it is 318 regenerated according to the Responder's forward secrecy interval. 319 Finally, note that the Responder does not need to generate any 320 state at this point, and the only ``expensive'' operation is a MAC 321 calculation. 323 Message (3) echoes back the data sent by the Responder, including 324 the authenticator. The authenticator is used by the Responder to 325 verify the authenticity of the returned data. The authenticator 326 also confirms that the sender of Message (3) uses the same address 327 as in Message (1) --- this can be used to detect and counter a 328 ``cookie jar'' DDoS attack. The message also includes the 329 Initiator's identity and service request, and a signature computed 330 over the nonces, the Responder's identity, and the two 331 exponentials. This latter information is all encrypted under a key 332 derived from the Diffie-Hellman computation and the nonces Ni and 333 Nr. The encryption and authentication use algorithms specified in 334 GRPINFOr. The Responder keeps a copy of recently-received Message 335 (3)'s, and their corresponding Message (4). Receiving a duplicate 336 (or replayed) Message (3) causes the Responder to simply retransmit 337 the corresponding Message (4), without creating new state or 338 invoking IPsec (or other application using JFKr as the key 339 establishment protocol). This cache of messages can be reset as 340 soon as HKr is changed. The Responder's exponential (g^r) 341 is re-sent by the Initiator because the Responder may be generating 342 a new g^r for every new JFK protocol run (e.g., if the arrival rate 343 of requests is below some threshold). Note: It is important that 344 the responder deals with repeated Message (3)'s as described above. 345 Responders that create new state for a repeated Message (3) open 346 the door to attacks against the protocol. The message is also 347 protected by an MAC (such as HMAC), using a key derived from the 348 Diffie-Hellman computation and the nonces Ni and Nr. Notice that 349 this key is different form the one used for encrypting the message. 351 Message (4) contains application-specific information (such as the 352 Responder's IPsec SPI), and a signature on both nonces and both 353 exponentials. Everything is encrypted by Ke, which is derived from 354 Ni, Nr, and g^ir (the result of the Diffie-Hellman 355 computation). As in Message (3), this message is also protected by 356 a MAC using key Ka. 358 We remark that the core cryptographic design of JFKr follows that 359 of SIGMA [K01] and IKEv2 [IKEv2]. 361 2.3 Discussion 363 The design follows from our requirements. With respect to 364 communication efficiency, observe that the protocol requires only 365 two round trips. The protocol is optimized to protect the 366 Responder against denial of service attacks on state or 367 computation. The Initiator must establish round-trip communication 368 with the Responder before the latter is required to perform 369 expensive operations. At the same time, the protocol is designed 370 to protect both parties from revealing their identities in the 371 clear. An active attacker can determine the Initiator's identity 372 by performing a man-in-the-middle attack, since the Initiator must 373 authenticate to the Responde first (this is a consequence of the 374 4-message exchange combined with the "liveness" requirement for 375 DDoS prevention). 377 The Initiator's initial message, Message (1), is a straight-forward 378 Diffie-Hellman exponential. Note that this is assumed to be 379 encoded in a self-identifying manner, i.e., it contains a tag 380 indicating which modulus and base was used. The nonce Ni serves two 381 purposes: first, to allow the Initiator to reuse the same 382 exponential across different sessions (with the same or different 383 Responders, within the Initiator's forward secrecy interval) while 384 ensuring that the resulting session key will be 385 different. Secondly, it can be used to differentiate between 386 different parallel sessions. 388 Message (2) must require only minimal work for the Responder, since 389 at that point he has no idea whether the Initiator is a legitimate 390 correspondent or, e.g., a forged message from an denial of service 391 attack; no round trip has yet occurred with the Initiator. 392 Therefore, it is important that the Responder not be required at 393 this point to perform expensive calculations or create state. 394 Here, the Responder's cost will be a single authentication 395 operation, the cost of which (for HMAC) is dominated by two 396 invocations of a cryptographic hash function, plus generation of a 397 random nonce Nr. Notice that, if the Responder is reusing the 398 same g^r across multiple Initiators, the beginning of the HMAC 399 computation can be cached along with g^r. 401 The Responder may compute a new exponential g^r for each 402 interaction. This is an expensive option, however, and at times of 403 high load (or attack) it would be inadvisable. The nonce prevents 404 two successive session keys from being the same, even if both the 405 Initiator and the Responder are reusing exponentials. 407 A simple way of dealing with DDoS is to periodically (e.g., once 408 every 30 seconds) generate an (r, g^r, HMAC(HKr){g^r}) tuple and 409 place it in a FIFO queue. As requests arrive (in particular, as 410 valid Message (3)'s are processed), the first entry from the FIFO 411 is removed. If the rate of requests exceeds the generating rate, a 412 JFKr implementation should reuse the last tuple in the FIFO. 413 Notice that in this scheme, the same g^r may be reused in different 414 sessions, if those sessions are interleaved. This does not violate 415 the PFS or other security properties of the protocol. 417 If the Responder is willing to accept the group identified in the 418 Initiator's message, his exponential must be in the same group. 419 Otherwise, he may respond with an exponential from any group of his 420 own choosing. The field GRPINFOr lists what groups the Responder 421 finds acceptable, if the Initiator should wish to restart the 422 protocol. This provides a simple mechanism for the Initiator to 423 discover the groups currently allowed by the Responder. That field 424 also lists what encryption algorithm is acceptable for the next 425 message. This is not negotiated; the Responder has the right to 426 decide what strength encryption is necessary to use his services. 428 Note that the Responder creates no state when sending this message. 429 If it is bogus --- that is, if the Initiator is non-existent or 430 intent on perpetrating a denial-of-service attack --- the Responder 431 will not have committed any storage resources. 433 In Message (3), the Initiator echoes content from the Responder's 434 message, including the authenticator. The authenticator allows the 435 Responder to verify that he is in round-trip communication with a 436 legitimate potential correspondent. She also uses the key derived 437 from the two exponentials and the two nonces to encrypt her 438 identity and service request. (The Initiator's nonce is used to 439 ensure that this session key is unique, even if both the Initiator 440 and the Responder are reusing their exponentials and the Responder 441 has ``forgotten'' to change nonces.) The key used to protect 442 Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The 443 session key used by IPsec (or any other application), Kir, is 444 HMAC{g^ir}(Ni, Nr, 0). The message authentication key, Ka, is 445 computed as HMAC{g^ir}{Ni, Nr, 2}. For this computation, the 446 values '0', '1', and '2' correspond to a single-byte decimal value 447 (so the HMAC computation is over the two nonces and one extra byte, 448 with the corresponding value). 450 In JFKr, the parties obtain a shared encryption key, Ke, before any 451 of the parties send their identities. Therefore, both parties send 452 their identities encrypted with Ke, thus providing both parties 453 with identity protection against passive eavesdroppers. In 454 addition, the party that first reveals its identity is the 455 initiator. This way, the responder is required to reveal its 456 identity only after it verifies the identity of the initiator. 457 This guarantees active identity protection to the responder. 459 The service request (sa payload) is encrypted too, since its 460 disclosure might identify the requester. The Responder may wish to 461 require a certain strength of cryptographic algorithm for certain 462 services. 464 We remark that it is essentially impossible, using current 465 technology, to provide a two-round-trip protocol that provides DOS 466 protection for the responder, passive identity protection for both 467 parties, and active identity protection for the initiator. An 468 informal argument proceeds as follows: If DoS protection is in 469 place, then the responder must be able to send his first message 470 before he computes any shared key. (This is so since computing a 471 shared key is a relatively costly operation in current technology.) 472 This means that the responder cannot send its identity in the 473 second message, without compromising its identity protection 474 against passive eavesdroppers. This means that the responder's 475 identity must be sent in the fourth (and last) message of the 476 protocol. Consequently, the initiator's identity must be sent 477 before the responder's identity is sent. 479 Upon successful receipt and verification of message (3), the 480 Responder has a shared key with a party known to be the Initiator. 481 The Responder further knows what service the Initiator is 482 requesting. At this point, he may accept or reject the request. 484 The Responder's processing on receipt of Message (3) requires 485 verifying an authenticator and --- if that is successful --- 486 performing several public key operations to verify the Initiator's 487 signature and certificate chain. The authenticator (again 488 requiring two hash operations) is sufficient defense against 489 forgery; replays, however, could cause considerable computation. 490 The defense against this is to cache the corresponding Message (4); 491 if a duplicate Message (3) is seen, the cached response is 492 retransmitted; the Responder does not create any new state or 493 notify the application (e.g., IPsec). The key for looking up 494 Message 3's in the cache is the authenticator; this prevents 495 DoS attacks where the attacker randomly modifies the encrypted 496 blocks of a valid message, causing a cache miss and thus more 497 processing to be done at the Responder. Further, if the 498 authenticator verifies but there is some problem with the message 499 (e.g., the certificates do not verify), the responder can cache the 500 authenticator along with an indication as to the failure (or the 501 actual rejection message), to avoid unnecessary processing (which 502 may be part of a DoS attack). This cache of Message(3)'s and 503 authenticators can be purged as soon as HKr is changed (since the 504 authenticator will no longer pass verification). 506 Caching Message (3) and refraining from creating new state for 507 replayed instances of Message (3) serves also another security 508 purpose. If the Responder were to create a new state and send a 509 new Message (4), and a new sa' for a replayed Message (3), then an 510 attacker that compromised the Initiator could replay a recent 511 session with the Responder. That is, by replaying Message (3) from 512 a recent exchange between the Initiator and the Responder, the 513 attacker could establish a session with the Responder where the 514 session-key is identical to the key of the previous session (which 515 took place when the Initiator was not yet compromised). This could 516 compromise the Forward Security of the Initiator. 518 There is a risk, however, to keeping this message cached for too 519 long: if the Responder's machine is compromised during this period, 520 perfect forward secrecy is compromised. We can tune this by 521 changing the MAC key HKr more frequently. The cache can be reset 522 when a new HKr is chosen. 524 In Message (4), the Responder sends to the Initiator any 525 Responder-specific application data (e.g., the Responder's IPsec 526 SPI), along with a signature on both nonces, both exponentials, and 527 the Initiator's identity. All the information is encrypted using a 528 key derived the two nonces, Ni and Nr, and the Diffie-Hellman 529 result. The Initiator can verify that the Responder is present and 530 participating in the session, by decrypting the message and 531 verifying the enclosed signature. 533 2.4 Rejection Messages 535 Instead of sending Messages (2) or (4), the Responder can send a 536 'rejection' instead. For Message (2), this rejection can only be 537 on the grounds that he does not accept the group that the Initiator 538 has used for her exponential. Accordingly, the reply should 539 indicate what groups are acceptable. Since Message (2) already 540 contains the field GRPINFOr (which indicates what groups are 541 acceptable), no explicit rejection message is needed. (For 542 efficiency sake, the group information could also be in the 543 Responder's long-lived certificate, which the Initiator may already 544 have.) 546 Message (4) can be a rejection for several reasons, including lack 547 of authorization for the service requested. But it could also be 548 caused by the Initiator requesting cryptographic algorithms that 549 the Responder regards as inappropriate, given the requester 550 (Initiator), the service requested, and possibly other information 551 available to the Responder, such as the time of day or the 552 Initiator's location as indicated by the network. In these cases, 553 the Responder's reply should list acceptable cryptographic 554 algorithms, if any. The Initiator would then send a new Message 555 (3), which the Responder would accept de novo; again, the Responder 556 does not create any state until after a successful Message (3) 557 receipt. 559 2.5 What JFK Avoids 561 By intent, JFK does not do certain things. It is worth enumerating 562 them, if only to forestall later attempts to add them in. The 563 ``missing'' items were omitted by design, in the interests of 564 simplicity. 566 In our view, any form of authentication other than certificate 567 chain trusted by the other party is best accomplished by outboard 568 protocols. Initiators that wish to rely on any form of legacy 569 authentication can use the protocols being defined by the IPSRA or 570 SACRED working groups. While these mechanisms do add extra round 571 trips, the expense can be amortized across many JFK negotiations. 572 Similarly, certificate chain discovery (beyond the minimal 573 capabilities implicit in IDi and IDr) should be accomplished by 574 protocols defined for that purpose. By excluding these protocols 575 for JFK, we can exclude them from our security analysis; the only 576 interface between the two is a certificate chain, which by 577 definition is a stand-alone secure object. However, it is possible 578 to use the lightweight JFK mode, as described in Section 3, to 579 perform shared-secret based authentication. 581 We also eliminate negotiation, in favor of ukases issued by the 582 Responder. The Responder is providing a service; it is entitled to 583 set its own requirements for that service. Any cryptographic 584 primitive mentioned by the Responder is acceptable; the Initiator 585 can choose any it wishes. We thus eliminate complex rules for 586 selecting the ``best'' choice from two different sets. We also 587 eliminate state to be kept by the Responder; the Initiator can 588 either accept the Responder's desires or restart the protocol. 590 Finally, we reject the notion of two different phases. The 591 practical benefits of quick mode are limited. Furthermore, we do 592 not agree that frequent rekeying is necessary. If the underlying 593 block cipher is sufficiently limited as to bar long-term use of any 594 one key, the proper solution is to replace that cipher. For 595 example, 3DES is inadequate for protection of very high speed 596 transmissions, because the probability of collision in CBC mode 597 becomes too high after less than encryption of $2^{32}$ plaintext 598 blocks. Using AES instead of 3DES solves that problem without 599 complication the key exchange. Should low-cost rekeying be 600 necessary, the JFK protocol itself can be run in ``lightweight'' 601 mode, as we describe in Section 3. 603 2.6 Phase II and the Lack Thereof 605 Phase II of IKE is used for several things. We do not regard any 606 of them as necessary. 608 One is generating the actual keying material used for security 609 associations. It is expected that this will be done several 610 times, to amortize the expense of the Phase I negotiation. 611 A second reason for this is to permit very frequent rekeying. 612 Finally, it permits several separate security associations to 613 be set up, with different parameters. 615 We do not think these apply. First, with modern ciphers, such as 616 AES, there is no need for frequent key changes. AES keys are long 617 enough that brute force attacks are infeasible. Its longer block 618 size protects against CBC limitations when encrypting many blocks 619 [BDJR97]. 621 We also feel that JFK is efficient enough that avoiding the 622 overhead of a full key exchange is not required. Rather than add 623 new SAs to an existing Phase I SA, we suggest that a full JFK 624 exchange be initiated instead. We note that the initiator can also 625 choose to reuse its exponential, it if wishes to trade perfect 626 forward secrecy for computation time. If state already exists 627 between the initiator and the responder, they can simply check that 628 the Diffie-Hellman exponentials are the same; if so, the result of 629 the previous exponentiation can be reused. As long as one of the 630 two parties uses a fresh nonce in the new protocol exchange, the 631 resulting cryptographic keys will be fresh and not subject to a 632 related key (or other, similar) attack. As we discuss in Section 633 3, a similar performance optimization can be used on the 634 certificate chain validation. 636 A second major reason for Phase II is dead peer detection. IPsec 637 gateways often need to know if the other end of a security 638 association is dead, both to free up resources and to avoid "black 639 holes". In JFK, this is done by noting the time of the last packet 640 received. A peer that wishes to elicit a packet may send a "ping". 641 Such hosts MAY decline any proposed security associations that do 642 not permit such "ping" packets. 644 A third reason for Phase II is general security association 645 control, and in particular SA deletion. While such a desire is not 646 wrong, we prefer not to burden the basic key exchange mechanism 647 with extra complexity. There are a number of possible approaches. 648 Our requires that JFK endpoints implement the following rule: a new 649 negotiation that specifies an SPD identical to the SPD of an 650 existing SA overwrites it. To some extent, this removes any need 651 to delete an SA if black hole avoidance is the concern; you simply 652 negotiate a new one. If you wish to delete an SA without replacing 653 it, negotiate a new SA with the ESP_BYPASS, AH_BYPASS or 654 IPCOMP_BYPASS ciphersuite. 656 3. Rekeying 658 When a negotiated SA expires (or shortly before it does), the JFK 659 protocol is run again. It is up to the application to select the 660 appropriate SA to use among many valid ones. In the case of IPsec, 661 implementations should switch to using the new SA for outgoing 662 traffic, but would still accept traffic on the old SA (as long as 663 that SA has not expired). 665 To address performance considerations, we should point out that, 666 properly implemented, rekeying only requires one signature and one 667 verification operation in each direction, if both parties use the 668 same Diffie-Hellman exponentials (in which case the cached result 669 can be reused) and certificates: the receiver of an ID payload 670 compares its hash with those of any cached ID payloads received 671 from the same peer. While this is an implementation detail, a 672 natural location to cache past ID payloads is along with already 673 established SAs (a convenient fact, as rekeying will likely occur 674 before existing SAs are allowed to expire --- so the ID information 675 will be readily available). If a match is found and the result has 676 not "expired" yet, then we do not need to re-validate the 677 certificate chain. A previously verified certificate chain is 678 considered valid for the shortest of its CRL re-validate time, 679 certificate expiration time, OCSP result validity time, etc. For 680 each certificate chain, there is one such value associated (the 681 time when one of its components becomes invalid or needs to be 682 checked again). 684 Notice that an implementation does need to cache the actual ID 685 payloads; all that is needed is the hash and the expiration time. 687 That said, if for some reason fast rekeying is needed for some 688 application domain, it can be done by re-using the JFKr protocol 689 itself, using an ID payload identifying a previous exchange (and 690 thus a corresponding secret key generated during that exchange) and 691 an HMAC instead of a public-key signature for authentication. 693 Message 1, I->R: Ni, g^i 695 Message 2, R->I: Ni, Nr, g^r, GRPINFOr, 696 HMAC{HKr}(g^r, Nr, Ni, IPi) 698 Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi), 699 E{Ke}(IDi, IDr' sa, HMAC{Ks}(Ni, Nr, g^i, g^r, GRPINFOr)), 700 HMAC{Ka}('I', E{Ke}(IDi, IDr', sa, HMAC{Ks}(Ni, Nr, g^i, g^r, GRPINFOr))) 702 Message 4, R->I: Ni, Nr, E{Ke}(IDr, sa', HMAC{Ks}(g^r, Nr, g^i, Ni)), 703 HMAC{Ka}('R', E{Ke}(IDr, sa', HMAC{Ks}(g^r, Nr, g^i, Ni))) 705 The only difference from the basic JFKr protocol is the use of an 706 HMAC in messages 3 and 4 for peer authentication. The HMAC is 707 computed over the same fields as the public key signature in the 708 basic protocol. The shared key, Ks, is either statically 709 configured (when JFKr is used for shared-secret based 710 authentication) or is derived from a previous exchange. 712 Payloads IDi and IDr identify the secret key in use. For 713 shared-secret authentication, these are free-form strings that are 714 configured by the administrator (or otherwise provided through 715 means outside the JFK protocol's scope). 717 When Ks is derived from a previous JFKr exchange, the IDi and IDr 718 payloads contain unique identifiers provider by the Responder and 719 the Initiator respectively in the previous protocol exchange, and 720 are used to identify the shared-secret. These identifiers should 721 be treated as opaque bitstrings by the receiver. Effectively, at 722 each protocol run, each party provides their peer with a cookie. 723 This cookie can be used by the peer in subsequent rounds to 724 identify the shared secret to use for authentication. 726 When run in lightweight mode, and if both parties reuse the 727 exponentials g^i and g^r, new application (e.g., IPsec) SAs can be 728 established without any public-key operations. If PFS is desired, 729 then both parties have to perform one modular exponentiation 730 operation (for the Diffie-Hellman computation). No signature or 731 certificate verification is require for this mode. 733 4. Wire Format 735 This section describes a proposal for the specific protocol 736 elements for the protocol described in this document. The authors 737 of the document are not strongly attached to these proposed 738 elements. More detail on the protocol elements will be added in 739 later drafts. 741 The protocol will be run over UDP on a port to be assigned later by 742 IANA. UDP is chosen to avoid well-known TCP attacks, although 743 running JFK over UDP may cause some problems with packet 744 fragmentation and reordering. For pre-standards testing purposes, 745 UDP port 1024 which is reserved by IANA and will *not* be the 746 eventual port for JFK. 748 Implementors of IKE have long complained that the specification 749 required or strongly suggested too many algorithms that had 750 essentially the same properties. Because of this, JFK only lists 751 one option for each type of algorithm below. In the future, 752 additional options might be added (which is why there are algorithm 753 identifiers in the protocol), but they should only be added if 754 there is a strong security requirement for them. Two such 755 requirements would be the compromise of one of the listed 756 algorithms or the adoption of a much stronger or much more capable 757 algorithm. Additional algorithms can only be added by a 758 standards-track RFC. 760 4.1 Structure 762 Each message is a string of tag-length-value elements concatenated 763 together. Tags are one octet. Lengths are two octets, and specify 764 the number of octets of the value. Values are always integral 765 numbers of octets. All octets are in big-endian order. 767 The values for the tags are: 769 Tag Value (in decimal) 770 Ni 1 771 Nr 2 772 g^i 3 773 g^r 4 774 GRPINFOr 5 775 IDi 6 776 IDr, IDr' 7 777 Signature 8 778 HashedInfo 9 779 encrypt_i 10 780 encrypt_r 11 781 sa, sa' 12 782 rejectinfo_to_msg3 13 784 4.2 Description of the values for each tag 786 Nonces Ni and Nr MUST be 8 octets or longer. 788 g^i and g^r are expressed as a single octet specifying the group 789 number, followed by value of Diffie-Hellman exponential. The group 790 number is the same as the group numbers used in [RFC2409]. 792 GRPINFOr is expressed as a string of at least four octets. The 793 first octet is the encryption algorithm ID, the second octet is the 794 signature algorithm ID, and the third octet is the hash function 795 used for session key derivation. Each remaining octet specifies an 796 acceptable group number. 798 IDi, IDr, and IDr' are expressed as a single octet specifying the 799 type of ID used, followed by the ID material. The following ID 800 types are specified. 802 ID tag Meaning 803 1 PKIX certificate 804 2 CRL 805 3 OCSP response 807 Signatures are expressed as one octet specifying the signature 808 algorithm followed by the octets of the signature. 810 HashedInfo is expressed as one octet specifying the keyed hash 811 algorithm followed y the octets of the hash. 813 encrypt_i and encrypt_r are expressed as one octet specifying the 814 encryption algorithm followed by the encrypted content. When using 815 a block cipher with chaining, requiring an Initialization Vector 816 (IV), the IV is prepended to the ciphertext and constitutes the 817 first block of the payload. 819 sa and sa' are expressed by one octet specifying the SA type 820 followed by the SA itself. The following SA types are specified. 822 SA tag Meaning 823 1 IPsec SA, as described below. 824 2 Opaque identifier for lightweight mode 825 authentication. Contents should be treated as a bit-string 826 and passed as is to the peer on subsequent rounds of 827 the protocols, to identify the correct key Ks to use for 828 the HMAC computation. 830 Both types (1 and 2) of sa payload may appear in messages 3 and 4. 832 rejectinfo_to_msg3 has the same structure as grpInfo. 834 Encryption algorithm IDs (for use in JFK only) 835 3DES 1 837 Signature algorithm IDs (for use in JFK only) 838 RSA 1 840 Hash algorithm IDs (for use in JFK only) 841 SHA-1 1 843 5. Security Associations and the Security Policy Database 845 Security Association in JFK follows the two primary principles 846 of JFK: simplicity and lack of negotiation. The latter 847 is straightforward: an initiator proposes an SA; the 848 responder may either accept it or reject it with a reason. 850 The myriad combinations of cipher and authentication suites 851 available in IKE contributed in no small measure to 852 interoperability problems. We follow the suggestion put forth by 853 an early IKEv2 draft: the acceptable combinations are denoted by 854 16-bit, unstructured integers. The integers may happen to be 855 assigned according to some structuring principle, but 856 implementations MUST NOT treat them as other than opaque values. 858 The initial set of algorithms that MUST be supported is: 860 ESP-AES-CBC with HMAC-SHA1 861 ESP-3DES-CBC with HMAC-MD5 862 ESP-3DES-CBC with HMAC-SHA1 863 ESP-NULL with HMAC-MD5 864 ESP-NULL with HMAC-SHA1 865 ESP_BYPASS 866 AH with HMAC-MD5 867 AH with HMAC-SHA1 868 AH_BYPASS 869 IPCOMP_DEFLATE 870 IPCOMP_BYPASS 872 The 3DES choices are for backwards compatibility. We do not 873 specify a DES variant -- DES was demonstrated to be insecure 874 several years ago, and implementors have had time to upgrade. 875 We do support MD5, but recommend that it not be used. 877 The *_BYPASS entries are used to indicate that existing SAs of 878 that type that have previously been negotiated between the two 879 peers should be deleted. 881 Following the algorithm choice is a 4-byte value containing the 882 sender's SPI, in network byte order (big endian format). 884 Following the SPI are two lists of zero or more SPD elements, the 885 list of source addresses followed by the list of destination 886 addresses. 888 JFK supports two different address types: a list of IPv4 address 889 ranges, and a list of IPv6 address ranges. A single address is a 890 range where the starting and ending elements are the same. 891 Subnets are converted to range format. The notion of "all 892 addresses" is expressed as the pair (0, 0xFFFFFFFF) for IPv4; v6 893 is handled similarly. 895 Port numbers are also expressed as pairs; again, the concept 896 of "all ports" is represented as (0, 0xFFFF). The same is 897 done for protocols. 899 An SPD element has the following format: 901 Address family version v4/v6 (2 bytes) 902 Transport protocol range (TCP, UDP, etc.) (2 bytes) 903 Number of address ranges (2 bytes) 904 address ranges... 905 Number of port number ranges (2 bytes) 906 port number ranges... 908 An SPD source or destination specification consists of a two-byte 909 counter for the number of SPD elements, followed by each element. 910 The simplest entry -- all protocols, all ports, all addresses, for 911 IPv4 -- would look like this: 913 Bytes 914 1 2 915 ---- 916 0001 Number of SPD elements (1 element) 917 0004 Address family (IPv4 addresses) 918 00FF Protocol range (all transport protocols) 919 0001 One address range 920 0000,0000 (4 bytes, 0.0.0.0) 921 FFFF,FFFF (4 bytes, 255.255.255.255) 922 0001 Number of port ranges (1 port range) 923 0000 Beginning of transport protocol port range (port 0) 924 FFFF End of port range (port 65535) 926 Two specifications are contained in the sa and sa' payloads, one 927 for the source range followed by one for the destination range. 929 When transmitted on the wire, all values are sent in big endian 930 format. 932 6. Security Considerations 934 This section very briefly overviews our security analysis of the 935 JFK protocol. Full details are deferred to the full analysis paper. 937 In general, there are currently two main approaches to analyzing 938 security of protocols. One is the formal-methods approach, where 939 the cryptographic components of a protocol are modeled by "ideal 940 boxes" and automatic theorem-verification tools are used to verify 941 the validity of the high-level design (assuming ideal 942 cryptography). The other is the cryptographic approach, which 943 accounts for the facts that cryptographic components are imperfect 944 and may potentially interact badly with each other. Here security 945 of protocols is proven based on some underlying computational 946 intractability assumptions (such as the hardness of factoring large 947 numbers, or computing discrete logarithms modulo a large prime, or 948 inverting a cryptographic hash function). The formal-methods 949 approach, being automated, has the advantage that it is less 950 susceptible to human errors and oversights in analysis. On the 951 other hand, the cryptographic approach provides better soundness 952 since it considers the overall security of the protocol, and in 953 particular accounts for the imperfections of the cryptographic 954 components. 956 Our analysis follows the cryptographic approach. We welcome any 957 additional analysis. In particular, analysis based on formal 958 methods would be a useful complement to the analysis described 959 here. 961 We separate the analysis of the "core security" of the protocol 962 (which is rather tricky) from the analysis of added security 963 features such as DoS protection and identity protection (which is 964 much more straightforward). The rest of this section concentrates 965 on the "core security" of the protocol. DoS and Identity protection 966 were discussed in previous sections. 968 6.1 Core security 970 We use the modeling and treatment of [CK01], which in turn is based 971 on [BR93]. See there for more references and comparisons with other 972 analytical work. Very roughly, the "core security" of a key exchange 973 protocol boils down to two requirements: 975 * If party A generates a key Ka associated with a 976 session-identifier S and peer identity B, and party B generates 977 a key Kb associated with the same session identifier S and peer 978 A, then Ka=Kb. 980 * No attacker can distinguish between the key exchanged in a session 981 between two unbroken parties and a truly random secret. This holds 982 even if the attacker has total control over the communication, can 983 invoke multiple sessions, and is told the keys generated in all 984 other sessions. 986 We stress that this is only a rough sketch of the requirement. 987 For full details see [CK01,CK02]. We show that both JFKi and 988 JFKr satisfy the above requirement. When these protocols are 989 run with perfect forward secrecy, the security is based on a 990 standard intractability assumption of the DH problem. When a 991 party reuses its DH value, the security is based on a stronger 992 assumption intractability assumption involving both DH and the 993 HMAC pseudo random function. 995 We first analyze the protocols in the restricted case where the 996 parties do not re-use the private DH exponents for multiple sessions. 997 (This is the bulk of the work.) Here the techniques for demonstrating 998 the security of the two protocols are quite different. Specifically: 1000 (I) JFKi: The basic cryptographic core of this protocol is the same as 1001 the ISO 9798-3 protocol, which was analyzed and proven secure 1002 in [CK01]. This protocol can be briefly summarized as follows: 1004 A->B: A,N_a,g^a 1005 B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,A) 1006 A->B: SIG_a(N_a,N_b,g^a,g^b,B) 1008 A salient point about this protocol is that each party signs, in 1009 addition to the nonces and the two public DH exponents, also the 1010 identity of the peer. (If the peer's identity is not signed then 1011 the protocol is completely broken.) JFKi inherits the same basic core 1012 security. In addition, JFKi adds a preliminary cookie mechanism 1013 for DoS protection (which results in adding one flow to the protocol 1014 and having the *responder* in JFKi play the role of A), and encrypts 1015 the last two messages in order to provide identity protection to 1016 the initiator. 1018 (II) JFKr: The basic cryptographic core of this protocols is the 1019 same as that of the signature mode of IKE and SIGMA [K01], 1020 which was analyzed and proven secure in [CK02]. This basic protocol 1021 can be briefly summarized as follows: 1023 A->B: N_a,g^a 1024 B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b),MAC_{Ka}(Na,Nb,B) 1025 A->B: A,SIG_a(N_a,N_b,g^a,g^b),MAC_{Ka}(Na,Nb,A) 1027 Here neither party signs the identity of its peer. Instead, each 1028 party includes a MAC, keyed with a key derived from g^ab, and 1029 applied to its own identity (concatenated with Na and Nb). 1030 JFKr inherits the same basic core security as this protocol. 1031 In addition, JFKr adds a preliminary cookie mechanism 1032 for DoS protection (which results in adding one flow to the 1033 protocol and having the *responder* in JFKr play the role of A), 1034 and encrypts the last two messages in order to provide identity 1035 protection. (Here the identity protection covers both parties, 1036 since the identities are sent only in the last two messages.) 1038 The next step in the analysis is to generalize to the case 1039 where the private DH exponents are re-used across sessions. This 1040 is done by making stronger (but still reasonable) computational 1041 intractability assumptions involving both DH problem and the HMAC 1042 pseudo random function. We defer details to the full analysis paper. 1044 7. IANA Considerations 1046 IANA is asked to assign a UDP port for JFK at the time that this 1047 draft becomes an RFC. Also, the algorithm identifiers will need to 1048 be kept in an IANA registry. These two requests will be described 1049 in more detail in a future version of this draft. 1051 8. Acknowledgments 1053 We would like to thank Paul Hoffman for suppling us with the draft 1054 text in Section 4 (Wire Format), and his constant prodding us in 1055 getting this document done. Ran Atkinson, Matt Crawford, and Eric 1056 Rescorla provided useful comments, and discussions with Hugo 1057 Krawczyk proved very useful. Dan Harkins suggested the inclusion 1058 of IPi in the authenticator. 1060 Appendix A. Protocol JFKi 1062 In the following, "I->R" means a message from the Initiator to the 1063 Responder and "R->I" means the opposite direction. 1065 Message 1, I->R: Ni, g^i, IDr' 1067 Message 2, R->I: Ni, Nr, g^r, GRPINFOr, IDr, 1068 SIG{r}(g^r, GRPINFOr), 1069 HMAC{HKr}(g^r, Nr, Ni, IPi) 1071 Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi), 1072 E{Ke}(IDi, sa, SIG{i}(Ni, Nr, g^i, g^r, IDr, sa)) 1074 Message 4, R->I: Ni, Nr, 1075 E{Ke}(SIG{r}(Ni, Nr, g^i, g^r, IDi, sa, sa'), sa') 1077 The key used to protect Messages (3) and (4), Ke, is computed as 1078 HMAC{g^ir}(Ni, Nr, 1). The session key used by IPsec (or any other 1079 application), Kir, is HMAC{g^ir}(Ni, Nr, 0). 1081 If more key material is needed, the same mechanism for "key 1082 stretching" as specified in [IKEv2] may be used. 1084 Message (1) is straightforward; note that it assumes that the 1085 Initiator already knows a group and generator that is acceptable to 1086 the Responder. The Initiator can reuse a g^i value in multiple 1087 instances of the protocol with the Responder or other responders 1088 that accept the same group, for as long as she wishes her forward 1089 secrecy interval to be. We discuss how the Initiator can discover 1090 what groups to use later. This message also contains an indication 1091 as to which ID the Initiator would like the Responder to use to 1092 authenticate. In contrast to JFKr, IDr' is sent in the clear; 1093 however, notice that the responder's ID in Message (2) is also sent 1094 in the clear, so there is no loss of privacy in this respect. 1096 Message (2) is more complex. Assuming that the Responder accepts 1097 the Diffie-Hellman group in the Initiator's message (rejections are 1098 discussed elsewhere in this document), he replies with a signed 1099 copy of his own exponential (in the same group), information on 1100 what secret key algorithms are acceptable for the next message, a 1101 random nonce, his identity (certificates or a bit-string 1102 identifying his public key), and an authenticator calculated from a 1103 secret, HKr, known to the Responder; the authenticator is computed 1104 over the two exponentials and nonces, and the Initiator's network 1105 address. The authenticator key is changed at least as often as 1106 g^r, thus preventing replays of stale data. The Responder's 1107 exponential may also be reused; again, it is regenerated according 1108 to the Responder's forward secrecy interval. The signature on the 1109 exponential needs to be calculated at the same rate as the 1110 Responder's forward secrecy interval (when the exponential itself 1111 changes). Finally, note that the Responder does not need to 1112 generate any state at this point, and the only ``expensive'' 1113 operation is a MAC calculation. 1115 Message (3) echoes back the data sent by the Responder, including 1116 the authenticator. The authenticator is used by the Responder to 1117 verify the authenticity of the returned data. The authenticator 1118 also confirms that the sender of Message (3) uses the same address 1119 as in Message (1) --- this can be used to detect and counter a 1120 ``cookie jar'' DDoS attack. The message also includes the 1121 Initiator's identity and service request, and a signature computed 1122 over the nonces, the Responder's identity, and the two 1123 exponentials. This latter information is all encrypted under a key 1124 derived from the Diffie-Hellman computation and the nonces Ni and 1125 Nr. The encryption and authentication use algorithms specified in 1126 GRPINFOr. The Responder keeps a copy of recently-received Message 1127 (3)'s, and their corresponding Message (4). Receiving a duplicate 1128 (or replayed) Message (3) causes the Responder to simply retransmit 1129 the corresponding Message (4), without creating new state or 1130 invoking IPsec. This cache of messages can be reset as soon as g^r 1131 or HKr are changed. The Responder's exponential (g^r) is re-sent 1132 by the Initiator because the Responder may be generating a new g^r 1133 for every new JFK protocol run (e.g., if the arrival rate of 1134 requests is below some threshold). Note: It is important that the 1135 responder deals with repeated Message (3)'s as described above. 1136 Responders that create new state for a repeated Message (3) open 1137 the door to attacks against the protocol. 1139 Note that the signature is protected by the encryption. This is 1140 necessary, since everything signed is public except the sa, and 1141 that is often guessable. An attacker could verify guesses at 1142 identities, were it not encrypted. 1144 Message (4) contains application-specific information (such as the 1145 Responder's IPsec SPI), and a signature on both nonces, both 1146 exponentials, and the Initiator's identity. Everything is encrypted 1147 by Ke, which is derived from Ni, Nr, and g^ir (the result of the 1148 Diffie-Hellman computation). 1150 Appendix B. Avoiding Fragmentation-based DoS Attacks 1152 Since Message (3) contains certificates, it may be larger than the 1153 MTU and thus require fragmentation (with most common certificate 1154 formats, this will be the case only if there are more than 2 1155 certificates included in the payload). Thus, it is possible for an 1156 attacker to send partial fragments of a Message (3) packet in an 1157 attempt to saturate the Responder's reassembly queue and thus deny 1158 service to legitimate Initiators. Similar considerations hold for 1159 Message (4). 1161 To avoid this, we propose that the following mechanism be used by 1162 the underlying operating system: 1164 - The operating system periodically selects a secret value (16 bits 1165 for IPv4, 32 bits for IPv6). This value is also provided to the 1166 JFK implementation. 1168 - The operating system also maintains two reassembly queues: one 1169 for fragments that contain the correct cookie in the ip_id field 1170 (for IPv4 packets) or the ip6f_ident field (for IPv6 packets, in 1171 the fragmentation header). Both queues are of fixed size. While 1172 the privileged queue may be larger (to accomodate higher traffic 1173 volumes), this is not strictly necessary. 1175 - The cookie is encoded in the first 16 (or 32) bits of the Nonce 1176 of the appropriate party (Ni or Nr). These should be copied 1177 verbatim (i.e., without any byte-swapping etc.) to the 1178 appropriate field in the IPv4 header or the IPv6 fragmentation 1179 header. 1181 - The cookie is computed by applying a hash function on the peer's 1182 IP address and the host secret, then taking the first 16 or 32 1183 bits. Both the operating system and the JFK implementation can 1184 perform this computation. The actual algorithm used to compute 1185 the cookie is left up to the implementation; a fast keyed hash or 1186 equivalent algorithm should be used. 1188 Notice that if multiple retransmissions of the same packet are 1189 performed, all fragments of all instances of the same packet will 1190 have the same identification number (whereas they are supposed to 1191 have different values). Since, however, no field of Message (3) or 1192 (4) changes between retransmissions, this poses no problem even if 1193 the sender's network stack fragments the packets in different 1194 ways. 1196 Finally, notice that no changes are required on the protocol, and 1197 the Initiator's and Responder's operating systems may or may not 1198 implement this functionality independently, without affecting 1199 interoperability. 1201 References: 1203 [BDJR97] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of 1204 Symmetric Encryption: Analysis of the DES Modes of Operation", 1205 1997, http://www-cse.ucsd.edu/users/mihir/. 1207 [BR93] Bellare and Rogaway, "Entity authentication and key 1208 distribution", Crypto '93. Available at 1209 http://www-cse.ucsd.edu/users/mihir. 1211 [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols 1212 and Their Use for Building Secure Channels", Eurocrypt 01. 1213 Available at http://eprint.iacr.org/2001/040. 1215 [CK02] Canetti and Krawczyk, "Security Analysis of IKE's Signature- 1216 based Key-Exchange Protocol", manuscript, 2002. 1218 [IKEv2] Harkins, Kaufman, Kent, Kivinen, Perlman, "Proposal for 1219 the IKEv2 Protocol", draft-ietf-ipsec-ikev2-01.txt. 1220 February 2002. Work in Progress. 1222 [K01] Krawczyk, "The IKE-SIGMA Protocol". Available at 1223 http://tiger.technion.ac.il/~hugo/ 1224 draft-krawczyk-ipsec-ike-sigma-00.txt. Nov 2001. Work 1225 in progress. 1227 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 1228 Message Authentication. RFC 2104. February 1997. 1230 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1231 Internet Protocol", RFC 2401, November 1998. 1233 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1234 (IKE)", RFC 2409, November 1998. 1236 [RFC2522] Karn, Simpson, "Photuris: Session-Key Management Protocol", 1237 RFC 2522, March 1999. 1239 Authors' addresses: 1241 The authors as a group can be reached by email at jfk@crypto.com 1243 William Aiello 1244 AT&T Labs - Research 1245 180 Park Avenue 1246 Florham Park, New Jersey 07932-0971 1248 Email: aiello@research.att.com 1250 Steven M. Bellovin 1251 AT&T Labs - Research 1252 180 Park Avenue 1253 Florham Park, New Jersey 07932-0971 1255 Email: smb@research.att.com 1257 Matt Blaze 1258 AT&T Labs - Research 1259 180 Park Avenue 1260 Florham Park, New Jersey 07932-0971 1262 Email: mab@research.att.com 1264 Ran Canetti 1265 IBM T.J. Watson Research Center 1266 30 Saw Mill Rover Road 1267 Hawthorne, New York 10532 1268 Email: canetti@watson.ibm.com 1270 John Ioannidis 1271 AT&T Labs - Research 1272 180 Park Avenue 1273 Florham Park, New Jersey 07932-0971 1275 Email: ji@research.att.com 1277 Angelos D. Keromytis 1278 Columbia University, CS Department 1279 515 CS Building 1280 1214 Amsterdam Avenue, Mailstop 0401 1281 New York, New York 10027-7003 1283 Phone: +1 212 939 7095 1284 Email: angelos@cs.columbia.edu 1286 Omer Reingold 1287 AT&T Labs - Research 1288 180 Park Avenue 1289 Florham Park, New Jersey 07932-0971 1291 Email: omer@research.att.com 1293 Expiration and File Name 1295 This draft expires in September 2002 1297 Its file name is draft-ietf-ipsec-jfk-04.txt