idnits 2.17.1 draft-montenegro-sucv-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 610 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 (November 2001) is 8169 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 552, but not defined == Missing Reference: 'RFC2412' is mentioned on line 554, but not defined == Missing Reference: 'RFC2451' is mentioned on line 559, but not defined == Unused Reference: 'BIRTH' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: 'HIPARCH' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'HIPIMPL' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'HIPPROT' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'WeakMD5' is defined on line 1185, 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' -- No information found for draft-ietf-moskowitz-hip-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIPARCH' -- Possible downref: Normative reference to a draft: ref. 'HIPIMPL' == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-03 -- Possible downref: Normative reference to a draft: ref. 'HIPPROT' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2373 (ref. 'IPV6ADDR') (Obsoleted by RFC 3513) -- Possible downref: Normative reference to a draft: ref. 'MIPPRIV' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 -- No information found for draft-ietf-mobileip-MIPv6-scrty_reqts - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIPv6SecReq' -- Possible downref: Normative reference to a draft: ref. 'MIPv6SecEval' == 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: 9 errors (**), 0 flaws (~~), 14 warnings (==), 16 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 November 2001 5 SUCV Identifiers and Addresses 6 draft-montenegro-sucv-02.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 ........................................... 9 61 5.3 Deriving the Session Keys .................................. 12 62 5.3.1 SUCV Session Key ...................................... 12 63 5.3.2 Keys for ESP-protected Binding Updates ................ 12 64 5.4 Default Algorithms ......................................... 12 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 ...................................... 15 71 8.0 Security Analysis ............................................. 16 72 8.1 Hash ID Size Considerations ................................ 16 73 8.2 Key size considerations .................................... 18 74 8.3 Intruder-in-the-middle attacks ............................. 19 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 .................................................. 24 81 11.0 Acknowledgements ............................................. 25 82 References ........................................................ 25 83 Authors' addresses ................................................ 26 84 Changes ........................................................... 27 85 1.0 Introduction 87 This document addresses the identifier ownership problem 88 [ADDROWN] by using characteristics of Statistic Uniqueness and 89 Cryptographic Verifiability (SUCV) of certain entities which 90 this document calls SUCV Identifiers (SUCV ID's). This note 91 also proposes using these SUCV characteristics in related 92 entities called SUCV Addresses in order to severely limit 93 certain classes of denial of service attacks and hijacking 94 attacks. SUCV addresses can solve the 'address ownership' 95 problem that hinders confidence in mechanisms like Binding 96 Updates in Mobile IP for IPv6. 98 [ADDROWN] argues that there is a fundamental problem in handling 99 operations like Binding Updates (BU's) in Mobile IP for IPv6 100 [MIPv6], source routing, etc) that allows hosts to modify how 101 other hosts route packets to a certain destination. The problem 102 is that these operations can be misused by rogue nodes to 103 redirect traffic away from its legitimate destination. 104 Authentication does not solve this problem. Even if a node 105 unequivocally identifies itself, this has no bearing on its 106 rights to modify how packets to any given address are routed. 107 This is true even if its packets currently seem to emanate from 108 the address in question. This last point is obvious if one 109 considers DHCP leased addresses. It is imperative not to allow 110 any node to redirect traffic for a DHCP address for which it 111 held a valid lease previously. This would allow it to hijack 112 traffic meant for the current valid user of the address in 113 question. Hence, protection against hijacking of valid addresses 114 requires cryptographic authorization for operations that modify 115 routing (BU's, source routing, etc). One way to show 116 authorization is by showing that the requesting node owns the 117 address for which routing information is being altered. Quoting 118 [ADDROWN]: 120 Currently there exists no specified mechanism for proving 121 address ownership in Internet-wide scale. 123 This document proposes a solution to the address ownership 124 problem. 126 2.0 Terminology 128 This Section presents the notation used throughout this paper. 130 prf: 131 Pseudo-random function. SUCV mandates the use of the keyed 132 hash function HMAC [HMAC] which produces 160 bits of output. 133 Input key is assumed to also be 160 bits. 135 prfT: 136 Pseudo-random function whose output is truncated by taking 137 the T leftmost bits of the output. In SUCV, HMAC-SHA1 is 138 used, so prf96, for example, would be the keyed hash function 139 HMAC-SHA1-96 [RFC2404]. 141 hash: 142 Cryptographic hash function, SHA-1 [SHA1] for SUCV. 144 hashT: 145 Cryptographic hash function whose output is truncated by 146 taking the T leftmost bits of the output. 148 SUCV: 149 Statistical uniqueness and cryptographic verifiability, the 150 property exhibited by the identifiers and addresses which are 151 the subject of this study. We also use SUCV to refer to the 152 resultant mechanism as a whole. 154 sucvP: 155 The protocol developed here, whose objectives are proof of 156 address ownership and session key generation. 158 sucvID: 159 128 bit identifier obtained as the keyed hash output of the 160 hash of the public key, using an imprint value as the input 161 key. 163 sucvHID: 164 64 bit SUCV identifier used instead of the interface 165 identifier, and combined with the routing prefix to form an 166 autoconfigured IPv6 address [IPV6ADDR]. Obtained as the keyed 167 hash output of the hash of the public key, using an imprint 168 value as the input key. 170 MIPv6: 171 Mobile IPv6 [MIPv6]. 173 MN, HA, CN, BU, BA and CoA: 174 Abbreviations of mobile node, home agent, correspondent node, 175 binding update, binding acknowledgement and care-of address, 176 respectively, as defined by MIPv6 [MIPv6] 178 3.0 Overview of the Proposal 180 We assume that we have a network in which the nodes inherently 181 distrust each other, and in which a global or centralized PKI 182 (Public Key Infrastructure) or KDC (Key Distribution Center) is 183 not available. 185 The goal is to arrive at some fundamental assumptions about 186 trust on top of which one can build some useful peer-to-peer 187 communication using opportunistic security. 189 But in such a network, is there a default rule we can follow 190 safely? We posit this is it: 192 Default Trust Rule: 194 Redirect operations are allowed only with addresses which 195 are securely bound to the requesting entity. 197 The above rule (to be refined later) constitutes the only rule 198 that operates by default, allowing any other more dangerous 199 operation only if authorized by strong cryptographic 200 mechanisms. 202 4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV) 204 In the absence of a third party, how does a principal prove 205 ownership of its identity to a peer? 207 Notice that usual owner verification relies on a third party to 208 provide this function. 210 In this proposal, the principal self-generates a private/public 211 key pair. It uses material obtained via a prf based on the 212 public key as its identity (or as part of its address) and 213 proves its ownership by signing it with its private key. The 214 recipient verifies the signature, and, consequently, the 215 ownership of the identity. 217 4.1 SUCV ID's 219 It is much more practical for protocols to use fixed length 220 identifiers (representations of identities). Because of this, we 221 do not use the public key itself as the identifier, but material 222 obtained via a prf of the public key. 224 These identifiers have a strong cryptographic binding with their 225 public components (of their private-public keys). This is 226 exactly the purpose that certificates have. Let's call them 227 Statistically Unique Cryptographically Verifiable ID's, or SUCV 228 ID's. 230 Because of this, once a CN obtains information about one of 231 these identifiers, it has a strong cryptographic assurance about 232 which entity created it. Not only that, it knows that this 233 identifier is owned and used exclusively by only one node in the 234 universe: its peer in the current exchange. Thus, it is safe to 235 allow that peer to effect changes (via BU's, for example) on how 236 this address or identifier is routed to. Notice that with 237 publically routable addresses, this assurance is much harder to 238 arrive at, given that the address may be 'loaned' to (not owned 239 by) the peer in question, perhaps thanks to the good service of 240 a DHCP server. 242 Despite the fact that currently there is no way to prove address 243 ownership in the Internet, these considerations lead to the 244 following fundamental assumption: 246 Default Trust Rule 248 Redirect operations are only allowed to affect routing for 249 entities which have the SUCV property. 251 The above constitutes perhaps the only rule that operates by 252 default, allowing any other more dangerous operation only if 253 authorized by strong cryptographic mechanisms 255 What should one use: pure identifiers with no routing 256 significance or addresses? With pure identifiers, routing 257 information must be included somewhere in the packet. This 258 takes up extra space in the packet via home address options, 259 routing headers or tunneling headers. 261 A major advantage to using an address is that the data traffic 262 need not carry extra information in the packet to guarantee 263 proper delivery by routing. Because of this it is useful 264 to create addresses that are routable and satisfy the SUCV 265 property: SUCV addresses. 267 4.3 SUCV Addresses 269 In IPv6, addresses that satisfy the SUCV property may be 270 obtained as follows (as it turns out, this is very similar to 271 and was predated by [CAM]): 273 - use the top 64 bits from your routing prefix (as in rfc3041) 275 - define the bottom 64 bits as an SUCV ID (called the sucvHID). 276 Use these 64 bits instead of the 'interface 277 identifier' in IPv6 [IPV6ADDR]. 279 The resultant 128 bit field is an identifier that is also 280 routable, avoiding the need for taking extra space in the packet 281 (for example, by sending routing options or tunneling headers). 282 Notice that even after moving, it is possible to reuse the 283 'HID' portion of the address with the new network prefix at 284 the new location. Thus it is possible to reuse the HID with 285 different CoA's. 287 Nevertheless, by snooping on binding updates, it is possible for 288 an attacker to learn the original network prefix used by the 289 home address. This tells an eavesdropper where this home address 290 began to be used, and to which network it belongs, potentially 291 important information. 293 On the other hand, if you use a 'pure' SUCV ID (without any 294 routing significance), then your packets will always need extra 295 information somewhere to assure they are routed properly. 296 Eavesdroppers may still know where that identity is at any 297 particular point in time. Nevertheless, this is a tangible 298 improvement over always including a valid 64 bit prefix, as this 299 divulges information about an identity's topological 300 connectivity or under what prefix a given identity began to be 301 used. 303 4.4 SUCV Derivation and Formats 305 This section describes how to generate an SUCV ID (128 bits), an 306 SUCV HID (64 bits) and an SUCV address (128 bits). 308 First of all, the node generates a public/private key pair. 309 Then we define the required quantities as: 311 sucvID = hmac-sha-1-128(sha1(imprint), sha1(PK)) 312 sucvHID = hmac-sha-1-64(sha1(imprint), sha1(PK)) 314 Where, imprint is a 64 bit field: 316 It could be a quantity that depends on the MN's location or 317 something created by the MN itself (a random value, for 318 example). The objective is to use the imprint to limit 319 certain types of brute-force attacks by limiting their 320 applicability, or by forcing interaction with the MN. 322 PK: The public key is the DSA public key. 324 Note that according to [IPV6ADDR], the leftmost 3 bits of 325 the sucvID can be used to unequivocally distinguish them from 326 IPv6 addresses. Accordingly, we assume only 125 bits may be 327 used. Additionally, bit 6 of the sucvHID (the universal/local) 328 has to be set to zero to indicate that the sucvHID is not 329 guaranteed to be globally unique. 331 5.0 SUCV Protocol (sucvP) Overview 333 The following protocol, sucvP, is run between a MN and an 334 arbitrary CN to: 336 - prove the Mobile host home address and possibly CoA 337 ownership 339 - to establish an IPSec ESP SA (Skey, Lifetime, SPI) between 340 the MN and its CN that will be used to secure MIPv6 BUs. 342 As for the choice of using AH or ESP to protect the binding 343 updates, we chose the latter, because we believe there is 344 no added value in protecting the IP headers of BU's once a 345 security association has been established. This and the heated 346 debate on the future of AH convinced us to use ESP. 348 sucvP is functionally independent of MIPv6, and is, in fact, 349 a separate protocol. sucvP provides the authorization for 350 the MIPv6 BU's, but the authentication is provided by IPsec 351 ESP. These are two separate steps which could run serially. For 352 example, the sucvP step could be carried out over UDP (as our 353 initial experimental implementation does), after which the 354 ESP-authenticated BU could be sent. 356 However for efficiency reasons, sucvP messages might contain 357 MIPv6 BUs (along with sucvP3). 359 In order for sucvP to set up an IPsec security association 360 (including an SPI) just in time to process an ESP header and 361 its encapsulated BU, the sucvP payload is carried as an IP 362 protocol number (currently unassigned). Furthermore, it must 363 precede the ESP payload used to authenticate the binding update. 365 5.1 Goals and Constraints 367 This design allows sucvP to satisfy these two objectives: 369 - not affect existing IPsec implementations more than 370 absolutely necessary 372 - support efficient BU processing by reducing as much as 373 possible the number of round trips. 375 Furthermore, we assume there is no piggybacking with the BU, 376 so no further payload follows. 378 sucvP has been designed based on the following considerations: 380 - the protocol should not rely on a third party (i.e. a 381 global PKI, central key distribution center, etc), although 382 it could use one if available 384 - not all nodes need to use SUCV addresses, only those that 385 wish their binding updates to be heeded (mobile nodes) 387 - not all nodes need to verify the validity of SUCV 388 addresses, only those CN's that accept and handle binding 389 updates from MN's (these CN's must use SUCV as explained 390 below to safely populate their binding caches) 392 sucvP packets are exchanged directly between the mobile node and 393 its correspondent nodes. They are not routed through the Home 394 agent because the mobile node might be homeless or the home 395 agent might be out of order for a certain period of time. The 396 implications for this decision are explored below. 398 5.2 Packet Exchanges 400 The proposed protocol that a mobile host uses to send a BU to 401 its CN is the following: 403 sucvP1: 404 The MN sends a sucvP1 message (just to initiate the exchange) 405 to its correspondent node. This message contains a Nonce, 406 N1. This packet may contain a MIP HomeAddress Option 407 containing the MN's home address. The CN might sometimes need 408 the home address to decide whether it wants to pursue the 409 protocol exchange or not. The source address of the packet is 410 the MN's current CoA. Additionally, SUCV supports a very 411 simple negotiation mechanism that works as follows: 413 Optionally, the MN can express its desire to use certain 414 Diffie-Hellman groups (for the ephemeral DH exchange), as 415 well as algorithms for ESP authentication and for ESP 416 encryption. 418 sucvP2: 419 The CN replies with a sucvP2 message that contains the 420 following: N1, Client puzzle request, Diffie-Hellman value 421 (g^y mod p), Session_Key_lifetime. The CN may respond to any 422 optional parameter negotiation included by the MN in sucvP1, 423 by choosing those algorithms it wishes to support. 425 In order to defend against sucvP1 storms, a host might use 426 the same Diffie-Hellman (DH) value for a period of time. The 427 sucvP2 contains a client puzzle to prevent DoS attacks 428 PUZZLES. Along these line, the CN may wish to ignore the 429 optional negotiation of parameters initiated by the MN in 430 sucvP1. In this case, the default algorithms (see below) must 431 be used by both parties. 433 When the MN receives sucvP2, it verifies that the nonce N1 is 434 the same as what was sent in sucvP1. It then solves the 435 puzzle. At this stage of the protocol, the MN: 437 1. generates a DH value (g^x mod p) and derives from it and 438 the DH received from the CN the session keys. 440 2. computes skey_espauth (the ESP session key used to 441 authenticate the MIPv6 binding update lifetime as the 442 minimum of the lifetime value suggested by the CN and its 443 lifetime value. 445 3. builds an IPSec SA. If ESP is used subsequently in the 446 packet to secure a Binding Update, the MN must use a fixed 447 SPI assigned from the range 1 to 255 (currently 448 unassigned). 450 4. sends a sucvP3 packet. Note that this message is sent 451 directly from the MN's CoA to the CN. 453 sucvP3: 454 A sucvP3 message contains the following fields: Puzzle reply, 455 Public key and imprint it has used to generate its HID, a 456 Diffie-Hellman value, the skey_espauth lifetime and an SPI 457 for the CN to use when sending BA's (secured via ESP) to the 458 MN. This message must be signed by the MN with its private 459 key (the public key is used to generate the HID). 461 Note that this sucvP3 might be followed by an ESP header 462 authenticating an encapsulated BU. The authentication is 463 performed using the SA available inline within this sucvP3 464 packet. 466 When the CN receives the sucvP3, it first checks for a valid 467 Puzzle reply. It verifies the signature using the included 468 Public key, and then verifies that this Public key and 469 imprint produce the sucvHID used as part of the sender's 470 address. The CN can then conclude that the MN owns its the 471 Home and CoA addresses. 473 At this point, the CN makes a note of this Public key and 474 HID. 476 The CN can then compute the session keys (using the ephemeral 477 DH value. From the fixed SPI, the CN learns that the 478 security association material is all inline in sucvP3. It 479 proceeds to build an IPSec SA and processes this ESP header. 480 In preparation for subsequent ESP processing of BU's, it 481 computes an SPI and sends it in sucvP4. After this point, and 482 thanks to this SPI, IPsec usage reverts to normal, i.e., 483 future BU's can be secured via ESP, unaccompanied by any 484 inline sucvP material. 486 sucvP4: 487 In sucvP4, the CN sends an SPI. The MN will use this SPI in 488 association with ESP in order to authenticate subsequent 489 BU's. The CN authenticates sucvP4 with HMAC-SHA1 using the 490 Session key Skey_sucv derived previously. Additionally, a CN 491 that uses an SUCV address could sign sucvP4 instead. This 492 possibility is explored below. 494 A CN may include a BA (binding acknowledgement) along with 495 sucvP4, and if so, it must use ESP for authentication. The 496 SPI used is that communicated by the MN in sucvP3. When the 497 MN receives a sucvP4, it must make note of the SPI 498 corresponding to the CN. } 500 As long as the MN uses the same HID interface identifier for 501 its CoA, it does not have to prove the CoA ownership and BU 502 authentication is enough. 504 Proving the CoA ownership can be very useful to prevent a 505 malicious host from bombing a victim with packets by using 506 the victim's address as CoA. For example, with ``regular'' 507 Mobile IPv6, a host can start a big file transfer from a server 508 and then send a BU with the victim's address as CoA to the 509 server. As a result, the file will be send to the victim. If 510 an host can prove that it owns its CoA, and that therefore it 511 is not using someone's else address as CoA, this attack can 512 be avoided. 514 If for any reason the MN configures its CoA with a new interface 515 identifier, it must restart the whole protocol sequence. 517 5.3 Deriving the Session Keys 519 We need to generate keying material and keys for the SUCV 520 protocol itself and for use with ESP. 522 skeymat = prf(hash (g^{xy} mod p), N1 | imprint) 524 Where N1 is the nonce used in sucvP1 and sucvP2. 526 5.3.1 SUCV Session Key 528 skey_sucv = prf(skeymat, g^{xy} mod p | N1 | imprint | 0) 530 Used with sucvP4 for: authentication, and optionally with sucvP5 531 (see Section on Privacy Considerations) for both authentication 532 and encryption. 534 5.3.2 Keys for ESP-protected Binding Updates 536 skeymat_espauth = prf(skeymat, skey_sucv | g^{xy} | N1 | 537 imprint | 1) 539 Used to authenticate BU's unaccompanied by SUCV packets (once 540 sucvP is completed). 542 Note that whereas skey_sucv is the actual key used by the 543 SUCV protocol, skeymat_espauth is keying material used to 544 derive the real key for use with ESP, i.e. skey_espauth in an 545 algorithm-specific manner. 547 5.4 Default Algorithms 549 The following algorithms must be supported by any SUCV 550 implementation: 552 DSA [DSA] for signing sucvP3. 554 Diffie-Hellman Oakley Group 1 [RFC2412] for the ephemeral 555 Diffie-Hellman exchange. 557 HMAC-SHA-1-96 [RFC2404] for ESP authentication. 559 3DES-CBC [RFC2451] for sucvP5 and ESP encryption. 561 6.0 Extension for Constrained Devices 563 In our sucvP protocol, a MN must: 565 - generate a DSA public/private key pair. 567 - sign the sucvP3 message. 569 - perform a DH exponentiation to derive the Skey. 571 All these operations are computativally expensive especially 572 if the MN is a constrained device (i.e. a PDA or a sensor 573 with limited memory, battery or CPU). Elliptic curve 574 cryptographic algorithms might be more efficient but still 575 too expensive to execute for a constrained device. 577 In this section, we propose an extension to our scheme for 578 this type of contrained devices. Our goal is to off-load most 579 of the expensive cryptographic operations of a MN to its HA. 580 We assume that the MN and HA share a secret key, and that the 581 MN trusts its HA. 583 The proposed extension operates as follows: 585 1. The HA generates the DSA keys (public and private keys) 586 and sends the public Key to the MN via the secured channel. 588 2. The SUCV id and HID is generated by the MN itself by choosing 589 a k and computing sucvHID = prf64(hash(publicKey), k). 591 3. When a MN wants to initiate a sucvP exchange with CN, it 592 sends a SUCV_request messages, that contains the CN address 593 and the k value, to its HA (authenticated with the shared 594 key). The HA then initiates a sucvP exchange with the CN. The 595 HA then proves that it knows the private key corresponding 596 to the public by signing the exchanged messages (sucvP has 597 to be slightly modified here) and generates a session key, 598 SKey using the DH algorithm. 600 4. The HA then sends the Skey to the MN via the secure channel. 602 5. The MN can then send authentication BUs to the CN using 603 the SKey. 605 With this extension all the expensive cryptographic operations 606 are offloaded to the home agent but the session key that is 607 used to authenticated the MIPv6 BU (Skey) is only known to 608 the MN, its HA and the CN. A malicious host that wants to 609 redirect a MN's traffic needs either to discover the HA-MN 610 secret key or to find a public key/private key pair and a k' 611 such that 613 sucvHID = prf64(hash(public), k') 615 Both are very difficult to achieve. 617 7.0 Privacy Considerations 619 A normal sucvP exchange consists of sucvP1 through sucvP3, 620 and a subsequent sucvP4 authenticated using the session key. 621 This basic protocol does not allow any hijacking attacks, so 622 it already fulfills the security requirements for protecting 623 BU's in MIPv6 as defined by the Mobile IP working group 624 [MIPv6SecReq]. 626 7.1 Support for Random Addresses [RFC3041] 628 A first concern regarding privacy is how to use random 629 addresses as defined in RFC3041 in a mobile environment. 630 The issue here is that, whereas these addresses hide a node's 631 permanent identifier (perhaps derived from IEEE addresses), 632 the node cannot prove address ownership of them so it cannot 633 safely send binding updates. This means that an MN cannot use 634 RFC3041 addresses with route optimization. SUCV addresses 635 are indistinguishable from those defined in RFC3041, with the 636 added benefit that an MN can use them in a route optimized 637 fashion. The basic sucvP outlined above already handles this 638 case. The only consideration is that nodes interested in being 639 anonymous may want to use ephemeral SUCV identifiers (as opposed 640 to more permanent or longer-lived SUCV ID's) for this purpose. 642 Furthermore, if nodes wish to have higher protection against 643 attackers than what is afforded by 63 bits in the sucvAddr, 644 they can use an sucvID. The protocol exchange is the same, 645 but since an sucvID is a pure identifier without any routing 646 information, the MN is restricted to being a client. Of course, 647 as shown below, routing information must be included somewhere 648 in the packet, via home address options and routing headers 649 (alternatively, tunneling headers could be used as well). 651 7.2 Support for Confidentiality 653 7.2.1 Confidentiality 655 If confidentiality is a concern, there is the possibility of 656 an intruder in the middle gaining knowledge of the session keys, 657 as explained in the section on Security Analysis. In fact, 658 sucvP prevents an intruder from impersonating a Mobile node 659 but not from impersonating a correspondent node. As a result, 660 a MN might think that it is talking with its CN whereas it 661 is actually talking with an intruder. The MN may wish to 662 make sure it is indeed talking to a given CN whose address 663 it has previously obtained (via, for example, a DNS search, 664 or a preconfigured list). If in addition to the MN, the CN 665 also uses an SUCV address this problem can be prevented. We 666 suggest that a CN uses a SUCV address when confidentiality 667 is an issue and that the CN signs sucvP4 to prove its address 668 ownership. By doing so, both MN and CN have the assurance that 669 they are talking to each other and not to an intruder. 671 7.2.2 Location Privacy 673 In Mobile IPv6: 675 Each packet (BU and data) sent by a MN contains a 676 HomeAddress option that reveals the MN's home address. 678 Each packet sent to a MN contains a routing header with 679 the MN's home address. 681 As a result it is very easy for any host in the network 682 to track the location of a MN by snooping its packets. 683 If location privacy is an issue, a MN can use an ephemeral 684 home address sucvADDR_ephem instead of its actual one and 685 only reveal its actual home address sucvADDR to its CN (see 686 [MIPPRIV] for more details). Packets (BU and data) sent over 687 the network then use the ephemeral home address sucvADDR_ephem. 689 This privacy extension can actually be applied to our proposal. 691 The MN will need an ephemeral SUCV identity sucvID_ephem, and 692 defer revealing its more permanent SUCV identity sucvID after 693 the CN has proven ownership of its address. This is accomplished 694 roughly via the following extended protocol sequence: 696 sucvP1: as usual 698 sucvP2: the CN adds a bit to advertise its SUCV capabilities 700 sucvP3: the MN proves ownership of its sucvADDR_ephem (derived 701 from an ephemeral public-private key. At this point, 702 the MN derives session keys but is not yet sure it 703 sharing them with the CN itself. 705 sucvP4: the CN proves ownership of its SUCV address by signing 706 sucvP4 with its private key, at which point the MN 707 knows the session keys have not been compromised by 708 an intermediary. 710 sucvP5: the MN uses the session key obtained above to send an 711 encrypted payload revealing its actual SUCV Home Address 712 sucvADDR. sucvP5 must be signed with the key used to 713 generate the sucvADDR in order to prove its ownership. 715 Notice that if the MN wishes to use the stronger mode, it can do 716 so by using an sucvID_ephem and sucvID instead of sucvADDR_ephem 717 and sucvAddr, respectively. As in the discussion above, 718 this provides for more protection against attackers, with the 719 proviso that the MN is now limited to being a client. That is, 720 it must initiate communication with the CN, because it is now 721 using non-routable entities (SUCV ID's versus SUCV Addresses). 723 8.0 Security Analysis 725 This section includes a non-exhaustive security analysis of the 726 SUCV protocol. For an assessment with regards to the security 727 requirements in [MIPv6SecReq] please see [MIPv6SecEval]. 729 8.1 Hash ID Size Considerations 731 In SUCV addresses, one of the lower 64 bits is reserved as the 732 local/universal bit (the u bit), so only 63 bits are actually 733 usable as a hash. 735 Suppose the hash function produces an n-bit long output. If we 736 are trying to find some input which will produce some target 737 output value y, then since each output is equally likely we 738 expect to have to try 2^{(n-1) possible input values on average. 740 On the other hand, if we are worried about naturally ocurring 741 SUCV address duplications, then by the birthday paradox we 742 would expect that after trying 1.2*2^n/2 possible input values 743 we would have a 50% probability of collision [HandBook]. 745 So if n=63, you need a population of 1.2*2^{31.5} i.e. 3.64*10^9 746 nodes on average before any two produce duplicate addresses. 747 This is acceptable especially if you consider that this 748 collision is actually harmfull only if the 2 hosts (that 749 collide) are in the same site (i.e. they have the same 64 750 bit prefix), and have the same correspondent nodes. This is 751 very unlikely. Additionally, assuming the collision is not 752 deliberate the duplicate address detection (DAD) will detect it. 754 If an attacker wishes to impersonate a given SUCV address, 755 it must attempt 2^{62} (i.e. approximately 4.8*10^{18}) 756 tries to find a public key that hashes to this SUCV address. 757 If the attacker can do 1 million hashes per second it will need 758 142,235 years. If the attacker can hash 1 billion hashes per 759 second it will still need 142 years. 761 If we use SUCV Addresses as suggested in RFC3041 (perhaps 762 renewing them as often as once every 24 hours), an attacker 763 would then have to to hash 5.3*10^{13} hashes/second in order 764 to be able to find a public key that hashes to the sucvHID of 765 a given host. 767 Note that the previous analysis only considers the cost of 768 computing the hash of the public key. Additionally, an attacker 769 must also generate a valid (public, private) key pair. This is 770 a significantly more expensive operation. 772 This would still leave open the possibility of brute-force 773 attacks. In this scenario, a bad guy BG could generate a huge 774 table of PK's and their corresponding HID's, assuming any fixed 775 imprint. It could then look for matching real IP addresses. 776 By doing so it would identify a victim for a hijacking attack. 777 BG can send a BU to any CN without a binding entry for the 778 victim's address (for example, by targetting non-mobile fixed 779 hosts as victims). 781 In general, such attacks are possible with hash functions, but 782 not with keyed hash functions because they require interacting 783 with the legitimate user [HMAC]. Notice that normal usage of 784 keyed hash functions requires an authenticated secret, which 785 we do not have. Nevertheless, we can still limit exposure by 786 creating the HID (or ID) using (in addition to the Public key) 787 some key or known state that is established in advance of the 788 sucvP interaction itself, and which will force interaction 789 with the MN. 791 This is the role of the imprint, sent by the MN to the CN in 792 sucvP. Since the imprint is not authenticated, the CN could 793 verify it independently of sucvP, perhaps by checking directly 794 with the MN by routing it via the HA. True, the imprint 795 is not a secret as expected for HMAC use, but it serves to 796 severely limit which entities can launch the attack to only 797 those entities with this priviledged location, and within this 798 time period. 800 As another possibility, the imprint may instead be a quantity 801 which the CN knows about the MN, and which the CN can verify 802 independently using a separate subsystem (DNS, routing fabric, 803 etc). In this case, the attack is limited to only those nodes 804 for which the imprint is also a valid quantity. Tying the 805 HID in this manner may have undesirable consequences with 806 regards to privacy and location independence (for example 807 homeless operation). 809 Alternatively, one could always use sucvID's (in which case 810 the brute-force attacks would be nearly impossible). 812 Even for HID's, actually carrying out such brute-force 813 attacks remain highly unlikely in practice, and we claim our 814 scheme remains secure even without requiring any of the above 815 counter-measures. 817 8.2 Key size considerations 819 There are three ways that an attacker could break the MIPv6 820 security protocol presented in the paper: 822 1. If an attacker find a DSA public/private key pair that hashes 823 to the MN's sucvID, it can run a sucvP exchange with a CN 824 and impersonate the MN. This can be achieved by a brute 825 force attack. The attacker tries several public keys as 826 input to the hash function used to generate the sucvID. 827 The difficulty of this attack depends on the size of the 828 sucvID and is at least as hard as breaking a symmetric key 829 algorithm that uses the same key size as the sucvID size 830 (actually this is more difficult because the attacker 831 must also generate valid public/private key pairs before 832 performing the hash function). 834 2. If an attacker can find the public/private key pair that 835 is used to generate the sucvId and sign sucvP3, an attacker 836 can impersonate a MN in sucvP. Breaking a DSA system depends 837 on the DSA modulus and subgroup. 839 3. If an attacker can retrieve the generated session key it can 840 send fake BU's on behalf of the MN and redirect its traffic. 841 An attacker has two ways of retrieving the session key: 842 (1) generate it from the DH values exchanged between the 843 MN and the CN, or (2) perform a brute-force attack on the 844 session key itself. The difficulty of these attacks depend 845 respectively on the DH modulus size and the session Key size. 847 A security system is consistent if all the components of the 848 security chain provide the same security levels and none of 849 them is a weak link. Most of the security parameters used in 850 our proposal (DH modulus size, Session key size, DSA subgroup) 851 can be adjusted. The only fixed parameter is the SUCV identifier 852 itself. It is either 63 bits long (i.e. we use an sucvHID) 853 or 125 bits long (if using an sucvID itself). 855 If we use sucvHID's, the security of our proposal depends on 856 these 63 bits. Accordingly, the symmetric key strength should 857 not be less, not would we gain much by it being significantly 858 stronger. In light of [DetStrengths], Oakley group 1 is about 859 enough for this application (although there are other more 860 conservative views [lenstra00selecting]). 862 However, if we use suvcID's, we will need a symmetric key 863 strength of almost 128 bits (125 bits) of output from our 864 prf. Notice that 96 bits symmetric keys are generally considered 865 safe for another 20 years or so. However, if we want to keep up 866 with the strength afforded by the sucvID itself, we would need 867 to use other MODP groups [MODPGrp]. For example, MODP group 5 868 with exponents of 1563 bits should be enough to derive 90 bit 869 symmetric keys. MODP group 6 with 2048 bits should be used to 870 produce 100 bit symmetric keys. 872 8.3 Intruder-in-the-middle attacks 874 As described above, a mobile node and its correspondent node 875 derive a shared (symetric) key to authenticate the MIPv6 876 Binding updates sent by the MN. 878 The MN and its CN derive the shared key using the Diffie-Hellman 879 algorithm. 881 The CN chooses a random secret y and sends g^y mod p to 882 the MN (in the DH value field of sucvP2) 884 The MN chooses a random secret x and sends g^x mod p to 885 its CN (in the DH value field sucvP3) 887 The session key shared by the MN and its CN is then a hash 888 digest of g^{xy} mod p (g and p are known by the MN and CN). 890 8.3.1 Summary of the Attack 892 Diffie Hellman is know to be vulnerable to the 893 intruder-in-the-middle attack on un-authenticated DH key 894 agreement: 896 CN -->g^y-->Intruder-->g^y_i-->MN 897 CN<--g^x_i-->Intruder<--g^x<--MN 899 The intruder intercepts g^y sent by the CN and sends g^{y_i} 900 to the MN. The intruder also intercepts g^x sent by the MN 901 and sends g^x_i to the CN. As a result, MN shares the key 902 g^{xy_i} with the intruder (it actually thinks that it is 903 sharing this key with its CN). The CN shares the key g^{x_iy} 904 with the intruder (it actually thinks that it is sharing this 905 key with the MN). The Intruder can then impersonate the MN 906 and the CN. 908 In our protocol, the MN signs sucvP3 (which contains g^x). 909 As a result, the intruder can not modify nor replace this 910 message. This only thing that the intruder could do is the 911 following attack: 913 sucvP1: CN<--HID'-->Intruder<--HID<--MN 914 sucvP2: CN-->g^y-->Intruder-->g^yi-->MN 915 sucvP3: CN<--g^xi-->Intruder<--g^x<--MN 917 In sucvP1, MN sends its HID by virtue of sending from its 918 address (the HID is just the bottom 64 bits in the address). The 919 intruder could replace this HID by another value, say HID_i, 920 without affecting return routability, as long as the prefix 921 remains the same. In sucvP2, the CN sends its DH value g^y, 922 which is replaced by the intruder for g^{y_i}. In sucvP3, the 923 MN sends its g^x. Notice that the intruder can replace it by 924 another g^{x_i} as long as this {g^x_i} is used to create HID_i. 926 8.3.2 Risks 928 The keys created are derived from: 930 g^{xy_i} (between the MN and the intruder) and 932 g^{yx_i} (between the intruder and the CN). 934 So the intruder cannot pass itself off as MN (assuming it is 935 computationally unfeasible to find another private-public pair 936 that generates the same HID). It can, however, pass itself off 937 as MN_i, where this is the address formed from HID_i. This means 938 that it is not possible for an intruder to hijack an existing 939 communication between MN and CN. But if the intruder is present 940 at the very beginning of the communication, and if it sits 941 on the path it could supplant MN. In so doing it could obtain 942 knowledge of any session keys derived for this communication. 944 If the session supported encryption, the endpoints might be led 945 to believe in the privacy of their conversation, oblivious to 946 the fact that the intruder could snoop. For example, suppose 947 an MN established an sucvP session with an CN. Subsequently, 948 and using this optimized path, an application (for example 949 telnet) started. If a security policy database required all 950 such application traffic to be encrypted, a misconfigured 951 system might leverage the existing sucvP session and use ESP 952 for confidentiality. This would result in the intermediary 953 being privy to all the application traffic. 955 Because of this, sucvP session keys must not be used for 956 anything more than securing BU's. In other words, IPsec 957 traffic selectors in the SPD must limit use of SA's obtained 958 via sucvP for the sole purpose of securing BU's. In order to 959 avoid any potential misapplication of these SA's BU's must 960 not be piggybacked. 962 Not heeding the above guidelines may result in the 963 aforementioned snooping attack. Nevertheless, the attacker 964 would have to remain on the path forever. This interception 965 is possible because of the non-authenticated nature of 966 the example. Of course, if the exchange is authenticated, 967 perhaps as contemplated by default by HIP [HIPARCH, HIPIMPL, 968 HIPPROT], this would not be possible. Even if this interception 969 is possible, once the intruder ceases to be on the path between 970 MN and CN there is nothing further it can do. In other words, 971 the use of unauthenticated SUCV entities does not add any 972 risk to those that currently exist. Even unauthenticated 973 SUCV, eliminates the possibility of on the path redirection 974 of traffic. Notice that with current MIPv6, ``off the path'' 975 (as well as ``on the path'') redirection of traffic is possible. 977 In some case, a MN might request to its CN to acknowledge the 978 reception of the BU. The intruder could actually fool the MN 979 by sending an acknowledgement with the CN address as source 980 address (note that the intruder could also authenticate this 981 acknowlegement since it knows the key used by the MN, g^{xy}). 982 This might confuse the MN that has received an acknowledgement 983 but keeps receiving the packets from the CN via its home agent 984 (note that the same problem exists also will current Mobile 985 IPv6 specification)! 987 One solution to these problems is for the the CN to use an 988 SUCV address and to sign sucvP2 (the message that contains the 989 DH value). Then, the intruder will not be able to substitute 990 g^y by g^{y_i}. 992 Of course, the intruder can hinder successful completion 993 of the SUCV protocol, thus preventing the CN from heeding 994 the MN's BU using route optimization to the MN. In effect, 995 this is a denial-of-service attack against route optimization, 996 and it leads to service degradation not disruption. 998 The previous security analysis shows that sucvP prevents any 999 intruders from redirecting the traffic addressed to a mobile 1000 host's home address and consequently provides the minimal 1001 Mobile IP security requirement [MIPv6SecReq]. 1003 8.3.3 Why not Route sucvP2 Through the Home Agent? 1005 What, if we assume sucvP1 was carried with a home address 1006 option, and then sucvP2 travelled via the home agent. At 1007 this point, the home agent can check that the validity of 1008 this MN_i (corresponding to HID_i), its current care-of 1009 address, etc. In this case, none of the above snooping would be 1010 possible. In order to further mitigate the sucvP2 packet from 1011 being redirected, the MN must check upon its reception that it 1012 was sent tunneled by its home agent. Home address options can 1013 be misused to set up distributed denial of service attacks 1014 whereby these options are sent to numerous hosts prompting 1015 them all to respond to the same address. Even if CN's exercise 1016 caution when sending their sucvP2 packets as instructed via a 1017 home address option, the nature of DDoS attacks is such that 1018 any given CN may not send more than a few sucvP2's to the same 1019 home address region (same prefix), the collection of thousands 1020 of such responses may be sufficient to clog a target network. 1022 The above analysis shows the pro's and cons of using the home 1023 address option. Notice that for our purpose of authenticating 1024 BU's we do not need to resort to the heavy requirement of 1025 routing sucvP2 via the HA. SUCV packets are exchanged directly 1026 between the MN and the CN. 1028 8.4 Denial-of-Service Attacks 1030 Denial-of-service (DOS) attacks that exhaust a host resource 1031 (memory and computional resources) is a major security threat 1032 on the Internet. In this section we study the behavior of 1033 the sucvP against DoS attacks. 1035 sucvP1 storm: 1037 Malicious hosts, could try to attack a host, by sending a 1038 storm of sucvP1 messages. We prevent this potential attack 1039 as follows: 1041 1. When receiving a sucvP1, a host does not create any 1042 state and replies with a constant message (sucvP2) 1043 that contains a client puzzle [PUZZLES]. 1045 2. An host only creates state if it receives a valid puzzle 1046 reply to its puzzle request (in sucvP3). 1048 sucvP2 storm: 1050 Malicious host could try to attack a host by sending a storm 1051 of sucvP2 messages. We prevent this attack by inserting 1052 a nonce, N1, in the sucvP1. If a host receives a sucvP2 1053 with a nonce N1 that is not equal to the nonce N1 that it 1054 has set in the initial sucvP1, this sucvP2 must be rejected. 1056 Note that an intruder (between the MN and its CN) could 1057 intercept the sucvP1 and reply to the MN with a fake sucvP2 1058 containing a valid N1 and an intentionally difficult puzzle 1059 request. The MN would then spend a lot of CPU and power 1060 computing the puzzle reply. This attack can be avoided 1061 if the MN had a mean to authenticate the address used by 1062 its CN. One solution is that the CN uses a SUCV address 1063 and signs sucvP2. 1065 Instead of this heavy alternative, we suggest that a MN 1066 simply reject any sucvP2 messages that contain an overly 1067 complex client puzzle request Of course, the MN itself 1068 defines the complexity threshold of the puzzle request as 1069 a function of its processing power. 1071 As a result, the attack that consists of sending complex 1072 puzzles (in sucvP2) to a MN, in order to exhaust its 1073 computing resources, will not be sucessful, because the 1074 MN will drop the sucvP2. The MN service will be degraded 1075 (because its incoming packets will then be routed through 1076 its home agent) but not disrupted.} 1078 sucvP3 storm: 1080 Malicious hosts could try to attack a host by sending a storm 1081 of sucvP3 messages. We prevent this attack by using a client 1082 puzzle. A host accepts a sucvP3 message only after verifying 1083 that the puzzle reply (contained in the sucvP3) is valid.} 1085 9.0 Security Considerations 1087 The technique introduced in this document is meant to increase 1088 the level of security in the Internet. 1090 This document explains the concept of statistical uniqueness 1091 and cryptographic verifiability (SUCV), specially as it 1092 applies to IPv6 addresses in the form of SUCV addresses. The 1093 SUCV characteristics are used to prove address ownership, thus 1094 preventing a class of attacks which exploit this fault in many 1095 types of commands. In particular, commands which alter how an 1096 address is treated by peers or by the routing infrastructure 1097 can be used to launch denial of service attacks or hijacking 1098 attacks. Proving address ownership eliminates these attacks. 1099 However, given that this technique is meant to be used primarily 1100 in the absence of global infrastructures, the possibility of 1101 man in the middle attacks does remain. Nevertheless, these 1102 attacks are limited by the use of cookies and client puzzles. 1104 10.0 Conclusions 1106 The present document focuses on the use of the SUCV property to 1107 enhance the security of exchanges between an arbitrary pair of 1108 peers in the absence of any third party. In particular, we 1109 propose that SUCV addresses be used to solve the issue of 1110 securing binding updates in Mobile IPv6. 1112 11.0 Acknowledgements 1114 The authors appreciate the helpful comments received from the 1115 following individuals: Erik Nordmark, Alberto Escudero, Lars 1116 Henrik Petander, Imad Aad, Pars Mutaf and the anonymous 1117 reviewers. 1119 References 1121 [ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6", 1122 draft-nikander-ipng-address-ownership-00.txt, February 2001. 1124 [BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html 1126 [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for 1127 MIPv6 (CAM)", ACM Computer Communications Review, April 2001. 1129 [DetStrengths] Hilarie Orman and Paul Hoffman, "Determining 1130 Strengths For Public Keys Used For Exchanging Symmetric Keys", 1131 draft-orman-public-key-lengths-02.txt 1133 [HandBook] A.J. Menezes, P.C. van Oorschot and S.A. Vanstone. 1134 Handbook of applied cryptography. CRC Press, 1997. 1136 [HIPARCH] Bob Moskowitz, "HIP Architecture", 1137 draft-ietf-moskowitz-hip-arch-02.txt 1139 [HIPIMPL] Bob Moskowitz, "HIP Implementation", 1140 draft-moskowitz-hip-impl-01.txt 1142 [HIPPROT] Bob Moskowitz, "Host Identity Payload and Protocol", 1143 draft-moskowitz-hip-03.txt 1145 [HMAC] Krawczyk, Bellare and Canetti, "HMAC: Keyed-Hashing 1146 for Message Authentication," RFC 2104, February 1997. 1148 [IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture," 1149 RFC 2373, July 1998. 1151 [lenstra00selecting] A.K. Lenstra and E.R. Verheul, "Selecting 1152 Cryptographic Key Sizes," manuscript, (Oct.1999). 1153 http://citeseer.nj.nec.com/lenstra99selecting.html 1155 [MIPPRIV] Castelluccia, Dupont, "A Simple Privacy Extension for 1156 Mobile IPv6," draft-castelluccia-mobileip-privacy-00.txt, 1157 February 2001. 1159 [MIPv6] C. Perkins, "Mobile IP for IPv6", 1160 draft-ietf-mobileip-ipv6-15.txt 1162 [MIPv6SecReq] Mankin, Patil, Harkins, Nordmark, Nikander, 1163 Roberts, Narten, "Threat Models Introduced by Mobile 1164 IPv6 and Requirements for Security in Mobile IPv6", 1165 draft-ietf-mobileip-MIPv6-scrty_reqts-02.txt 1167 [MIPv6SecEval] Montenegro and Petrescu, "MIPv6 Security: Assessment 1168 of Proposals," draft-montenegro-mobileip-mipv6-seceval-00.txt. 1170 [MODPGrp] T. Kivinen and M. Kojo, "More MODP Diffie-Hellman Groups 1171 for IKE", draft-ietf-ipsec-ike-modp-groups-03.txt 1173 [PUZZLES] Tuomas Aura, Pekka Nikander and J. Leiwo. DOS-resistant 1174 Authentication with Client Puzzles. 1176 [RFC2404] Madson and Glenn, "The Use of HMAC-SHA-1-96 within ESP 1177 and AH," RFC 2404, November 1998. 1179 [RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless 1180 Address Autoconfiguration in IPv6," RFC 3041. 1182 [SHA1] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA-1)," 1183 RFC 3174, September 2001. 1185 [WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress", 1186 http://www.cs.ucsd.edu/users/bsy/dobbertin.ps 1188 Authors' addresses 1190 Questions about this document may be directed to: 1192 Gabriel Montenegro 1193 Sun Microsystems Laboratories, Europe 1194 29, chemin du Vieux Chene 1195 38240 Meylan, FRANCE 1197 Voice: +33 476 18 80 45 1198 E-Mail: gab@sun.com 1199 Claude Castelluccia 1200 INRIA Rhone-Alpes 1201 655 avenue de l'Europe 1202 38330 Montbonnot Saint-Martin 1203 FRANCE 1204 email: claude.castelluccia@inria.fr 1205 phone: +33 4 76 61 52 15 1206 fax: +33 4 76 61 52 52 1208 Copyright (c) The Internet Society (2000). All Rights Reserved. 1210 This document and translations of it may be copied and furnished to 1211 others, and derivative works that comment on or otherwise explain it 1212 or assist in its implementation may be prepared, copied, published 1213 and distributed, in whole or in part, without restriction of any 1214 kind, provided that the above copyright notice and this paragraph are 1215 included on all such copies and derivative works. However, this 1216 document itself may not be modified in any way, such as by removing 1217 the copyright notice or references to the Internet Society or other 1218 Internet organizations, except as needed for the purpose of 1219 developing Internet standards in which case the procedures for 1220 copyrights defined in the Internet Standards process must be 1221 followed, or as required to translate it into languages other than 1222 English. 1224 The limited permissions granted above are perpetual and will not be 1225 revoked by the Internet Society or its successors or assigns. 1227 This document and the information contained herein is provided on an 1228 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1229 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1230 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1231 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1232 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1234 Changes 1236 Changes between version 01 and 02: 1238 o Cosmetic editorial changes, reorganization, etc. 1240 o Added more details on SKey derivation to the protocol overview 1241 section. 1243 o Added a terminology section. 1245 o Specified more fully the sucvP protocol, which means SUCV is 1246 now independent of HIP. 1248 o Added a section on extensions for constrained devices. 1250 o Added a section on Privacy considerations.