idnits 2.17.1 draft-haddad-privacy-omipv6-anonymity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (October 23, 2006) is 6394 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) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-06 -- No information found for draft-ietf-mipshop-omipv6-cga-cba - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OMIPv6' == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-02 -- No information found for draft-ietf-ipv6-privacy-address-v2 - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: April 26, 2007 Ericsson Research 5 F. Dupont 6 CELAR 7 M. Bagnulo 8 UC3M 9 H. Tschofenig 10 Siemens AG 11 October 23, 2006 13 An Anonymity and Unlinkability Extension for OMIPv6 14 draft-haddad-privacy-omipv6-anonymity-02 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 26, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 The "Optimized Mobile IPv6 with CBA" (OMIPv6) protocol specifies a 48 new route optimization (RO) mechanism, which offers better security, 49 less signaling messages and reduces the handoff latency. This 50 document describes a new extension to be added to the OMIPv6 protocol 51 in order to provide the anonymity and the unlinkability aspects at 52 the IP layer. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction 72 Optimized Mobile IPv6 [OMIPv6] protocol specifies a new route 73 optimization (RO), which reduces the amount of signaling messages, 74 the handover latency and improves the overall security. 76 However, OMIPv6 protocol lacks privacy support, namely anonymity or 77 pseudonymity, and unlinkability aspects. Supporting these privacy 78 aspects in OMIPv6 would allow a mobile user to move outside its home 79 network without disclosing its real IPv6 home address nor linking its 80 different moves together, and thereby preventing eavesdroppers from 81 the ability to correlate its actions at the IP layer. 83 This document describes privacy extensions to the OMIPv6 protocol. 85 2. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [TERM]. 91 3. Glossary 93 Anonymity 95 Anonymity ensures that a user may use a resource or service 96 without disclosing the user's identity. 98 Anonymity in wireless networks means that neither the mobile node 99 nor its system software shall by default expose any information, 100 that allows any conclusions on the owner or current use of the 101 node. 103 Consequently, in scenarios where a device and/or network 104 identifiers are used (e.g., MAC address, IP address), neither the 105 communication partner nor any outside attacker should be able to 106 disclose the relationship between the respective identifier and 107 the user's identity. 109 Pseudonymity 111 Pseudonymity is a weaker property related to anonymity. It means 112 that one cannot identify an entity, but it may be possible to 113 prove that two pseudonymous acts were performed by the same 114 entity. 116 Unlinkability 118 Two events are unlinkable if they are no more and no less related 119 than they are related concerning the a-priori knowledge. 121 Unlinkability ensures that a user may make use of resources or 122 services without others being able to link the use of these 123 services together. 125 In hiding the mobile node's current location, unlinkability 126 feature removes any possible correlation between two successive IP 127 handovers performed by the same mobile node. 129 For more information about privacy aspects and location privacy 130 please refer to [MOMIPRIV]. 132 4. Problem Statement 134 OMIPv6 protocol introduces a new route optimization (RO) mode, which 135 significantly reduces the load of signaling messages, i.e., mainly by 136 eliminating the HoTI/HoT messages, offers a semi-permanent security 137 association (SA) between the mobile node (MN) and the correspondent 138 node (CN) and improves the overall security of the communication. 140 However, OMIPv6 allows the CN and any potential eavesdropper located 141 on the path between the MN and the CN to first identify the mobile 142 node via its IPv6 Home Address (HoA) and to trace its movements in 143 real time across the Internet, thus seriously violating its privacy. 144 Such scenario is feasible by simply looking into the Binding Update 145 (BU) message(s) sent by the MN to the CN, which carries among other 146 parameters, the MN's IPv6 Home Address (HoA) and its new current 147 topological location, i.e., disclosed in its IPv6 care-of address 148 (CoA). 150 In addition to the BU message(s), the eavesdropper can learn and 151 trace the MN's movements by looking into the data packets exchanged 152 with the CN. In fact, the main RO mode (detailed in [MIPv6]) defined 153 two mobility extension headers, which carry the MN's home address. 154 The first one is the Home Address Option (HAO) and is inserted in 155 each data packet sent by the MN to the CN on the direct path. The 156 second one is a Routing Header (RH) and is inserted in each data 157 packet sent by the CN to the MN on the direct path. 159 Based on the above, it appears that in order to keep the exchange of 160 data packets between the two endpoints flowing on the direct path, 161 only the home address can be hidden from both the CN and any 162 potential eavesdropper(s) located on the direct path. 164 Consequently, any solution for the privacy problem in OMIPv6 MUST 165 prevent the CN from falling back to the bidirectional (BT) mode 166 (detailed in [MIPv6]) under any circumstance(s), since data packets 167 sent by the CN are addressed to the MN's HoA. 169 However, replacing the real MN's HoA with a static/dynamic pseudo-HoA 170 does not solve the entire privacy problem as described above. In 171 fact, using static/dynamic pseudo-HoA(s) can still allow the 172 eavesdropper to correlate between MN's movements across the Internet, 173 thus easily breaking the unlinkability feature. Such correlation can 174 be accomplished by simply tracing the sequence number carried by each 175 BU message. The seriousness of such correlation is tightly related 176 to how difficult is for the eavesdropper to discover the MN's real 177 HoA (e.g., based on prior knowledge and/or other identifier(s), which 178 are already known or can be discovered at a further stage, etc). In 179 fact, learning the MN's HoA can reveal all its pseudo-HoAs and their 180 corresponding CoAs as well as the exact time of each movement. 182 The unlinkability feature can also be broken if an eavesdropper is 183 able to correlate between two data packets exchanged between the MN 184 and the CN and carrying different CoAs, but associated with the same 185 pseudo-HoA. In this case, the correlation may also reveal the exact 186 time of the MN's movement(s), regardless of the BU message content. 188 In addition to the correlation based on tracing data packets only, 189 which provides the possibility to correlate between different 190 movements, another correlation becomes possible between the signaling 191 messages and the data packets. In fact, tracing the BU messages in 192 addition to the data packets can also help the eavesdropper correlate 193 between the MIPv6 signaling messages and the data packets (namely the 194 pseudo-HoA and/or CoA carried by the BU message with the address(es) 195 and/or pseudo-address(es) carried by the data packet). 197 Consequently, we argue that any solution for privacy related to the 198 network layer mobility only should also offer the unlinkability 199 feature by fulfilling the following requirements: 201 o prevent disclosing the MN's HoA in any BU message. 203 o prevent any correlation between BU messages by avoiding using the 204 same pseudo-HoA in more than one BU message. 206 o prevent any correlation between the BU messages via the sequence 207 number. 209 o prevent any correlation between data packets exchanged with the 210 current CoA and the next BU message sent after performing an IP 211 handover. 213 o prevent any correlation between data carried by the BU message and 214 data packets exchanged directly after sending/receiving BU/BA 215 message(s). 217 Finally, it should be noted that any potential solution, which 218 addresses privacy as motivated above, should take into consideration 219 the scenario where a mobile node starts communicating with a CN from 220 its home network before switching to a foreign network(s). 222 5. Proposed Solution 224 Our suggested solution can be used regardless of whether the MN is 225 establishing its session from its home network or from a visited 226 network. It consists of three components: 228 1. the "P" bit that is carried in the Pre-Binding Update (PBU), the 229 Pre-Binding Test (PBT) and the Binding Update (BU) message; this 230 bit demands additional processing guidelines (including special 231 sequence number handling). 233 2. replacing the home address inserted in the HAO with an ephemeral 234 identifier. 236 3. associating the interface identifier (iid) of the MN's home 237 address with the statistically unique cryptographically-Based 238 Identifiers (described in [CBID]). 240 As a first step, a Pre-Binding Update (PBU) message is sent directly 241 from the MN to the CN. The PBU message carried a newly introduced 242 Privacy (P) bit set and thereby asks the CN to skip any home address 243 test, and also to avoid any possible fallback to the BT mode during 244 the subsequent data packets exchange. 246 The MN MUST set the "P" bit in the PBU message, regardless of the 247 MN's location (i.e., also if located in its home network), and in the 248 BU message sent after receiving the Pre-Binding Test (PBT) message 249 from the CN. 251 Additionally, the MN MUST replace the home address inserted in the 252 Home Address Option (HAO) with a "Virtual Home Address" (VHoA). The 253 VHoA sent in the first BU message MUST be a statistically unique 254 crypto-based identifier (CBID). Note that using the CBID technology 255 in Mobile IPv6 for privacy purposes has been introduced in [MIPriv]. 257 During the initial signaling messages exchange between the two 258 endpoints, and in order to enable the CN to check if it is still 259 talking to the same MN when receiving the first BU message, the MN 260 MUST insert in the PBU message the value obtained from hashing the 261 VHoA (note that for the initial case, the VHoA is the CBID, thus the 262 value sent in the PBU message is equal to SHA1(CBID)). 264 After receiving the PBU message, the CN computes a challenge from the 265 MN's CoA, the content of the HAO and a local secret. Then it inserts 266 the challenge in the PBT message and sends it to the MN. When the MN 267 gets the PBT message, it sends a BU message carrying the "P" bit, the 268 challenge and the real CBID (i.e., the CBID is inserted in the HAO). 269 Note that the iid of the MN's CoA sent in the PBU and the BU messages 270 SHOULD be generated from hashing the CBID in the following way: 272 iid(CoA) = First(64, SHA1(CBID)) 274 Where: 276 o SHA1 is a hashing function 278 o CBID is a crypto-based identifier 280 o First(size,input) is a function used to indicate truncation of the 281 input data so that only the first bits remain to be used. 283 o iid is the interface identifier 285 Upon receiving the first BU message with the "P" bit set, the CN 286 starts by checking its validity, which is done by hashing the content 287 of the HAO, i.e., the CBID, and comparing the first 64 bits of the 288 resulting hash with the CoA's iid. After that, it will re-compute 289 the challenge and compare it to the one sent in the BU message. The 290 third step after a successful validation would be to create an entry 291 in the BCE for the MN's VHoA and CoA. The CN MUST also generate a 292 long lifetime shared secret (i.e., SKbm) and sends it to the MN in 293 the BA message as described in [OMIPv6]. 295 The presence of the "P" bit in the BU message serves another purpose, 296 which is to request the CN to replace the sequence number carried by 297 the BU message, in its BCE with the "next" value, i.e., the value 298 expected in the next BU message sent by the MN. Such value is called 299 the "Sequence Value" SQV and is used to prevent replay attacks and to 300 allow the CN to identify the MN's corresponding entry in its BCEs 301 when processing a BU message carrying the "P" bit. 303 In OMIPv6, each time the MN sends a BU message, it MUST increase the 304 32-bit sequence number value. When the privacy extensions introduced 305 in this document are used, then both endpoints MUST increment the SQV 306 with a constant value equal to the one obtained from hashing the 307 SKbm. Finally, the increased SQV is hashed, inserted by the MN into 308 the BU message and sent it to the CN. 310 The two entities MUST compute the next SQV (nSQV) in the following 311 way: 313 Khbm = SHA1(SKbm) 315 nSQV = First(32, SHA1((pSQV) | Khbm)) 317 Where: 319 o SKbm is a long lifetime binding management key 321 o Khbm is the hashed binding management key 323 o pSQV is the previous SQV, i.e., SQV sent in the last BU message 324 sent bythe MN and already processed by the CN. 326 o nSQV is the hash value of the next SQV computed during updating 327 the BCE with the BU message carrying the pSQV. 329 The CN MUST compute and store the nSQV during creating or updating 330 the MN's corresponding entry in its BCE, and the MN MUST compute and 331 send a new SQV in all subsequent BU messages sent to the CN. 333 In addition, all subsequent BU messages sent after the first one 334 SHOULD carry each a different VHoA, which is generated from hashing 335 the nCoA, i.e., nVHoA is equal to SHA1(nCoA), sent in the message. 337 However, it should be noted that the CN SHOULD NOT store in the MN's 338 corresponding entry the new CoA (nCoA) and new VHoA (nVHoA) carried 339 in the BU message. In fact, besides computing the nSQV and storing 340 it in the corresponding entry, the CN SHOULD also compute another 341 pair of addresses (CoA, VHoA) to be used in the data packets exchange 342 following the BCE creation or update. These two addresses are called 343 "expected CoA" (eCoA) and "expected VHoA" (eVHoA). 345 The two expected addresses are computed in the following way: 347 iid(eCoA) = First(64, SHA1(Khbm | nCoA Subnet Prefix)) 349 eVHoA = SHA1(eCoA) 351 Where: 353 o nCoA is the MN's care-of address sent in the BU message. 355 o eVHoA is the pseudo-home address carried in the HAO and RH headers 356 in all data packets. 358 The subnet prefix of the nCoA MUST be the same as the one sent by the 359 MN in the BU message (note that this technique is similar to the one 360 defined in [HBA]). As mentioned above, the CN MUST update the MN's 361 entry in its BCE with the eCoA and eVHoA. However, the BA message 362 sent to the MN MUST carry the nCoA and nVHoA. 364 When the MN sends a BU message carrying the "P" bit, the SQV MUST be 365 used alone by the CN to detect the presence of an entry corresponding 366 to the MN in its BCE. If an entry containing the same SQV is found, 367 then the CN SHOULD proceed to check the signature before updating the 368 corresponding entry with the eCoA, eVHoA and nSQV. 370 6. Packet Format 372 This proposal defines a new bit called the Privacy (P) bit to be 373 added to the Pre-BU and BU messages. The MN MUST set the "P" bit in 374 both messages and in all subsequent BU messages as long as it needs 375 to keep its real home IP address undisclosed. 377 When used in the Pre-BU message, the "P" bit indicates to the CN to 378 limit the address test to the CoA only and also to include the VHoA 379 in computing the nonce value sent in the Pre-Binding Test (PBT) 380 message. 382 When used in the BU message, the "P" bit is used for three different 383 purposes. The first one is to ask the CN to use the sequence number 384 to locate the MN's corresponding BCE. The second one is to notify 385 the CN to NOT send any data packet carrying the MN's home pseudo- 386 address, i.e., VHAO, as destination address. 388 The third purpose is to ask the CN to compute the eCoA, the eVHoA, 389 the new SQV and store them in the MN's corresponding BCE. 391 When used in the Pre-BU message, the structure of the message will be 392 as it follows: 394 0 1 2 3 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |P| Reserved | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 + + 401 | | 402 + Care-of Address + 403 | | 404 + + 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 + Pre-Binding Update Cookie + 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 . . 413 . Mobility Options . 414 . . 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The different fields carried in the Pre-BU message are detailed in 419 [OMIPv6]. 421 When used in the BU message, the structure of the message will be as 422 it follows: 424 0 1 2 3 425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Sequence # | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |A|H|L|K|P| Reserved | Lifetime | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 . . 433 . Mobility options . 434 . . 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 The different fields carried in the BU message are detailed in 439 [MIPv6]. 441 7. Privacy Considerations 443 This memo describes an extension, which makes the MN's real identity 444 anonymous for both the CN and any malicious eavesdropper(s) located 445 on the path between the MN and the CN. 447 Our solution aims to present the MN's HoA as any other CoA that the 448 MN may use during its movements across the Internet. However, our 449 solution is based on the assumption that the BU messages exchanged 450 between the MN and its HA are protected with an ESP tunnel according 451 to [MIPv6-IKE] and [MIPv6-IKEv2]. 453 The suggested solution provides the anonymity feature to the MN 454 during exchanging data packets and signaling messages with the CN. 455 It also provides the unlinkability feature during and after 456 performing IP handovers, by making it difficult for an eavesdropper 457 to correlate between two successive IP handoffs performed by the same 458 MN. The unlinkability between these events aims to enhance the 459 anonymity feature. 461 However, it should be noted that the unlinkability protection is 462 limited against eavesdroppers located on the path between the MN and 463 the CN and does not prevent the CN to trace the MN's movements in 464 real time. 466 The suggested solution allows the MN to select when and where the 467 anonymity feature should be activated. But it should be noted that 468 it works only when the MN initiates the session. Actually, when the 469 CN initiates the session, it uses the MN's home address (HoA). In 470 such scenario, the MN can hide its current location from the CN by 471 switching to the bidirectional tunneling mode. 473 It is worth mentioning that the anonymity concept is very much 474 context dependent. In order to quantify anonymity with concrete 475 situations, one would have to describe the system context, which is 476 practically not always possible for large open systems [ANON]. 478 Consequently, the efficiency of the suggested solution is tightly 479 related to two key factors: the diversity and load of the traffic 480 circulating in parallel with the MN's traffic, on the same portion(s) 481 of the direct path, which is monitored by an eavesdropper(s). 483 Finally, the suggested solution strongly recommends using the Privacy 484 Extension proposal [PRIVACY], in configuring the care-of address(es) 485 sent by the MN in all BU messages except for the BU message sent 486 after receiving a PBT message, i.e., in which the CoA is derived from 487 the CBID. 489 8. Security Considerations 491 The suggested solution does not introduce new attacks nor does it 492 amplify existing threats. However, it is important to mention that 493 it makes the switch to the MIPv6 BT mode impossible. 495 The suggested solution aims to hide the mobile user's real identity 496 when moving outside its home network or from its home network to 497 foreign networks. Making the MN anonymous (with regard to the used 498 home address) to potential eavesdroppers may help to prevent attacks, 499 thus improves the overall security. 501 9. References 503 9.1. Normative References 505 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 506 in IPv6", RFC 3775, June 2004. 508 [MIPv6-IKE] 509 Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 510 Protect Mobile IPv6 Signaling Between Mobile Nodes and 511 Home Agents", RFC 3776, June 2004. 513 [MIPv6-IKEv2] 514 Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 515 IKEv2 and the revised IPsec Architecture", Internet 516 Draft, draft-ietf-mip6-ikev2-ipsec-06.txt, April 2006. 518 [OMIPv6] Arkko, J., Vogt, C., and W. Haddad, "Applying 519 Cryptographically Generated Addresses and Credit-Based 520 Authorization to Optimize Mobile IPv6 (OMIPv6)", Internet 521 Draft, draft-ietf-mipshop-omipv6-cga-cba-01, 522 September 2006. 524 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 525 Requirement Levels", RFC 2119, BCP , March 1997. 527 9.2. Informative References 529 [ANON] Pfitzmann et al., A., "Anonymity, Unobservability, 530 Pseudonymity and Identity Management - A Consolidated 531 Proposal for Terminology", Anon Terminology Draft v0.28, 532 May 2006. 534 [CBID] Montenegro, G. and C. Castelluccia, "Cryptographically- 535 Based Identifiers (CBID): Concepts and Applications", ACM 536 Transactions on Information and System Security TISSEC, 537 February 2004. 539 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", Internet 540 Draft, draft-ietf-shim6-hba-02.txt, October 2006. 542 [MIPriv] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple 543 Privacy Extension for Mobile IPv6", Internet 544 Draft, draft-dupont-mip6-privacyext-04.txt, July 2006. 546 [MOMIPRIV] 547 Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, 548 S., and B. Patil, "Privacy for Mobile and Multi-homed 549 Nodes: MoMiPriv Problem Statement", Internet-Draft, draft- 550 haddad-momipriv-problem-statement-03.txt, June 2006. 552 [PRIVACY] Narten, T., Draves, R., and S. Krishnan, "Privacy 553 Extensions for Stateless Address Autoconfiguration in 554 IPv6", 555 Internet-Draft, draft-ietf-ipv6-privacy-address-v2-05.txt, 556 August 2006. 558 Authors' Addresses 560 Wassim Haddad 561 Ericsson Research 562 Torshamnsgatan 23 563 SE-164 80 Stockholm 564 Sweden 566 Phone: +46 8 4044079 567 Email: Wassim.Haddad@ericsson.com 569 Suresh Krishnan 570 Ericsson Research 571 8400 Decarie Blvd. 572 Town of Mount Royal, QC 573 Canada 575 Phone: +1 514 345 7900 576 Email: Suresh.Krishnan@ericsson.com 578 Francis Dupont 579 CELAR 581 Email: Francis.Dupont@point6.net 583 Marcelo Bagnulo 584 UC3M 585 Universidad Carlos III de Madrid 586 Av. Universidad 30 587 Leganes, Madrid 28911 588 Spain 590 Phone: +31 91 6249500 591 Email: Marcelo@it.uc3m.es 592 URI: http://www.it.uc3m.es 594 Hannes Tschofenig 595 Siemens AG 596 Otto-Hahn-Ring 6 597 81739 Munich 598 Germany 600 Email: Hannes.Tschofenig@siemens.com 602 Intellectual Property Statement 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Disclaimer of Validity 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 631 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 632 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 633 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Copyright Statement 638 Copyright (C) The Internet Society (2006). This document is subject 639 to the rights, licenses and restrictions contained in BCP 78, and 640 except as set forth therein, the authors retain all their rights. 642 Acknowledgment 644 Funding for the RFC Editor function is currently provided by the 645 Internet Society.