idnits 2.17.1 draft-montenegro-sucv-03.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 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? == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 1157: '... algorithms that MUST be supported is:...' RFC 2119 keyword, line 1200: '...s version of sucvP MUST always contain...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 638 has weird spacing: '...air and a k'...' -- 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.) -- The document date (July 2002) is 7955 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) == Missing Reference: 'DSA' is mentioned on line 580, but not defined == Missing Reference: 'RFC2412' is mentioned on line 582, but not defined == Missing Reference: 'RFC2451' is mentioned on line 587, but not defined == Unused Reference: 'BIRTH' is defined on line 1432, but no explicit reference was found in the text == Unused Reference: 'WeakMD5' is defined on line 1486, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ADDROWN' -- Possible downref: Non-RFC (?) normative reference: ref. 'BIRTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'CAM' == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'HandBook' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2' ** Obsolete normative reference: RFC 2373 (ref. 'IPV6ADDR') (Obsoleted by RFC 3513) == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-jfk-03 -- Possible downref: Normative reference to a draft: ref. 'JFK' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 -- No information found for draft-ietf-mobileip-MIPv6-scrty_reqts - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIPv6SecReq' == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ike-modp-groups-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'PUZZLES' ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') -- Possible downref: Non-RFC (?) normative reference: ref. 'WeakMD5' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro 3 INTERNET DRAFT C. Castelluccia 4 July 2002 5 SUCV Identifiers and Addresses 6 draft-montenegro-sucv-03.txt 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC 2026. 13 Comments should be submitted to the Mobile IP mailing list 14 at mobile-ip@sunroof.eng.sun.com. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as ``work in 27 progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document addresses the identifier ownership problem. It 38 does so by using characteristics of Statistic Uniqueness and 39 Cryptographic Verifiability (SUCV) of certain entities which 40 this document calls SUCV Identifiers (SUCV ID's). This note 41 also proposes using these SUCV characteristics in related 42 entities called SUCV Addresses in order to severely limit 43 certain classes of denial of service attacks and hijacking 44 attacks. SUCV addresses are particularly applicable to solve the 45 'address ownership' problem that hinders confidence in 46 mechanisms like Binding Updates in Mobile IP for IPv6. 48 Table of Contents 50 1.0 Introduction .................................................. 3 51 2.0 Terminology ................................................... 3 52 3.0 Overview of the Proposal ...................................... 5 53 4.0 Statistical Uniqueness and Cryptographic Verifiability 54 (SUCV) ............................................................ 5 55 4.1 SUCV ID's .................................................. 5 56 4.3 SUCV Addresses ............................................. 6 57 4.4 SUCV Derivation and Formats ................................ 7 58 5.0 SUCV Protocol (sucvP) Overview ................................ 8 59 5.1 Goals and Constraints ...................................... 9 60 5.2 Packet Exchanges ........................................... 10 61 5.3 Deriving the Session Keys .................................. 12 62 5.3.1 SUCV Session Key ...................................... 12 63 5.3.2 Key for use with ESP .................................. 12 64 5.4 Default Algorithms ......................................... 13 65 6.0 Extension for Constrained Devices ............................. 13 66 7.0 Privacy Considerations ........................................ 14 67 7.1 Support for Random Addresses [RFC3041] ..................... 14 68 7.2 Support for Confidentiality ................................ 15 69 7.2.1 Confidentiality ....................................... 15 70 7.2.2 Location Privacy ...................................... 16 71 8.0 Security Analysis ............................................. 17 72 8.1 Hash ID Size Considerations ................................ 17 73 8.2 Key size considerations .................................... 19 74 8.3 Intruder-in-the-middle attacks ............................. 20 75 8.3.1 Summary of the Attack ................................. 20 76 8.3.2 Risks ................................................. 21 77 8.3.3 Why not Route sucvP2 Through the Home Agent? ......... 22 78 8.4 Denial-of-Service Attacks .................................. 23 79 9.0 Security Considerations ....................................... 24 80 10.0 Conclusions .................................................. 25 81 11.0 Acknowledgements ............................................. 25 82 A. Appendix: sucvP Protocol Specification and Packet Formats ...... 25 83 A.1. Packet Formats ............................................ 26 84 A.2. Common Header Format ...................................... 27 85 A.3. Cookie Puzzle Request Format .............................. 27 86 A.4. Cookie Puzzle Reply Format ................................ 27 87 A.5. P1 Packet Format .......................................... 28 88 A.6. P2 Packet Format .......................................... 28 89 A.7. P3 Packet Format .......................................... 29 90 A.8. P4 Packet Format .......................................... 30 91 A.9. P5 Packet Format .......................................... 30 92 References ........................................................ 31 93 Authors' addresses ................................................ 33 94 Changes ........................................................... 34 95 1.0 Introduction 97 This document addresses the identifier ownership problem 98 [ADDROWN] by using characteristics of Statistic Uniqueness and 99 Cryptographic Verifiability (SUCV) of certain entities which 100 this document calls SUCV Identifiers (SUCV ID's). This note 101 also proposes using these SUCV characteristics in related 102 entities called SUCV Addresses in order to severely limit 103 certain classes of denial of service attacks and hijacking 104 attacks. SUCV addresses can solve the 'address ownership' 105 problem that hinders confidence in mechanisms like Binding 106 Updates in Mobile IP for IPv6. 108 [ADDROWN] argues that there is a fundamental problem in handling 109 operations like Binding Updates (BU's) in Mobile IP for IPv6 110 [MIPv6], source routing, etc) that allows hosts to modify how 111 other hosts route packets to a certain destination. The problem 112 is that these operations can be misused by rogue nodes to 113 redirect traffic away from its legitimate destination. 114 Authentication does not solve this problem. Even if a node 115 unequivocally identifies itself, this has no bearing on its 116 rights to modify how packets to any given address are routed. 117 This is true even if its packets currently seem to emanate from 118 the address in question. This last point is obvious if one 119 considers DHCP leased addresses. It is imperative not to allow 120 any node to redirect traffic for a DHCP address for which it 121 held a valid lease previously. This would allow it to hijack 122 traffic meant for the current valid user of the address in 123 question. Hence, protection against hijacking of valid addresses 124 requires cryptographic authorization for operations that modify 125 routing (BU's, source routing, etc). One way to show 126 authorization is by showing that the requesting node owns the 127 address for which routing information is being altered. Quoting 128 [ADDROWN]: 130 Currently there exists no specified mechanism for proving 131 address ownership in Internet-wide scale. 133 This document proposes a solution to the address ownership 134 problem. 136 2.0 Terminology 138 This Section presents the notation used throughout this paper. 140 prf: 141 Pseudo-random function. SUCV mandates the use of the 142 HMAC-SHA-1 construct of the keyed hash function HMAC [HMAC] 143 which produces 160 bits of output. Input key is assumed 144 to also be 160 bits. 146 prfT: 147 Pseudo-random function whose output is truncated by taking 148 the T leftmost bits of the output. In SUCV, HMAC-SHA1 is 149 used, so prf96, for example, would be the keyed hash function 150 HMAC-SHA1-96 [RFC2404]. 152 hash: 153 Cryptographic hash function, SHA-1 [SHA1] for SUCV. 155 hashT: 156 Cryptographic hash function whose output is truncated by 157 taking the T leftmost bits of the output. 159 SUCV: 160 Statistical uniqueness and cryptographic verifiability, the 161 property exhibited by the identifiers and addresses which are 162 the subject of this study. We also use SUCV to refer to the 163 resultant mechanism as a whole. 165 sucvP: 166 The protocol developed here, whose objectives are proof of 167 address ownership and session key generation. 169 sucvID: 170 128 bit identifier obtained as the keyed hash output of the 171 hash of the public key, using an imprint value as the input 172 key. 174 sucvHID: 175 64 bit SUCV identifier used instead of the interface 176 identifier, and combined with the routing prefix to form an 177 autoconfigured IPv6 address [IPV6ADDR]. Obtained as the keyed 178 hash output of the hash of the public key, using an imprint 179 value as the input key. 181 MIPv6: 182 Mobile IPv6 [MIPv6]. 184 MN, HA, CN, BU, BA and CoA: 185 Abbreviations of mobile node, home agent, correspondent node, 186 binding update, binding acknowledgement and care-of address, 187 respectively, as defined by MIPv6 [MIPv6] 189 3.0 Overview of the Proposal 191 We assume that we have a network in which the nodes inherently 192 distrust each other, and in which a global or centralized PKI 193 (Public Key Infrastructure) or KDC (Key Distribution Center) is 194 not available. 196 The goal is to arrive at some fundamental assumptions about 197 trust on top of which one can build some useful peer-to-peer 198 communication using opportunistic security. 200 But in such a network, is there a default rule we can follow 201 safely? We posit this is it: 203 Default Trust Rule: 205 Redirect operations are allowed only with addresses which 206 are securely bound to the requesting entity. 208 The above rule (to be refined later) constitutes the only rule 209 that operates by default, allowing any other more dangerous 210 operation only if authorized by strong cryptographic 211 mechanisms. 213 4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV) 215 In the absence of a third party, how does a principal prove 216 ownership of its identity to a peer? 218 Notice that usual owner verification relies on a third party to 219 provide this function. 221 In this proposal, the principal self-generates a private/public 222 key pair. It uses material obtained via a prf based on the 223 public key as its identity (or as part of its address) and 224 proves its ownership by signing it with its private key. The 225 recipient verifies the signature, and, consequently, the 226 ownership of the identity. 228 4.1 SUCV ID's 230 It is much more practical for protocols to use fixed length 231 identifiers (representations of identities). Because of this, we 232 do not use the public key itself as the identifier, but material 233 obtained via a prf of the public key. 235 These identifiers have a strong cryptographic binding with their 236 public components (of their private-public keys). This is 237 exactly the purpose that certificates have. Let's call them 238 Statistically Unique Cryptographically Verifiable ID's, or SUCV 239 ID's. 241 Because of this, once a CN obtains information about one of 242 these identifiers, it has a strong cryptographic assurance about 243 which entity created it. Not only that, it knows that this 244 identifier is owned and used exclusively by only one node in the 245 universe: its peer in the current exchange. Thus, it is safe to 246 allow that peer to effect changes (via BU's, for example) on how 247 this address or identifier is routed to. Notice that with 248 publically routable addresses, this assurance is much harder to 249 arrive at, given that the address may be 'loaned' to (not owned 250 by) the peer in question, perhaps thanks to the good service of 251 a DHCP server. 253 Despite the fact that currently there is no way to prove address 254 ownership in the Internet, these considerations lead to the 255 following fundamental assumption: 257 Default Trust Rule 259 Redirect operations are only allowed to affect routing for 260 entities which have the SUCV property. 262 The above constitutes perhaps the only rule that operates by 263 default, allowing any other more dangerous operation only if 264 authorized by strong cryptographic mechanisms 266 What should one use: pure identifiers with no routing 267 significance or addresses? With pure identifiers, routing 268 information must be included somewhere else in the packet. This 269 takes up extra space in the packet via home address options, 270 routing headers or tunneling headers. 272 A major advantage to using an address is that the data traffic 273 need not carry extra information in the packet to guarantee 274 proper delivery by routing. Because of this it is useful 275 to create addresses that are routable and satisfy the SUCV 276 property: SUCV addresses. 278 4.3 SUCV Addresses 280 In IPv6, addresses that satisfy the SUCV property may be 281 obtained as follows (as it turns out, this is very similar to 282 and was predated by [CAM]): 284 - use the top 64 bits from your routing prefix (as in rfc3041) 286 - define the bottom 64 bits as an SUCV ID (called the sucvHID). 287 Use these 64 bits instead of the 'interface 288 identifier' in IPv6 [IPV6ADDR]. 290 The resultant 128 bit field is an identifier that is also 291 routable, avoiding the need to take extra space in the packet 292 (for example, by sending routing options or tunneling headers). 293 Notice that even after moving, it is possible to reuse the 294 'HID' portion of the address with the new network prefix at 295 the new location. Thus it is possible to reuse the HID with 296 different CoA's. 298 Nevertheless, by snooping on binding updates, it is possible for 299 an attacker to learn the original network prefix used by the 300 home address. This tells an eavesdropper where this home address 301 began to be used, and to which network it belongs, potentially 302 important information. 304 On the other hand, if you use a 'pure' SUCV ID (without any 305 routing significance), then your packets will always need extra 306 information somewhere else to assure they are routed properly. 307 Eavesdroppers may still know where that identity is at any 308 particular point in time. Nevertheless, from the point of view 309 of privacy this is a tangible improvement over always including 310 a valid 64 bit prefix, as this divulges information about an 311 identity's topological connectivity or under what prefix a 312 given identity began to be used. 314 4.4 SUCV Derivation and Formats 316 This section describes how to generate an SUCV ID (128 bits), an 317 SUCV HID (64 bits) and an SUCV address (128 bits). 319 First of all, the node generates a public/private key pair. 320 Then we define the required quantities as: 322 sucvID = hmac-sha-1-128(sha1(imprint), sha1(PK)) 323 sucvHID = hmac-sha-1-64(sha1(imprint), sha1(PK)) 325 Where, imprint is a 64 bit field: 327 It could be a quantity that depends on the MN's location or 328 something created by the MN itself (a random value, for 329 example). The objective is to use the imprint to limit 330 certain types of brute-force attacks by limiting their 331 applicability, or by forcing interaction with the MN. 333 PK: The public key is the DSA public key. 335 Note that according to [IPV6ADDR], the leftmost 3 bits of 336 the sucvID can be used to unequivocally distinguish them from 337 IPv6 addresses. Accordingly, we assume only 125 bits may be 338 used. Additionally, bit 6 of the sucvHID (the universal/local) 339 has to be set to zero to indicate that the sucvHID is not 340 guaranteed to be globally unique. 342 5.0 SUCV Protocol (sucvP) Overview 344 The following protocol, sucvP, is run between a MN and an 345 arbitrary CN. It is used: 347 - by the MN to prove ownership of its home address and 348 optionally of its CoA, 350 - to establish an IPsec ESP security association (Skey, 351 Lifetime, SPI) between the MN and the CN that will be 352 used to secure MIPv6 BU's, and, 354 - optionally, by the CN to prove ownership of its identifier 355 or address (only if the CN itself uses an SUCV identifier 356 or address). 358 Of course, the obtained security association (SA) could also be 359 used for any other application of ESP. However, in the basic 360 sucvP exchange, only the MN performs proof of ownership. 361 The section on Risks outlines the dangers this implies. 362 Accordingly, general ESP usage should be limited to the 363 extended sucvP exchange in which, in addition to the MN, 364 the CN also uses SUCV for proof of ownership. 366 As for the choice of using AH or ESP to protect the binding 367 updates, we chose the latter. Given the benefits of integrity 368 and data origin authentication inherent in the proof of 369 ownership, we believe there is no added value in using AH to 370 protect the IP headers of BU's once a security association has 371 been established. This and the heated debate on the future of 372 AH convinced us to use ESP. 374 sucvP is functionally independent of MIPv6, and is, in fact, 375 a separate protocol. sucvP's proof of ownership provides the 376 authorization for the MIPv6 BU's, but the authentication is 377 provided by IPsec ESP. These are two separate steps which could 378 run serially. For example, the sucvP step could be carried out 379 over UDP (as our initial experimental implementation does), 380 after which the ESP-authenticated BU could be sent. 382 However for efficiency reasons, sucvP messages might contain 383 MIPv6 BU's (along with sucvP3). 385 In order for sucvP to set up an IPsec security association 386 (including an SPI) just in time to process an ESP header and 387 its encapsulated BU, the sucvP payload is carried as an IP 388 protocol number (currently unassigned). Furthermore, it must 389 precede the ESP payload used to authenticate the binding update. 391 5.1 Goals and Constraints 393 This design allows sucvP to satisfy these two objectives: 395 - not affect existing IPsec implementations more than 396 absolutely necessary 398 - support efficient BU processing by reducing as much as 399 possible the number of round trips. 401 Furthermore, we assume there is no piggybacking with the BU, 402 so no further payload follows. 404 sucvP has been designed based on the following considerations: 406 - the protocol should not rely on a third party (i.e. a 407 global PKI, central key distribution center, etc), although 408 it could use one if available 410 - not all nodes need to use SUCV addresses, only those that 411 wish their binding updates to be heeded (mobile nodes) 413 - not all nodes need to verify the validity of SUCV 414 addresses, only those CN's that accept and handle binding 415 updates from MN's (these CN's must use SUCV as explained 416 below to safely populate their binding caches) 418 sucvP packets are exchanged directly between the mobile node and 419 its correspondent nodes. They are not routed through the Home 420 agent because the mobile node might be homeless or the home 421 agent might be out of order for a certain period of time. The 422 implications for this decision are explored below. 424 5.2 Packet Exchanges 426 The proposed protocol that a mobile host uses to send a BU to 427 its CN is the following: 429 sucvP1: 430 The MN sends a sucvP1 message (just to initiate the exchange) 431 to its correspondent node. This message contains a Nonce, 432 N1. This packet may contain a MIP HomeAddress Option 433 containing the MN's home address. The CN might sometimes need 434 the home address to decide whether it wants to pursue the 435 protocol exchange or not. The source address of the packet is 436 the MN's current CoA. Additionally, SUCV supports a very 437 simple negotiation mechanism that works as follows: 438 Optionally, the MN can express its desire to use certain 439 Diffie-Hellman groups (for the ephemeral DH exchange), as 440 well as algorithms for ESP authentication and for ESP 441 encryption. 443 sucvP2: 444 The CN replies with a sucvP2 message that contains the 445 following: N1, Client puzzle request, Diffie-Hellman value 446 (g^y mod p), Session_Key_lifetime. The CN may respond to any 447 optional parameter negotiation included by the MN in sucvP1, 448 by choosing those algorithms it wishes to support. 450 In order to defend against sucvP1 storms, a host might use 451 the same Diffie-Hellman (DH) value for a period of time. The 452 sucvP2 contains a client puzzle to prevent DoS attacks 453 PUZZLES. Along these line, the CN may wish to ignore the 454 optional negotiation of parameters initiated by the MN in 455 sucvP1. In this case, the default algorithms (see below) must 456 be used by both parties. 458 When the MN receives sucvP2, it verifies that the nonce N1 is 459 the same as what was sent in sucvP1. It then solves the 460 puzzle. At this stage of the protocol, the MN: 462 1. generates a DH value (g^x mod p) and derives from it and 463 the DH received from the CN the session keys. 465 2. computes skey_espauth (the ESP session key used to 466 authenticate the MIPv6 binding update lifetime as the 467 minimum of the lifetime value suggested by the CN and its 468 lifetime value. 470 3. builds an IPsec SA. If ESP is used subsequently in the 471 packet to secure a Binding Update, the MN must use a fixed 472 SPI assigned from the range 1 to 255 (currently 473 unassigned). 475 4. sends a sucvP3 packet. Note that this message is sent 476 directly from the MN's CoA to the CN. 478 sucvP3: 479 A sucvP3 message contains the following fields: Puzzle reply, 480 Public key and imprint it has used to generate its HID, a 481 Diffie-Hellman value, the skey_espauth lifetime and an SPI 482 for the CN to use when sending BA's (secured via ESP) to the 483 MN. This message must be signed by the MN with its private 484 key (the public key is used to generate the HID). 486 Note that this sucvP3 might be followed by an ESP header 487 authenticating an encapsulated BU. The authentication is 488 performed using the SA available inline within this sucvP3 489 packet. 491 When the CN receives the sucvP3, it first checks for a valid 492 Puzzle reply. It verifies the signature using the included 493 Public key, and then verifies that this Public key and 494 imprint produce the sucvHID used as part of the sender's 495 address. The CN can then conclude that the MN owns its the 496 Home and CoA addresses. 498 At this point, the CN makes a note of this Public key and 499 HID. 501 The CN can then compute the session keys (using the ephemeral 502 DH value). From the fixed SPI, the CN learns that the 503 security association material is all inline in sucvP3. It 504 proceeds to build an IPsec SA and processes this ESP header. 505 In preparation for subsequent ESP processing of BU's, it 506 computes an SPI and sends it in sucvP4. After this point, and 507 thanks to this SPI, IPsec usage reverts to normal, i.e., 508 future BU's can be secured via ESP, unaccompanied by any 509 inline sucvP material. 511 sucvP4: 512 In sucvP4, the CN sends an SPI. The MN will use this SPI in 513 association with ESP in order to authenticate subsequent 514 BU's. The CN authenticates sucvP4 with HMAC-SHA1 using the 515 Session key Skey_sucv derived previously. Additionally, a CN 516 that uses an SUCV address could sign sucvP4 instead. This 517 possibility is explored below. 519 A CN may include a BA (binding acknowledgement) along with 520 sucvP4, and if so, it must use ESP for authentication. The 521 SPI used is that communicated by the MN in sucvP3. When the 522 MN receives a sucvP4, it must make note of the SPI 523 corresponding to the CN. 525 As long as the MN uses the same HID interface identifier for 526 its CoA, it does not have to prove the CoA ownership and BU 527 authentication is enough. 529 Proving the CoA ownership can be very useful to prevent a 530 malicious host from bombing a victim with packets by using 531 the victim's address as CoA. For example, with ``regular'' 532 Mobile IPv6, a host can initiate a large stream transmission 533 from a server, and then send a BU with the victim's address 534 as CoA to the server. As a result, the stream will bombard 535 the victim. If a host can prove that it owns its CoA, and 536 that therefore it is not using another node's address as CoA, 537 this attack can be avoided. However, this does not protect 538 against a related attack in which the objective is not to 539 bombard a particular host, but any given network prefix or link. 541 If for any reason the MN configures its CoA with a new interface 542 identifier, it must restart the whole protocol sequence. 544 5.3 Deriving the Session Keys 546 We need to generate keying material and keys for the SUCV 547 protocol itself and for use with ESP. 549 skeymat = prf(hash (g^{xy} mod p), N1 | imprint) 551 Where N1 is the nonce used in sucvP1 and sucvP2. 553 5.3.1 SUCV Session Key 555 skey_sucv = prf(skeymat, g^{xy} mod p | N1 | imprint | 0) 557 Used with sucvP4 for: authentication, and optionally with sucvP5 558 (see Section on Privacy Considerations) for both authentication 559 and encryption. 561 5.3.2 Key for use with ESP 563 skeymat_espauth = prf(skeymat, skey_sucv | g^{xy} mod p | N1 | 564 imprint | 1) 566 Used to authenticate BU's unaccompanied by SUCV packets (once 567 sucvP is completed) as well as other applications of ESP 568 (subject to the warning at the beginning of Section 5). 570 Note that whereas skey_sucv is the actual key used by the 571 SUCV protocol, skeymat_espauth is keying material used to 572 derive the real key for use with ESP, i.e. skey_espauth in an 573 algorithm-specific manner. 575 5.4 Default Algorithms 577 The following algorithms must be supported by any SUCV 578 implementation: 580 DSA [DSA] for signing sucvP3. 582 Diffie-Hellman Oakley Group 1 [RFC2412] for the ephemeral 583 Diffie-Hellman exchange. 585 HMAC-SHA-1-96 [RFC2404] for ESP authentication. 587 3DES-CBC [RFC2451] for sucvP5 and ESP encryption. 589 6.0 Extension for Constrained Devices 591 In our sucvP protocol, a MN must: 593 - generate a DSA public/private key pair. 595 - sign the sucvP3 message. 597 - perform a DH exponentiation to derive the Skey. 599 All these operations are computativally expensive especially 600 if the MN is a constrained device (i.e. a PDA or a sensor 601 with limited memory, battery or CPU). Elliptic curve 602 cryptographic algorithms might be more efficient but still 603 too expensive to execute for a constrained device. 605 In this section, we propose an extension to our scheme for 606 this type of contrained devices. Our goal is to off-load most 607 of the expensive cryptographic operations of a MN to its HA. 608 We assume that the MN and HA share a secret key, and that the 609 MN trusts its HA. 611 The proposed extension operates as follows: 613 1. The HA generates the DSA keys (public and private keys) 614 and sends the public Key to the MN via the secured channel. 616 2. The SUCV id and HID is generated by the MN itself by choosing 617 a k and computing sucvHID = prf64(hash(publicKey), k). 619 3. When a MN wants to initiate a sucvP exchange with CN, it 620 sends a SUCV_request messages, that contains the CN address 621 and the k value, to its HA (authenticated with the shared 622 key). The HA then initiates a sucvP exchange with the CN. The 623 HA then proves that it knows the private key corresponding 624 to the public by signing the exchanged messages (sucvP has 625 to be slightly modified here) and generates a session key, 626 SKey using the DH algorithm. 628 4. The HA then sends the Skey to the MN via the secure channel. 630 5. The MN can then send authentication BU's to the CN using 631 the SKey. 633 With this extension all the expensive cryptographic operations 634 are offloaded to the home agent but the session key that is 635 used to authenticated the MIPv6 BU (Skey) is only known to 636 the MN, its HA and the CN. A malicious host that wants to 637 redirect a MN's traffic needs either to discover the HA-MN 638 secret key or to find a public key/private key pair and a k' 639 such that 641 sucvHID = prf64(hash(public), k') 643 Both are very difficult to achieve. 645 7.0 Privacy Considerations 647 A normal sucvP exchange consists of sucvP1 through sucvP3, 648 and a subsequent sucvP4 authenticated using the session key. 649 This basic protocol does not allow any hijacking attacks, so 650 it already fulfills the security requirements for protecting 651 BU's in MIPv6 as defined by the Mobile IP working group 652 [MIPv6SecReq]. 654 7.1 Support for Random Addresses [RFC3041] 656 A first concern regarding privacy is how to use random 657 addresses as defined in RFC3041 in a mobile environment. 658 The issue here is that, whereas these addresses hide a node's 659 permanent identifier (perhaps derived from IEEE addresses), 660 the node cannot prove address ownership of them so it cannot 661 safely send binding updates. This means that an MN cannot use 662 RFC3041 addresses with route optimization. SUCV addresses 663 are indistinguishable from those defined in RFC3041, with the 664 added benefit that an MN can use them in a route optimized 665 fashion. The basic sucvP outlined above already handles this 666 case. The only consideration is that nodes interested in being 667 anonymous may want to use ephemeral SUCV identifiers (as opposed 668 to more permanent or longer-lived SUCV ID's) for this purpose. 670 Furthermore, if nodes wish to have higher protection against 671 attackers than what is afforded by 63 bits in the sucvAddr, 672 they can use an sucvID. The protocol exchange is the same, but 673 since an sucvID is a pure identifier, as shown below, routing 674 information must be included somewhere else in the packet, 675 via home address options and routing headers (alternatively, 676 tunneling headers could be used as well). This poses no 677 difficulty if the MN operates as a client, always initiating 678 contact with the CN, but would otherwise require mechanisms 679 beyond the scope of this paper. 681 7.2 Support for Confidentiality 683 7.2.1 Confidentiality 685 If confidentiality is a concern, there is the possibility of 686 an intruder in the middle gaining knowledge of the session keys, 687 as explained in the section on Security Analysis. In fact, 688 sucvP prevents an intruder from impersonating an mobile node 689 but not from impersonating a correspondent node. As a result, 690 an MN might think that it is talking with its CN whereas it 691 is actually talking with an intruder. The MN may wish to 692 make sure it is indeed talking to a given CN whose address 693 it has previously obtained (via, for example, a DNS search, 694 or a preconfigured list). If in addition to the MN, the CN 695 also uses an SUCV address this problem can be prevented. We 696 suggest that a CN uses a SUCV address when confidentiality 697 is an issue and that the CN sign sucvP4 to prove its address 698 ownership. By doing so, both MN and CN have the assurance that 699 they are talking to each other and not to an intruder. 701 7.2.2 Location Privacy 703 In Mobile IPv6: 705 Each packet (BU and data) sent by a MN contains a 706 HomeAddress option that reveals the MN's home address. 708 Each packet sent to a MN contains a routing header with 709 the MN's home address. 711 As a result it is very easy for any host in the network to track 712 the location of a MN by snooping its packets. If location 713 privacy is an issue, a MN can use an ephemeral home address 714 sucvADDR_ephem instead of its real one (sucvADDR), and only 715 reveal the latter to its CN. Packets (BU and data) sent over the 716 network then use the ephemeral home address sucvADDR_ephem. 718 For this to work, the MN will need an ephemeral SUCV identity 719 sucvID_ephem, and defer revealing its more permanent SUCV 720 identity sucvID after the CN has proven ownership of its 721 address. This is accomplished roughly via the following extended 722 protocol sequence: 724 sucvP1: as usual 726 sucvP2: the CN adds a bit to advertise its SUCV capabilities 728 sucvP3: the MN proves ownership of its sucvADDR_ephem (derived 729 from an ephemeral public-private key. At this point, 730 the MN derives session keys but is not yet sure it 731 is sharing them with the CN itself. 733 sucvP4: the CN proves ownership of its SUCV address by signing 734 sucvP4 with its private key, at which point the MN 735 knows the session keys have not been compromised by 736 an intermediary. 738 sucvP5: the MN uses the session key obtained above to send an 739 encrypted payload revealing its actual SUCV Home Address 740 sucvADDR. sucvP5 must be signed with the key used to 741 generate the sucvADDR in order to prove its ownership. 743 Notice that if the MN wishes to use the stronger mode, it can do 744 so by using an sucvID_ephem and sucvID instead of sucvADDR_ephem 745 and sucvAddr, respectively. As in the discussion above, 746 this provides for more protection against attackers, with 747 the proviso, in practice, the MN may be limited to being a 748 client. That is, it must initiate communication with the CN, 749 because it is now using non-routable entities (SUCV ID's versus 750 SUCV Addresses). 752 8.0 Security Analysis 754 This section includes a security analysis of the SUCV protocol. 756 8.1 Hash ID Size Considerations 758 In SUCV addresses, one of the lower 64 bits is reserved as the 759 local/universal bit (the u bit), so only 63 bits are actually 760 usable as a hash. 762 Suppose the hash function produces an n-bit long output. If we 763 are trying to find some input which will produce some target 764 output value y, then since each output is equally likely we 765 expect to have to try 2^{(n-1) possible input values on average. 767 On the other hand, if we are worried about naturally ocurring 768 SUCV address duplications, then by the birthday paradox we 769 would expect that after trying 1.2*2^n/2 possible input values 770 we would have a 50% probability of collision [HandBook]. 772 So if n=63, you need a population of 1.2*2^{31.5} i.e. 3.64*10^9 773 nodes on average before any two produce duplicate addresses. 774 This is acceptable especially if you consider that this 775 collision is actually harmfull only if the 2 hosts (that 776 collide) are in the same site (i.e. they have the same 64 777 bit prefix), and have the same correspondent nodes. This is 778 very unlikely. Additionally, assuming the collision is not 779 deliberate the duplicate address detection (DAD) will detect it. 781 If an attacker wishes to impersonate a given SUCV address, 782 it must attempt 2^{62} (i.e. approximately 4.8*10^{18}) 783 tries to find a public key that hashes to this SUCV address. 784 If the attacker can do 1 million hashes per second it will need 785 142,235 years. If the attacker can hash 1 billion hashes per 786 second it will still need 142 years. 788 If we use SUCV Addresses as suggested in RFC3041 (perhaps 789 renewing them as often as once every 24 hours), an attacker 790 would then have to to hash 5.3*10^{13} hashes/second in order 791 to be able to find a public key that hashes to the sucvHID of 792 a given host. 794 Note that the previous analysis only considers the cost of 795 computing the hash of the public key. Additionally, an attacker 796 must also generate a valid (public, private) key pair. This is 797 a significantly more expensive operation. 799 This would still leave open the possibility of brute-force 800 attacks. In this scenario, a bad guy, BG, could generate a huge 801 table of PK's and their corresponding HID's, assuming any fixed 802 imprint. It could then look for matching real IP addresses. 803 By doing so it would identify a victim for a hijacking attack. 804 BG can send a BU to any CN without a binding entry for the 805 victim's address (for example, by targetting non-mobile fixed 806 hosts as victims). 808 In general, such attacks are possible with hash functions, but 809 not with keyed hash functions because they require interacting 810 with the legitimate user [HMAC]. Notice that normal usage of 811 keyed hash functions requires an authenticated secret, which 812 we do not have. Nevertheless, we can still limit exposure by 813 creating the HID (or ID) using (in addition to the Public key) 814 some key or known state that is established in advance of the 815 sucvP interaction itself, and which will force interaction 816 with the MN. 818 This is the role of the imprint, sent by the MN to the CN in 819 sucvP. Since the imprint is not authenticated, the CN could 820 verify it independently of sucvP, perhaps by checking directly 821 with the MN by routing it via the HA. True, the imprint 822 is not a secret as expected for HMAC use, but it serves to 823 severely limit which entities can launch the attack to only 824 those entities with this priviledged location, and within this 825 time period. 827 As another possibility, the imprint may instead be a quantity 828 which the CN knows about the MN, and which the CN can verify 829 independently using a separate subsystem (DNS, routing fabric, 830 etc). In this case, the attack is limited to only those nodes 831 for which the imprint is also a valid quantity. However, tying 832 the HID in this manner may have undesirable consequences with 833 regards to privacy and location independence (for example 834 homeless operation). 836 Alternatively, one could always use sucvID's (in which case 837 the brute-force attacks would be nearly impossible). 839 Even for HID's, actually carrying out such brute-force 840 attacks remain highly unlikely in practice, and we claim our 841 scheme remains secure even without requiring any of the above 842 counter-measures. 844 8.2 Key size considerations 846 There are three ways that an attacker could break the MIPv6 847 security protocol presented in the paper: 849 1. If an attacker find a DSA public/private key pair that hashes 850 to the MN's sucvID, it can run a sucvP exchange with a CN 851 and impersonate the MN. This can be achieved by a brute 852 force attack. The attacker tries several public keys as 853 input to the hash function used to generate the sucvID. 854 The difficulty of this attack depends on the size of the 855 sucvID and is at least as hard as breaking a symmetric key 856 algorithm that uses the same key size as the sucvID size 857 (actually this is more difficult because the attacker 858 must also generate valid public/private key pairs before 859 performing the hash function). 861 2. If an attacker can find the public/private key pair that 862 is used to generate the sucvId and sign sucvP3, an attacker 863 can impersonate a MN in sucvP. Breaking a DSA system depends 864 on the DSA modulus and subgroup. 866 3. If an attacker can retrieve the generated session key it can 867 send fake BU's on behalf of the MN and redirect its traffic. 868 An attacker has two ways of retrieving the session key: 869 (1) generate it from the DH values exchanged between the 870 MN and the CN, or (2) perform a brute-force attack on the 871 session key itself. The difficulty of these attacks depend 872 respectively on the DH modulus size and the session Key size. 874 A security system is consistent if all the components of the 875 security chain provide the same security levels and none of 876 them is a weak link. Most of the security parameters used in 877 our proposal (DH modulus size, Session key size, DSA subgroup) 878 can be adjusted. The only fixed parameter is the SUCV identifier 879 itself. It is either 63 bits long (i.e. we use an sucvHID) 880 or 125 bits long (if using an sucvID itself). 882 If we use sucvHID's, the security of our proposal depends on 883 these 63 bits. Accordingly, the symmetric key strength should 884 not be less, not would we gain much by it being significantly 885 stronger. In light of [DetStrengths], Oakley group 1 is about 886 enough for this application (although there are other more 887 conservative views [lenstra00selecting]). 889 However, if we use suvcID's, we will need a symmetric key 890 strength of almost 128 bits (125 bits) of output from our 891 prf. Notice that 96 bits symmetric keys are generally considered 892 safe for another 20 years or so. However, if we want to keep up 893 with the strength afforded by the sucvID itself, we would need 894 to use other MODP groups [MODPGrp]. For example, MODP group 5 895 with exponents of 1563 bits should be enough to derive 90 bit 896 symmetric keys. MODP group 6 with 2048 bits should be used to 897 produce 100 bit symmetric keys. 899 8.3 Intruder-in-the-middle attacks 901 As described above, a mobile node and its correspondent node 902 derive a shared (symetric) key to authenticate the MIPv6 903 Binding updates sent by the MN. 905 The MN and its CN derive the shared key using the Diffie-Hellman 906 algorithm. 908 The CN chooses a random secret y and sends g^y mod p to 909 the MN (in the DH value field of sucvP2) 911 The MN chooses a random secret x and sends g^x mod p to 912 its CN (in the DH value field sucvP3) 914 The session key shared by the MN and its CN is then a hash 915 digest of g^{xy} mod p (g and p are known by the MN and CN). 917 8.3.1 Summary of the Attack 919 Diffie Hellman is know to be vulnerable to the 920 intruder-in-the-middle attack on un-authenticated DH key 921 agreement: 923 CN -->g^y-->Intruder-->g^y_i-->MN 924 CN<--g^x_i-->Intruder<--g^x<--MN 926 The intruder intercepts g^y sent by the CN and sends g^{y_i} 927 to the MN. The intruder also intercepts g^x sent by the MN 928 and sends g^x_i to the CN. As a result, MN shares the key 929 g^{xy_i} with the intruder (it actually thinks that it is 930 sharing this key with its CN). The CN shares the key g^{x_iy} 931 with the intruder (it actually thinks that it is sharing this 932 key with the MN). The Intruder can then impersonate the MN 933 and the CN. 935 In our protocol, the MN signs sucvP3 (which contains g^x). 936 As a result, the intruder can not modify nor replace this 937 message. This only thing that the intruder could do is the 938 following attack: 940 sucvP1: CN<--HID'-->Intruder<--HID<--MN 941 sucvP2: CN-->g^y-->Intruder-->g^yi-->MN 942 sucvP3: CN<--g^xi-->Intruder<--g^x<--MN 944 In sucvP1, MN sends its HID by virtue of sending from its 945 address (the HID is just the bottom 64 bits in the address). The 946 intruder could replace this HID by another value, say HID_i, 947 without affecting return routability, as long as the prefix 948 remains the same. In sucvP2, the CN sends its DH value g^y, 949 which is replaced by the intruder for g^{y_i}. In sucvP3, the 950 MN sends its g^x. Notice that the intruder can replace it by 951 another g^{x_i} as long as this {g^x_i} is used to create HID_i. 953 8.3.2 Risks 955 The keys created are derived from: 957 g^{xy_i} (between the MN and the intruder) and 959 g^{yx_i} (between the intruder and the CN). 961 So the intruder cannot pass itself off as MN (assuming it is 962 computationally unfeasible to find another private-public pair 963 that generates the same HID). It can, however, pass itself off 964 as MN_i, where this is the address formed from HID_i. This means 965 that it is not possible for an intruder to hijack an existing 966 communication between MN and CN. But if the intruder is present 967 at the very beginning of the communication, and if it sits 968 on the path it could supplant MN. In so doing it could obtain 969 knowledge of any session keys derived for this communication. 971 If the session supported encryption, the endpoints might be led 972 to believe in the privacy of their conversation, oblivious to 973 the fact that the intruder could snoop. For example, suppose 974 an MN established an sucvP session with an CN. Subsequently, 975 and using this optimized path, an application (for example 976 telnet) started. If a security policy database required all 977 such application traffic to be encrypted, a misconfigured 978 system might leverage the existing sucvP session and use ESP 979 for confidentiality. This would result in the intermediary 980 being privy to all the application traffic. 982 Because of this, sucvP session keys must not be used for 983 anything more than securing BU's. In other words, IPsec 984 traffic selectors in the SPD must limit use of SA's obtained 985 via sucvP for the sole purpose of securing BU's. In order to 986 avoid any potential misapplication of these SA's BU's must 987 not be piggybacked. 989 Not heeding the above guidelines may result in the 990 aforementioned snooping attack. Nevertheless, the attacker would 991 have to remain on the path forever. This interception is 992 possible because of the non-authenticated nature of the 993 example. Of course, if the exchange is authenticated, this 994 would not be possible. Even if this interception is possible, 995 once the intruder ceases to be on the path between MN and CN 996 there is nothing further it can do. In other words, the use of 997 unauthenticated SUCV entities does not add any risk to those 998 that currently exist. Even unauthenticated SUCV, eliminates the 999 possibility of on the path redirection of traffic. Notice that 1000 with current MIPv6, ``off the path'' (as well as ``on the 1001 path'') redirection of traffic is possible. 1003 In some case, a MN might request to its CN to acknowledge the 1004 reception of the BU. The intruder could actually fool the MN 1005 by sending an acknowledgement with the CN address as source 1006 address (note that the intruder could also authenticate this 1007 acknowlegement since it knows the key used by the MN, g^{xy}). 1008 This might confuse the MN that has received an acknowledgement 1009 but keeps receiving the packets from the CN via its home agent 1010 (note that the same problem exists also will current Mobile 1011 IPv6 specification)! 1013 One solution to these problems is for the the CN to use an 1014 SUCV address and to sign sucvP2 (the message that contains the 1015 DH value). Then, the intruder will not be able to substitute 1016 g^y by g^{y_i}. 1018 Of course, the intruder can hinder successful completion 1019 of the SUCV protocol, thus preventing the CN from heeding 1020 the MN's BU using route optimization to the MN. In effect, 1021 this is a denial-of-service attack against route optimization, 1022 and it leads to service degradation not disruption. 1024 The previous security analysis shows that sucvP prevents any 1025 intruders from redirecting the traffic addressed to a mobile 1026 host's home address and consequently provides the minimal 1027 Mobile IP security requirement [MIPv6SecReq]. 1029 8.3.3 Why not Route sucvP2 Through the Home Agent? 1031 What, if we assume sucvP1 was carried with a home address 1032 option, and then sucvP2 travelled via the home agent. At 1033 this point, the home agent can check that the validity of 1034 this MN_i (corresponding to HID_i), its current care-of 1035 address, etc. In this case, none of the above snooping would be 1036 possible. In order to further mitigate the sucvP2 packet from 1037 being redirected, the MN must check upon its reception that it 1038 was sent tunneled by its home agent. Home address options can 1039 be misused to set up distributed denial of service attacks 1040 whereby these options are sent to numerous hosts prompting 1041 them all to respond to the same address. Even if CN's exercise 1042 caution when sending their sucvP2 packets as instructed via a 1043 home address option, the nature of DDoS attacks is such that 1044 any given CN may not send more than a few sucvP2's to the same 1045 home address region (same prefix), the collection of thousands 1046 of such responses may be sufficient to clog a target network. 1048 The above analysis shows the pro's and cons of using the home 1049 address option. Notice that for our purpose of authenticating 1050 BU's we do not need to resort to the heavy requirement of 1051 routing sucvP2 via the HA. SUCV packets are exchanged directly 1052 between the MN and the CN. 1054 8.4 Denial-of-Service Attacks 1056 Denial-of-service (DOS) attacks that exhaust a host resource 1057 (memory and computional resources) is a major security threat 1058 on the Internet. In this section we study the behavior of 1059 the sucvP against DoS attacks. 1061 sucvP1 storm: 1063 Malicious hosts, could try to attack a host, by sending a 1064 storm of sucvP1 messages. We prevent this potential attack 1065 as follows: 1067 1. When receiving a sucvP1, a host does not create any 1068 state and replies with a constant message (sucvP2) 1069 that contains a client puzzle [PUZZLES]. 1071 2. An host only creates state if it receives a valid puzzle 1072 reply to its puzzle request (in sucvP3). 1074 sucvP2 storm: 1076 Malicious host could try to attack a host by sending a storm 1077 of sucvP2 messages. We prevent this attack by inserting 1078 a nonce, N1, in the sucvP1. If a host receives a sucvP2 1079 with a nonce N1 that is not equal to the nonce N1 that it 1080 has set in the initial sucvP1, this sucvP2 must be rejected. 1082 Note that an intruder (between the MN and its CN) could 1083 intercept the sucvP1 and reply to the MN with a fake sucvP2 1084 containing a valid N1 and an intentionally difficult puzzle 1085 request. The MN would then spend a lot of CPU and power 1086 computing the puzzle reply. This attack can be avoided 1087 if the MN had a mean to authenticate the address used by 1088 its CN. One solution is that the CN uses a SUCV address 1089 and signs sucvP2. 1091 Instead of this heavy alternative, we suggest that a MN 1092 simply reject any sucvP2 messages that contain an overly 1093 complex client puzzle request Of course, the MN itself 1094 defines the complexity threshold of the puzzle request as 1095 a function of its processing power. 1097 As a result, the attack that consists of sending complex 1098 puzzles (in sucvP2) to a MN, in order to exhaust its 1099 computing resources, will not be sucessful, because the 1100 MN will drop the sucvP2. The MN service will be degraded 1101 (because its incoming packets will then be routed through 1102 its home agent) but not disrupted.} 1104 sucvP3 storm: 1106 Malicious hosts could try to attack a host by sending a storm 1107 of sucvP3 messages. We prevent this attack by using a client 1108 puzzle. A host accepts a sucvP3 message only after verifying 1109 that the puzzle reply (contained in the sucvP3) is valid.} 1111 9.0 Security Considerations 1113 The technique introduced in this document is meant to increase 1114 the level of security in the Internet. 1116 This document explains the concept of statistical uniqueness 1117 and cryptographic verifiability (SUCV), specially as it 1118 applies to IPv6 addresses in the form of SUCV addresses. The 1119 SUCV characteristics are used to prove address ownership, thus 1120 preventing a class of attacks which exploit this fault in many 1121 types of commands. In particular, commands which alter how an 1122 address is treated by peers or by the routing infrastructure 1123 can be used to launch denial of service attacks or hijacking 1124 attacks. Proving address ownership eliminates these attacks. 1125 However, given that this technique is meant to be used primarily 1126 in the absence of global infrastructures, the possibility of 1127 man in the middle attacks does remain. Nevertheless, these 1128 attacks are limited by the use of cookies and client puzzles. 1130 10.0 Conclusions 1132 The present document focuses on the use of the SUCV property to 1133 enhance the security of exchanges between an arbitrary pair of 1134 peers in the absence of any third party. In particular, we 1135 propose that SUCV addresses be used to solve the issue of 1136 securing binding updates in Mobile IPv6. 1138 11.0 Acknowledgements 1140 The authors appreciate the helpful comments received from the 1141 following individuals: Erik Nordmark, Alberto Escudero, Lars 1142 Henrik Petander, Imad Aad, Pars Mutaf and the anonymous 1143 reviewers. Special thanks to Julien Laganier for his sundry 1144 comments and major contribution to the packet formats. 1146 A. Appendix: sucvP Protocol Specification and Packet Formats 1148 SUCV uses a very simple negotiation. First of all, hopefully no 1149 negotiation of cryptographic parameters is necessary, as the 1150 defaults should be applicable. Any departure from the default 1151 is proposed by the initiator using TLV encoding and either 1152 accepted (and used) or rejected by the responder. 1154 Furthermore, SUCV deals with cryptographic suites, similar to 1155 TLS and JFK [JFK] usage. 1157 The initial set of algorithms that MUST be supported is: 1159 Suite Identifier 1160 ======================================= ========== 1161 SUCV_RSA_WITH_ESP_AES_128_CBC_HMAC_SHA1 {0x00,0x01} 1162 SUCV_RSA_WITH_ESP_3DES_CBC_HMAC_SHA1 {0x00,0x02} 1163 SUCV_RSA_WITH_ESP_NULL_HMAC_SHA1 {0x00,0x03} 1165 Notice that SUCV only supports RSA certificates, ESP headers 1166 and SHA1. These are repeated in the names of the suites above 1167 for clarity, not to imply that departures are allowed (to DSS, 1168 AH or MD5, for example). 1170 The default suite that requires no negotiation is: 1172 SUCV_RSA_WITH_ESP_AES_128_CBC_HMAC_SHA1 1174 This suite has been assigned an identifier, but the identifier 1175 will never be used in an SUCV payload because fixed payloads are 1176 enough to support the default case. As compared to IKEv2 1177 [IKEv2], SUCV does not allow individualized negotiation for 1178 tranform types 1 (encryption algorithm), 2 (pseudo-random 1179 function), 3 (authentication type) and 4 (integrity algorithm). 1180 By using the above default suite, SUCV mandates the following: 1181 AES_128_CBC for encryption, HMAC_SHA1 for pseudo-random 1182 function, RSA for authentication type and SHA1 for integrity 1183 algorithm. 1185 It does, however, allow for negotiation on Diffie-Hellman group 1186 (IKEv2's transform type 5). In so doing it reuses the numbering 1187 used in IKEv2. The mandatory group for Diffie-Hellman exchange 1188 is group 5 (1536 bit MODP) and RSA signature uses exponent 1189 65537. 1191 A.1. Packet Formats 1193 sucvP is an IPv6 protocol, identified by protocol number (sucvP 1194 TBD by IANA) in the Next Header field of the immediately 1195 preceding header. 1197 The Next Header field identifies the next protocol in the 1198 IPv6 daisy-chain header as per normal IPv6 usage. 1200 The Version field for this version of sucvP MUST always contain 1201 the number 1. 1203 The Length field indicate the length in bytes of the whole sucvP 1204 header, including any possible options. 1206 The Checksum is the 16-bit one's complement of the one's 1207 complement sum of the entire sucvP message starting with the 1208 Next Header field (see below), prepended with a "pseudo-header" 1209 of IPv6 header fields, as specified in [IPv6, section 8.1]. The 1210 Next Header value used in the pseudo-header is (sucvP TBD). 1212 For computing the checksum, the checksum field is set to zero. 1214 The Packet Type is defined to be {packet number|sequence type}; 1215 the packet number is related to the relative position within the 1216 exchange, while the sequence type is related to the sort of SUCV 1217 exchange we wish to perform. For example, an sucvP3 packet used 1218 to establish initiator's proof of ownership without privacy 1219 considerations would be labeled with the packet type 1220 {0x03|0x01}. It would be labeled {0x03|0x02} if it is used to 1221 establish mutual proof of ownership or to avoid disclosure of 1222 identity. On the other hand, an sucvP1 packet would always be 1223 labeled {0x01|0x01}, as there is only one type of p1 in both 1224 exchange types {initiator|responder|privacy}. 1226 A.2. Common Header Format 1228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Next Header | Version | Length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Packet Type | Checksum | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Initiator Nonce / Transaction ID? | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Depends of SUCV Packet Type... 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1239 A.3. Cookie Puzzle Request Format 1241 Level of Difficulty is k 1243 Responder's Nonce is Nr 1245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Level of Difficulty | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Responder's Nonce | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 A.4. Cookie Puzzle Reply Format 1254 Initiator's Nonce is Ni 1256 Puzzle's Solution is an integer X which verifies the property : 1258 +------------------------------------+ 1259 | | 1260 | hash(Ni|Nr)=000....000......... | 1261 | ___ ___/ | 1262 | / | 1263 | k leftmost bits | 1264 | | 1265 | ________ ________/ | 1266 | / | 1267 | 160 bits of SHA1's output | 1268 | | 1269 +------------------------------------+ 1271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Initiator's Nonce | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Puzzle's Solution | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 A.5. P1 Packet Format 1280 Type 0x0101 1282 P1 is just the common packet format without additional fields, 1283 although a vendor-specific or application-specific options field 1284 is possible. 1286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Options ... 1289 +-+-+-+-+- 1291 A.6. P2 Packet Format 1293 Type 0x0201 1295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Session Key Lifetime | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | | 1300 + Cookie Puzzle Request + 1301 | | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | | 1304 + Public Diffie-Hellman Value + 1305 / (1536 bits at least) / 1306 / / 1307 + + 1308 | | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Options ... 1311 +-+-+-+-+- 1313 A.7. P3 Packet Format 1315 Type 0x0301 1317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Session Key Lifetime | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | | 1322 + Cookie Puzzle Request + 1323 | | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Security Protocol Index | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | | 1328 + Imprint (64 bits) + 1329 | | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | | 1332 + Public Diffie-Hellman Value + 1333 / (1536 bits at least) / 1334 / / 1335 + + 1336 | | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | | 1339 + RSA Public Key + 1340 / (1536 bits at least) / 1341 / / 1342 + + 1343 | | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | | 1346 + RSA Signature + 1347 / (1536 bits at least) / 1348 / / 1349 + + 1350 | | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Options ... 1353 +-+-+-+-+- 1355 A.8. P4 Packet Format 1357 Type 0x0401 (to be used to prove only initiator's ownership) 1359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Security Protocol Index | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | | 1364 + + 1365 | Authenticator (HMAC) | 1366 + + 1367 | | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 Type 0x0402 (to be used to prove responder's address ownership) 1372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Security Protocol Index | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | | 1377 + Imprint (64 bits) + 1378 | | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | | 1381 + RSA Public Key + 1382 / (1536 bits at least) / 1383 / / 1384 + + 1385 | | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | | 1388 + RSA Signature + 1389 / (1536 bits at least) / 1390 / / 1391 + + 1392 | | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Options ... 1395 +-+-+-+-+- 1397 A.9. P5 Packet Format 1399 Type 0x0502 (to be used to protect disclosure of initiator's iden- 1400 tity) 1401 Note that this packet must be protected within an ESP payload, to 1402 avoid disclosure of initiator indentity (Public Key). 1404 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | | 1407 + Imprint (64 bits) + 1408 | | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | | 1411 + RSA Public Key + 1412 / (1536 bits at least) / 1413 / / 1414 + + 1415 | | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | | 1418 + RSA Signature + 1419 / (1536 bits at least) / 1420 / / 1421 + + 1422 | | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Options ... 1425 +-+-+-+-+- 1427 References 1429 [ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6", 1430 draft-nikander-ipng-address-ownership-00.txt, February 2001. 1432 [BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html 1434 [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for 1435 MIPv6 (CAM)", ACM Computer Communications Review, April 2001. 1437 [DetStrengths] Hilarie Orman and Paul Hoffman, "Determining 1438 Strengths For Public Keys Used For Exchanging Symmetric Keys", 1439 draft-orman-public-key-lengths-02.txt 1441 [HandBook] A.J. Menezes, P.C. van Oorschot and S.A. Vanstone. 1442 Handbook of applied cryptography. CRC Press, 1997. 1444 [HMAC] Krawczyk, Bellare and Canetti, "HMAC: Keyed-Hashing 1445 for Message Authentication," RFC 2104, February 1997. 1447 [IKEv2] D. Harkins, C. Kaufman, S. Kent, T. Kivinen, and R. 1449 Perlman, "Proposal for the IKEv2 Protocol", 1450 draft-ietf-ipsec-ikev2-02.txt. 1452 [IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture," 1453 RFC 2373, July 1998. 1455 [JFK] W. Aiello, S.M. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, 1456 A.D. Keromytis and O. Reingold, "Just Fast Keying (JFK)", 1457 draft-ietf-ipsec-jfk-03.txt. 1459 [lenstra00selecting] A.K. Lenstra and E.R. Verheul, "Selecting 1460 Cryptographic Key Sizes," manuscript, (Oct.1999). 1461 http://citeseer.nj.nec.com/lenstra99selecting.html 1463 [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobile IP for IPv6", 1464 draft-ietf-mobileip-ipv6-18.txt 1466 [MIPv6SecReq] Mankin, Patil, Harkins, Nordmark, Nikander, 1467 Roberts, Narten, "Threat Models Introduced by Mobile 1468 IPv6 and Requirements for Security in Mobile IPv6", 1469 draft-ietf-mobileip-MIPv6-scrty_reqts-02.txt 1471 [MODPGrp] T. Kivinen and M. Kojo, "More MODP Diffie-Hellman Groups 1472 for IKE", draft-ietf-ipsec-ike-modp-groups-03.txt 1474 [PUZZLES] Tuomas Aura, Pekka Nikander and J. Leiwo. DOS-resistant 1475 Authentication with Client Puzzles. 1477 [RFC2404] Madson and Glenn, "The Use of HMAC-SHA-1-96 within ESP 1478 and AH," RFC 2404, November 1998. 1480 [RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless 1481 Address Autoconfiguration in IPv6," RFC 3041. 1483 [SHA1] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA-1)," 1484 RFC 3174, September 2001. 1486 [WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress", 1487 http://www.cs.ucsd.edu/users/bsy/dobbertin.ps 1489 Authors' addresses 1491 Questions about this document may be directed to: 1493 Gabriel Montenegro 1494 Sun Microsystems Laboratories, Europe 1495 29, chemin du Vieux Chene 1496 38240 Meylan, FRANCE 1498 Voice: +33 476 18 80 45 1499 E-Mail: gab@sun.com 1501 Claude Castelluccia 1502 INRIA Rhone-Alpes 1503 655 avenue de l'Europe 1504 38330 Montbonnot Saint-Martin 1505 FRANCE 1506 email: claude.castelluccia@inria.fr 1507 phone: +33 4 76 61 52 15 1508 fax: +33 4 76 61 52 52 1510 Copyright (c) The Internet Society (2000). All Rights Reserved. 1512 This document and translations of it may be copied and furnished to 1513 others, and derivative works that comment on or otherwise explain it 1514 or assist in its implementation may be prepared, copied, published 1515 and distributed, in whole or in part, without restriction of any 1516 kind, provided that the above copyright notice and this paragraph are 1517 included on all such copies and derivative works. However, this 1518 document itself may not be modified in any way, such as by removing 1519 the copyright notice or references to the Internet Society or other 1520 Internet organizations, except as needed for the purpose of 1521 developing Internet standards in which case the procedures for 1522 copyrights defined in the Internet Standards process must be 1523 followed, or as required to translate it into languages other than 1524 English. 1526 The limited permissions granted above are perpetual and will not be 1527 revoked by the Internet Society or its successors or assigns. 1529 This document and the information contained herein is provided on an 1530 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1531 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1532 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1533 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1534 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1536 Changes 1538 Changes between version 02 and 03: 1540 o Added packet formats and sucvP protocol specs (to be taken 1541 out into a separate draft later on). 1543 o Deleted "dead" references to expired internet drafts and to 1544 HIP drafts. 1546 o Sundry editorial changes and corrections. 1548 Changes between version 01 and 02: 1550 o Cosmetic editorial changes, reorganization, etc. 1552 o Added more details on SKey derivation to the protocol overview 1553 section. 1555 o Added a terminology section. 1557 o Specified more fully the sucvP protocol, which means SUCV is 1558 now independent of HIP. 1560 o Added a section on extensions for constrained devices. 1562 o Added a section on Privacy considerations.