idnits 2.17.1 draft-montenegro-sucv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 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 463: '...correspond nodes MUST get the assuranc...' RFC 2119 keyword, line 468: '...correspond nodes SHOULD get the assura...' RFC 2119 keyword, line 547: '...U. This message MUST be signed by the...' RFC 2119 keyword, line 567: '...th a new interface identifier, it MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 417 has weird spacing: '...bits of regis...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MIPv6' is mentioned on line 116, but not defined == Unused Reference: 'RFC3041' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'WeakMD5' is defined on line 655, 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' -- 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' == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-addr-arch-v3-05 -- Possible downref: Normative reference to a draft: ref. 'MIPPRIV' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 == Outdated reference: A later version (-06) exists of draft-bradner-pbk-frame-00 ** Downref: Normative reference to an Informational draft: draft-bradner-pbk-frame (ref. 'PBK') ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. 'WeakMD5' Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 10 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 April, 2001 5 Statistically Unique and Cryptographically Verifiable Identifiers 6 and Addresses 7 draft-montenegro-sucv-00.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 Comments should be submitted to the HIP and Mobile IP mailing lists 15 at hipsec@mail.freeswan.org and mobile-ip@sunroof.eng.sun.com, 16 respectively. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as ``work in 29 progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document addresses the identifier ownership problem. It 40 does so by using characteristics of Statistic Uniqueness and 41 Cryptographic Verifiability (SUCV) of certain entities which 42 this document calls SUCV Identifiers (SUCV ID's). This note 43 also proposes using these SUCV characteristics in related 44 entities called SUCV Addresses in order to severely limit 45 certain classes of denial of service attacks and hijacking 46 attacks. SUCV addresses are particularly applicable to solve the 47 'address ownership' problem that severely undermines confidence 48 in mechanisms like Binding Updates in Mobile IP for IPv6. 50 Table of Contents 52 1.0 Introduction .................................................. 3 53 2.0 Related Issues ................................................ 3 54 2.1 Address Ownership .......................................... 3 55 2.2 Purpose Built Keys [PBK] ................................... 4 56 3.0 Overview of the Proposal ...................................... 4 57 4.0 Statistical Uniqueness and Cryptographic Verifiability 58 (SUCV) ............................................................ 5 59 4.1 SUCV ID's .................................................. 6 60 4.2 SUCV ID's versus Addresses ................................. 7 61 4.3 SUCV Addresses ............................................. 8 62 4.4 Hash ID Size Considerations ................................ 8 63 5.0 HIP IPv6 Accomodation Mode .................................... 9 64 6.0 Use of SUCV Addresses for Mobile IPv6 ......................... 11 65 6.1 Protocol Overview .......................................... 12 66 7.0 Security Considerations ....................................... 14 67 8.0 Conclusions ................................................... 14 68 References ........................................................ 14 69 Authors' addresses ................................................ 15 70 1.0 Introduction 72 This document addresses the identifier ownership problem 73 [ADDROWN] by using characteristics of Statistic Uniqueness and 74 Cryptographic Verifiability (SUCV) of certain entities which 75 this document calls SUCV Identifiers (SUCV ID's). This note 76 also proposes using these SUCV characteristics in related 77 entities called SUCV Addresses in order to severely limit 78 certain classes of denial of service attacks and hijacking 79 attacks. SUCV addresses can solve the 'address ownership' 80 problem that severely undermines confidence in mechanisms like 81 Binding Updates in Mobile IP for IPv6. 83 2.0 Related Issues 85 2.1 Address Ownership 87 [ADDROWN] argues that there is a fundamental problem in handling 88 operations like Binding Updates (BU's) in Mobile IP for IPv6 89 [MIPv6], source routing, etc) that allows hosts to modify how 90 other hosts route packets to a certain destination. The problem 91 is that these operations can be misused by rogue nodes to 92 redirect traffic away from its legitimate destination. 93 Authentication does not solve this problem. Even if a node 94 unequivocally identifies itself, this has no bearing on its 95 rights to modify how packets to any given address are routed. 96 This is true even if its packets currently seem to emanate from 97 the address in question. This last point is obvious if one 98 considers DHCP leased addresses. It is imperative not to allow 99 any node to redirect traffic for a DHCP address for which it 100 held a valid lease previously. This would allow it to hijack 101 traffic meant for the current valid user of the address in 102 question. Hence, protection against hijacking of valid addresses 103 requires cryptographic authorization for operations that modify 104 routing (BU's, source routing, etc). One way to show 105 authorization is by showing that the requesting node owns the 106 address for which routing information is being altered. Quoting 107 [ADDROWN]: 109 Currently there exists no specified mechanism for proving 110 address ownership in Internet-wide scale. 112 2.2 Purpose Built Keys [PBK] 114 Purpose built keys [PBK] have been proposed as a foundation for 115 solving scaling and cost concerns associated with some uses of 116 BU's [MIPv6]. It has also been suggested that such keys [PBK] 117 can solve the authorization problem that is at the heart of the 118 address ownership issue. 120 The proposal is succintly to: 122 1. Generate a temporary public/private pair 124 2. Generate an EID = hash(public component) 126 a. the initiator sends EID to responder along with initial 127 protocol exchanges. 129 b. the initiator sends public component to responder along 130 with subsequent exchanges. 132 3. The initiator sends the BU and its EID signed with its 133 private key to the responder. 135 Notice that the exchange at step 2 must be secure in order to 136 avoid intruder-in-the-middle attacks, but it is an improvement 137 over cookies. 139 Several problems linger: 141 1. This does NOT really address the address ownership problem of 142 any publicly routable addresses 144 2. It is not specified how the EID and public component of the 145 PK are sent by the initiator to the responder 147 3. Preventing or limiting hijacking and intruder-in-the-middle 148 attacks depend on this sequence if not clearly specified. 150 By the time the issues are worked out, [PBK] will look very 151 similar to an existing proposal [HIPARCH]. Because of this, it 152 may be simpler to base a solution on HIP. 154 3.0 Overview of the Proposal 156 We assume that we have a network in which the nodes inherently 157 distrust each other, and in which a global or centralized PKI 158 (Public Key Infrastructure) or KDC (Key Distribution Center) is 159 not available. 161 The goal is to arrive at some fundamental assumptions about 162 trust on top of which one can build some useful peer-to-peer 163 communication using opportunistic security. 165 But in such a network, is there a default rule we can follow 166 safely? We posit this is it: 168 Default Trust Rule: 170 Redirect operations are allowed only with addresses which 171 are bound (via a cryptographically sound binding) to the 172 requesting entity. 174 The above rule (to be refined later) constitutes the only rule 175 that operates by default, allowing any other more dangerous 176 operation only if authorized by strong cryptographic 177 mechanisms. 179 Furthermore, we suggest it be based on HIP for the following 180 reasons: 182 - HIP provides the types of identifiers required by the above 183 rule. 185 - The HIP protocol handshake [HIPPROT] is a foundation for a 186 very solid sequence resistant to denial-of-service attacks. 188 Nevertheless, this document proposes a specific use or 'profile' 189 of HIP as applied to environments without DNS (particularly 190 secure DNS), a centralized PKI, or a Key Distribution Center. 191 Rather, we favor the opportunistic mode in HIP [HIPIMPL], and 192 adapt and apply it to Mobile IPv6 (as detailed below). In order 193 not to hinder deployment, a primary consideration has been to 194 minimize the modifications of existing protocols and network 195 support. 197 Furthermore, at the end of this document we note that there are 198 other areas that can benefit from similar adaptations of HIP's 199 opportunistic mode. Their details, however, are left for further 200 exploration. 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? 206 Notice that usual owner verification relies on a third party to 207 provide this function. 209 In this proposal, the principal self-generates a private/public 210 key pair. It uses the public key as its identity and proves its 211 ownership by signing it with its private key. The recipient 212 verifies the signature, and, consequently, the ownership of the 213 identity. 215 4.1 SUCV ID's 217 It is much more practical for protocols to use fixed length 218 identifiers (representations of identities). Because of this, we 219 do not use the public key itself as the identifier, but its hash 220 (as in HIP). 222 These identifiers have a strong cryptographic binding with their 223 public components (of their private-public keys). This is 224 exactly the purpose that certificates have. Let's call them 225 Statistically Unique Cryptographically Verifiable ID's, or SUCV 226 ID's. 228 Because of this, once a CN obtains information about one of 229 these identifiers, it has a strong cryptographic assurance about 230 which entity created it. Not only that, it knows that this 231 identifier is owned and used exclusively by only one node in the 232 universe: its peer in the current exchange. Thus, it is safe to 233 allow that peer to effect changes (via BU's, for example) on how 234 this address or identifier is routed to. Notice that with 235 publically routable addresses, this assurance is much harder to 236 arrive at, given that the address may be 'loaned' to (not owned 237 by) the peer in question, perhaps thanks to the good service of 238 a DHCP server. 240 Despite the fact that currently there is no way to prove address 241 ownership in the Internet, these considerations lead to the 242 following fundamental assumption: 244 Default Trust Rule 246 Redirect operations are only allowed to affect routing for 247 entities which have the SUCV property. 249 The above constitutes perhaps the only rule that operates by 250 default, allowing any other more dangerous operation only if 251 authorized by strong cryptographic mechanisms 253 4.2 SUCV ID's versus Addresses 255 What should one use: pure identifiers with no routing 256 significance or addresses? 258 For example, in the Mobile IPv6 case, a node starts using its 259 home address, and issues binding updates as it moves. 261 With a home address that is not an SUCV ID it is never evident 262 to the CN that whoever was sitting on this address actually owns 263 it. At the very most, the mobile node can prove that at some 264 point it was sitting on a certain address, and later it can 265 prove it is still the same node, but now sitting on another 266 address. 268 But it cannot prove ownership. Ignoring this subtle distinction 269 leads to DOS and hijacking attacks. 271 Problems may also arise because of honest mistakes in 272 configuration. For example, say node A was originally sitting on 273 CoA, and then moved on to CoA'. Suppose it then asks its CN's 274 to redirect traffic to CoA'. In the meanwhile, the original 275 CoA may have been assigned to another node B, perhaps by the 276 DHCP server that rightfully 'owns' that address. The result is 277 that now traffic meant for B has been redirected to A at its new 278 location. 280 Relying on ingress filtering may limit the risk, but 281 essentially, the only way for a node to prove ownership of an 282 identifier (in the absence of any other centralized or global 283 mechanism), is for it to prove that it created this 284 statistically unique series of bits. 286 The intent is to use an identifier instead of an address. Using 287 identifiers that satisfy the SUCV conditions outlined above, it 288 is possible to gain the tremendous advantage that other nodes 289 can safely believe the node when it claims ownership of that 290 identifier. Hence they can safely heed its redirects when it 291 says that it is now available at some different CoA (and later 292 at another). Furthermore, you do not rely on ingress filtering 293 to limit exposure. 295 A major advantage to using an address is that the data traffic 296 need not carry extra information in the packet to guarantee 297 proper delivery by routing. Because of this it is advantageous 298 to create addresses that are both routable and satisfy the SUCV 299 property: SUCV addresses. 301 Another advantage to using an SUCV address is that this address 302 can be registered in the DNS and the host does not have to worry 303 about communicating securely this identifier to its correspondent 304 node. The correspondent node will just get it from the DNS. 306 4.3 SUCV Addresses 308 In IPv6, addresses that satisfy the SUCV property may be 309 obtained as follows: 311 - use the top 64 bits from your routing prefix (as in rfc3041) 313 - define the bottom 64 bits as an SUCV ID (called the HID or 314 'hash' ID). Use these 64 bits instead of the 'interface 315 identifier' in IPv6 [IPV6ADDR]. 317 The resultant 128 bit field is an identifier that is also 318 routable, avoiding the need for taking extra space in the packet 319 by sending routing options. Notice that even after moving, it is 320 possible to reuse the 'HID' portion of the address with the new 321 network prefix at the new location. Thus it is possible to reuse 322 the HID with different CoA's. 324 Nevertheless, by snooping on binding updates, it is possible for 325 an attacker to learn the original network prefix used by the 326 home address. This tells an eavesdropper where this home address 327 began to be used, and to which network it belongs, potentially 328 important information. 330 On the other hand, if you use a 'pure' SUCV ID (without any 331 routing significance), then your packets will always need extra 332 information somewhere to assure they are routed properly. 333 Eavesdroppers may still know where that identity is at any 334 particular point in time. But at least they will not know where 335 (under what prefix) that identity began to be used. 337 For further details on SUCV address please refer to section 338 5.0. 340 4.4 Hash ID Size Considerations 342 In SUCV addresses, one of the lower 64 bits is reserved as the 343 local/universal bit (the 'u' bit), so only 63 bits are actually 344 usable as a hash. 346 Suppose the hash function produces an n-bit long output. If we 347 are trying to find some input which will produce some target 348 output value y, then since each output is equally likely we 349 expect to have to try 2^(n-1) possible input values on average. 351 If we are trying to find a collision, then by the birthday 352 paradox we would expect that after trying 1.2*2^n/2 possible 353 input values we would a 50% probability of collision [BIRTH]. 355 So if n=63, you need 1.2*2^31.5 i.e. 3.64*10^9 tries on average 356 before having a collision. This is acceptable especially if you 357 consider that this collision is actually harmfull only if the 2 358 hosts (that collide) are in the same site (i.e. they have the 359 same network prefix), and have the same correspondent nodes. 360 This is very unlikely. Additionally, if the collision is not 361 deliberate the duplicate address detection (DAD) will detect 362 it. 364 If an attacker wishes to impersonate a given SUCV address, it 365 must attempt 2^62 (i.e. approximately 4.8*10^18) tries to find a 366 public key that hashes to this SUCV address. If the attacker 367 can do 1 million hashes per second it will need 142,235 years. 368 If the attacker can hash 1 billion hashes per second it will 369 still need 142 years 371 If we consider that the SUCV Addresses are renewed every 24 372 hours (as suggested in RFC3041), an attacker would then be able 373 to hash 5.3*.10^13 hashes/second in order to be able to find a 374 public key that hashes to the SUCV HID of a given host... 376 Note that the previous analysis only considers the cost of 377 computing the hash of the public key. Prior to this step, an 378 attacker must also generate a valid (public, private) key pair. 379 This is also a very computionally expensive operation. 381 As a conclusion SUCV addresses as used in this document provide 382 more than enough security. 384 5.0 HIP IPv6 Accomodation Mode 386 Using these ID's or addresses depends on also communicating 387 safely the SUCV portion, and this, in turn is dependent on the 388 packet sequencing, etc. These concerns are not addresses at all 389 in the PBK draft. On the other hand, HIP includes mechanisms and 390 detailed considerations in this regard (protection against 391 replay, DOS and MITM attacks). This is why this note proposes 392 that a solution be drafted based heavily on HIP [HIPARCH, 393 HIPPROT, HIPIMPL]. 395 To obtain an IPv6 SUCV address, we define a HIT-64 format and 396 use its lower 64 bits to form the relevant IPv6 addresses (this 397 constitutes HIP's IPv6 accomodation mode). So, for example, the 398 HIT-64 is used to form global aggregatable addresses which start 399 thus [IPV6ADDR]: 401 Aggregatable Global Unicast Addresses 001 403 As well as to derive link-local and site-local addresses which 404 start thus: 406 Link-Local Unicast Addresses 1111 1110 10 407 Site-Local Unicast Addresses 1111 1110 11 409 The HIT-64 format (section 5.2 of [HIPARCH]) is defined as 410 follows: 412 - first 64 bits: 413 - Bit 0 is one 414 - HAA field (next 63 bits) formed as follows: 415 - RAA: 23 bits of registered assigning authority assigned 416 by ICANN (suggested value: 0) 417 - RI: 40 bits of registered identity assigned 418 sequentially by the RAA. (suggested value: 0) 419 - last 64 bits: 420 - derived from a hash of the host identity 421 - used as the interface identifier in IPv6 addresses 423 The IPv6 accomodation mode consists in using a HIT-64 to form an 424 IPv6 address. 426 A HIT-64 derived IPv6 Aggregatable Global Unicast Address 427 (RFC2374) is formed as follows: 429 - top 64 bits: as per the valid prefix at the link the device is on 431 - bottom 64 bits: interface identifier obtained by taking the 432 last 64 bits of the above HIT-64, and setting bit 6 (the 433 left-most bit is numbered 0) to one. This creates an 434 interface identifier with universal significance. 436 From this IPv6 address, other non-global scope addresses are 437 derived. For example, a node uses the bottom 64 bits to form 438 the site-local and link-local addresses on the same prefix 439 (link) as the aggregatable global unicast address 440 (alternatively, if a non-global address is formed first, it is 441 used to form the others). Furthermor, if this address is used in 442 conjuction with Mobile IP for IPv6 [MIPV6], the Home Agent uses 443 the Prefix Length information within a "home registration" 444 binding update to form the corresponding link-local and 445 site-local addresses for the Mobile Node, and defend them for 446 purposes of Duplicate Address Detection. 448 Any of the addresses formed as described above constitute SUCV 449 addresses. 451 6.0 Use of SUCV Addresses for Mobile IPv6 453 In Mobile IPv6, a mobile host obtains a new address, a CoA, each 454 time it moves. It then registers the binding between its home 455 address and its new CoA with its home agent and correspond 456 nodes. Correspondent nodes in posession of such a binding can 457 send packets to the mobile node directly at its current CoA. 458 Instead, sending packets to the mobile node's home address 459 implies sub-optimal routing as they first proceed to the mobile 460 node's home link, where they are intercepted by the home agent 461 and forwarded to the mobile node's CoA. 463 However, the correspond nodes MUST get the assurance the home 464 address actually belongs to the mobile node. Otherwise, an 465 attacker could send a binding update with a victim's home 466 address, thus redirecting all the victim's packets. 468 Additionally, the correspond nodes SHOULD get the assurance that 469 the CoA actually belongs to the mobile node. Otherwise, any 470 host could use the address of another victim as its CoA. The 471 packets that were initially addressed to the first victim will 472 then be sent to the victim. Depending on how much traffic this 473 implies, this could be used as a denial-of-service attack. 475 These attacks can be avoided if, in order to accept and process 476 a binding update, a correspond host requires a mobile node to 477 prove ownership of its home address and its CoA. If ownership is 478 proven, the correspond node has the assurance that the mobile 479 node is not hijacking some other node's address, and that it is 480 not directing packets at some other node's one's address. 482 The solution that we propose is that a mobile node uses the 483 method describes previously to configure its Home Address and 484 its CoA (the same HID and public/private key pair is used for 485 the home address and the CoA). 487 By verifying the signature and the HID, the correspond host has 488 the assurance that the mobile host is not using some other 489 node's home address and CoA. 491 As described in [MIPPRIV], the use of SUCV Identifier for Mobile 492 IPv6 is useful when a mobile node wishes to hide its home 493 address. Indeed the home address can reveal a lot of information 494 about a mobile node. [MIPPRIV] proposes to use a random 495 Temporary Mobile Identifier (TMI) in place of the home address. 496 By using a SUCV ID as a TMI, a mobile node will be able to prove 497 ownership of the TMI and avoid hijacking attacks. 499 6.1 Protocol Overview 501 The following protocol sequence is based on [HIPPROT]. However, 502 it has been modified for Mobile IPv6 based on the following 503 considerations: 505 - the goal is to secure binding updates sent by a mobile node to 506 an arbitrary correspondent node 508 - the protocol should not rely on a third party (i.e. a home 509 agent, mobility anchor point, global PKI, central key 510 distribution center, etc) 512 - HIP is used for 'opportunistic security' so there is no 513 reliance on DNS 515 - not all nodes need to use SUCV addresses, only those that wish 516 their binding updates to be heeded (mobile nodes) 518 - not all nodes need to verify the validity of SUCV addresses, 519 only those that wish to safely heed binding updates in order 520 to populate its binding cache 522 The proposed protocol that a mobile host uses to send a BU to its CN 523 is the following: 525 msg1- The MN sends a BU HELLO message (just to initiate the 526 exchange) to its correspond node. This message 527 contains a Nonce, N1. 529 msg2- The CN replies with a message that contains the 530 following: N1, HIP Cookie request, SPI, Diffie-Hellman 531 value, ESP transform (list of supported ESP modes). 533 In order to defend against msg1 storms, a host might 534 use the same DH value for a period of time. A HIP 535 cookie request contains a random number I, the hash of 536 I concatenated with a random value J, and K, the number 537 of bits that must match as per [HIPPROT]. 539 When the MN receives msg2, it verifies that the nonce 540 N1 is the same than the one that was sent in the msg1. 541 It then computes the HIP Cookie reply by finding J and 542 replies with msg3. 544 msg3- The MN replies with a message that contains the 545 following: HIP Cookie reply, Public key, 546 Diffie-Hellman value, ESP transform (the selected ESP 547 modes) and BU. This message MUST be signed by the MN 548 with its private key. 550 Note that the home address contained in the BU is 551 either a SUCV Address or a SUCV Identifier. The CoA is 552 either a SUCV Address or a regular address. By using a 553 CoA SUCV address, a CN has the assurance the the CoA 554 belongs to the MN and has not been stolen. 556 When the CN receives the msg3, it can verify the ownership of 557 the Home and CoA addresses and authenticate the BU because it is 558 signed. 560 The MN and CN can then derive a session key (using the ephemeral 561 D-H value), and use it in conjunction with IPSec to authenticate 562 other subsequent BU (if any) as it is done in current MIPv6. 564 As long as the MN uses the same HID interface identifier for its 565 CoA, it does not have to prove the CoA ownership and IPSec 566 authentication mechanism is fine. If for any reason the MN 567 configures its CoA with a new interface identifier, it MUST 568 restart the whole protocol (i.e. msg1, msg2, msg3). 570 This proposal does not require any prerequisite between the MN 571 and the CN. By using a Home Address SUCV, that is generated by 572 hashing a public key, and signing message 2 with the 573 corresponding private key a MN can prove the ownership of its 574 Home Address. 576 Because our proposal is heavily based on HIP, it is resistant to 577 denial-of service attacks. Because our proposal is based on 578 SUCV Home Address, it is resistant to Man-in the Middle 579 attacks. An attacker won't be able to redirect the traffic 580 destined to a particular SUCV Home Address unless it can find a 581 (public, private) key pair such that the hash of the public 582 component is equal to the least significant 64 bits in the SUCV 583 Home Address. This is computationally infeasable (see section 584 4.4). 586 7.0 Security Considerations 588 The technique introduced in this document is meant to increase 589 the level of security in the Internet. 591 This document explains the concept of statistical uniqueness and 592 cryptographic verifiability (SUCV), specially as it applies to 593 IPv6 addresses in the form of SUCV addresses. The SUCV 594 characteristics are used to prove address ownership, thus 595 preventing a class of attacks which exploit this fault in many 596 types of commands. In particular, commands which alter how an 597 address is treated by peers or by the routing infrastructure can 598 be used to launch denial of service attacks or hijacking 599 attacks. Proving address ownership eliminates these attacks. 600 However, given that this technique is meant to be used primarily 601 in the absence of global infrastructures, the possibility of man 602 in the middle attacks does remain. Nevertheless, since the 603 protocol used here is based on HIP, these attacks are limited by 604 the use of cookies and client puzzles. 606 8.0 Conclusions 608 The present document focuses on the use of the SUCV property to 609 enhance the security of exchanges between an arbitrary pair of 610 peers in the absence of any third party. In particular, we 611 propose that SUCV addresses be used to solve the issue of 612 securing binding updates in Mobile IPv6. 614 Recent micro-mobility management protocols (such as HAWAII or 615 Cellular IP) propose to use specialized path setup schemes which 616 install host-based forwarding entries in specific routers to 617 support intra-domain micro-mobility. In order to avoid trafic 618 redirection, routers need to verify the ownership of an address 619 used by a mobile host before adding an entry for that particular 620 mobile host in its routing table. SUCV addresses or identifiers 621 also can be very useful for that purpose. 623 References 625 [ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6", 626 draft-nikander-ipng-address-ownership-00.txt, February 2001. 628 [BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html 630 [HIPARCH] Bob Moskowitz, "HIP Architecture," 631 draft-ietf-moskowitz-hip-arch-02.txt 633 [HIPIMPL] Bob Moskowitz, "HIP Implementation," 634 draft-moskowitz-hip-impl-01.txt 636 [HIPPROT] Bob Moskowitz, "Host Identity Payload and Protocol," 637 draft-moskowitz-hip-03.txt 639 [IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture," 640 draft-ietf-ipngwg-addr-arch-v3-05.txt 642 [MIPPRIV] Castelluccia, Dupont, "A Simple Privacy Extension for 643 Mobile IPv6," draft-castelluccia-mobileip-privacy-00.txt, 644 February 2001. 646 [MIPV6] C. Perkins, "Mobile IP for IPv6,", 647 draft-ietf-mobileip-ipv6-13.txt 649 [PBK] Bradner, Mankin, Schiller, "Purpose Built Keys," 650 draft-bradner-pbk-frame-00.txt 652 [RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless 653 Address Autoconfiguration in IPv6," RFC 3041. 655 [WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress," 656 http://www.cs.ucsd.edu/users/bsy/dobbertin.ps 658 Authors' addresses 660 Questions about this document may be directed to: 662 Gabriel Montenegro 663 Sun Microsystems Laboratories, Europe 664 29, chemin du Vieux Chene 665 38240 Meylan, FRANCE 667 Voice: +33 476 18 80 45 668 E-Mail: gab@sun.com 670 Claude Castelluccia 671 INRIA Rhone-Alpes 672 655 avenue de l'Europe 673 38330 Montbonnot Saint-Martin 674 FRANCE 675 email: claude.castelluccia@inria.fr 676 phone: +33 4 76 61 52 15 677 fax: +33 4 76 61 52 52 679 Copyright (c) The Internet Society (2000). All Rights Reserved. 681 This document and translations of it may be copied and furnished to 682 others, and derivative works that comment on or otherwise explain it 683 or assist in its implementation may be prepared, copied, published 684 and distributed, in whole or in part, without restriction of any 685 kind, provided that the above copyright notice and this paragraph are 686 included on all such copies and derivative works. However, this 687 document itself may not be modified in any way, such as by removing 688 the copyright notice or references to the Internet Society or other 689 Internet organizations, except as needed for the purpose of 690 developing Internet standards in which case the procedures for 691 copyrights defined in the Internet Standards process must be 692 followed, or as required to translate it into languages other than 693 English. 695 The limited permissions granted above are perpetual and will not be 696 revoked by the Internet Society or its successors or assigns. 698 This document and the information contained herein is provided on an 699 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 700 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 701 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 702 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 703 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.