idnits 2.17.1 draft-dupont-mip6-privacyext-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 427. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 19, 2006) is 6491 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 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-laganier-ipv6-khi-02 == Outdated reference: A later version (-02) exists of draft-haddad-privacy-omipv6-anonymity-00 -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 4305 (Obsoleted by RFC 4835) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Castelluccia 3 Internet-Draft INRIA 4 Expires: January 20, 2007 F. Dupont 5 CELAR 6 G. Montenegro 7 Microsoft 8 July 19, 2006 10 A Simple Privacy Extension for Mobile IPv6 11 draft-dupont-mip6-privacyext-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 20, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This draft presents a simple privacy extension for Mobile IPv6 that 45 prevents eavesdroppers from identifying the packets sent or received 46 from a particular mobile node. This extension also allows a mobile 47 node to hide its identity from correspondent nodes when the mobile 48 node initiates the communication. 50 1. Introduction 52 In Mobile IPv6 [RFC3775], the home address of a mobile node is 53 included in the packets that it sends and receives. 55 As a result any node in the network can identify packets that belong 56 to a particular mobile node (and use them to perform some kind of 57 traffic analysis) and track its movements (i.e., its care-of address) 58 and usage. We propose a solution to prevent such tracking while 59 still using route optimization. 61 In particular our proposal solves the two following problems: 63 - Privacy of mobile client from its correspondent node and from any 64 eavesdroppers in the network: the mobile node connects to a remote 65 node (a server for example) and wants to hide it identity (i.e., 66 its home address) from this node and from any eavesdropper in the 67 network while still being able to move. 69 - Privacy of mobile server from eavesdroppers: the remote node 70 initiates the communication and the mobile node is able to hide 71 its identity (and therefore its locations) from any eavesdropper 72 in the network (but not from the remote node). 74 We do not solve the problem of privacy of a mobile server from its 75 correspondent nodes. In this case a mobile node still needs to 76 reveal its care-of address to its correspondent nodes to ensure 77 optimal routing. If this level of privacy is desired, one possible 78 solution is bi-directional encrypted tunneling via the home agent. 79 Full privacy is then provided at the cost of routing performance. It 80 should be noted that [RFC4140] in revealing the regional care-of 81 address (RCoA) instead of the care-of address might be an other 82 alternative. 84 In this draft we only look at privacy issues in Mobile IPv6 and 85 assume that a mobile node's identity is not revealed by other 86 protocols such as AAA, IKE,...and by the applications (i.e. 87 applications must not include any IP address in their payloads.) 89 2. Problem statement 91 In Mobile IPv6, the home address of a mobile node is included in 92 clear text in the packets it sends and receives. In fact, packets 93 sent by a mobile node includes a home address option that contains 94 its home address. Packets sent by a correspondent node to a given 95 mobile node contains a routing header that includes the mobile home 96 address. As a result, any eavesdropper within the network can easily 97 identify packets that belong to a particular mobile node (and use 98 them to perform some kind of traffic analysis) and track mobile 99 movements and usage. 101 3. Possible solutions 103 Several solutions are possible, all with their limitations: 105 - IPv6 privacy extension: a solution could be to used the privacy 106 extension described in [RFC3041] to configure the home address and 107 the care-of addresses. While this solution represents a marked 108 improvement over the default address configuration methods 109 [RFC2462], and should be used for the home and care-of addresses, 110 we contend that this is not sufficient. [RFC3041] causes nodes to 111 generate global-scope addresses from interface identifiers that 112 change over time, even in cases where the interface contains an 113 embedded IEEE identifier. As a result if [RFC3041] is used to 114 generate the home address, this address will change periodically 115 but the network prefix (64 highest bits) will remain unchanged. 116 This network prefix can still reveal much information about the 117 mobile node's identity to an eavesdropper. This mechanism 118 described in [RFC3041] must be used for the home address and 119 care-of addresses in Mobile IPv6 but one should not rely on it to 120 get full privacy protection. 122 - Home address option encryption: an other solution could be to 123 encrypt the home address option. This solution is not 124 satisfactory because 125 (1) it would require to modify IPsec implementation (security 126 associations should then be indexed with the care-of address 127 and therefore would need to be updated at each movement of the 128 mobile node) and 129 (2) it would make the usage of firewalls difficult (currently 130 firewalls look at the home address option to perform some 131 filtering). 132 Furthermore this solution does not solve the problem of incoming 133 packets that contain a routing header which reveals the home 134 address. 136 - IPsec bi-directional Tunnel (mobile VPN): A solution could be to 137 open a bi-directional IPsec tunnel between the mobile node and its 138 home agent [RFC3024]. This solution has the following 139 disadvantages: 140 (1) addition of extra bandwidth (packets need to be 141 encapsulated) and processing overhead, 142 (2) the routing is suboptimal. 144 4. Our Proposal 146 In our scheme a mobile node uses the privacy extension described in 147 [RFC3041] to configure its home address and care-of addresses. A 148 mobile node must use an interface identifier for its home address 149 that is different from the one used for its care-of addresses. It 150 should also use a new interface identifier when configuring a new 151 care-of address. As a result, it would be more difficult for an 152 eavesdropper to identify a mobile node's identity and track its 153 movement. 155 We also propose to assign to each mobile node a TMI (Temporary Mobile 156 Identifier) that is a 128-bit long random number. This TMI is used 157 by the mobile node's home agent and correspondent nodes to identify 158 the mobile node. This TMI might be used by the correspondent node to 159 index the correspondent IPsec security association to the mobile and 160 might be used by firewalls to do filtering. 162 4.1. Protocol description 164 Two cases must be considered: 166 - Mobile Client (The mobile node initiates the communication). 168 - Mobile Server (the correspondent node initiates the 169 communication). 171 4.1.1. Mobile client 173 The mobile then uses standard Mobile IPv6 with the TMI as its home 174 address. Packets sent and received by a mobile node will contain its 175 TMI instead of its home address. As a result, the mobile identity is 176 hidden from the correspondent node and from potential eavesdroppers 177 in the network. 179 Note that in this case the correspondent node must never use the home 180 address, i.e., the TMI that is not routable, but must use the care-of 181 address (Mobile IPv6 should be modified to provide such 182 functionality.) 184 4.1.2. Mobile Server 186 In this case, the correspondent node knows the mobile identity by 187 definition. If a mobile node wants to hide its mobility, i.e., its 188 care-of address, to a particular correspondent node, it must not send 189 any binding update to this correspondent node and use bi-directional 190 tunneling. As a result the packets that are sent to the mobile node 191 are addressed to its home address and encapsulated by the home agent 192 to its current care-of address. The decision to send or not to send 193 a binding update to a correspondent node is a policy issue that is 194 out of the scope of this draft. Any eavesdroppers between the home 195 agent and the mobile node is able to identify and track the mobile 196 movement by looking at the inner packet. Therefore we suggest to 197 encrypt the packets that are sent between the mobile node and its 198 home agent. 200 If the mobile node decides to use route optimization, it then sends a 201 binding update to its correspondent node. This binding update 202 contains the TMI in the home address option and the actual home 203 address is encoded in a newly defined binding update sub-option. Of 204 course to preserve privacy the binding update must be encrypted (the 205 security association should be indexed with the TMI and not the home 206 address). The correspondent node uses the binding update to bind the 207 TMI with the home address and the care-of address. 209 Subsequent packets between the mobile node and the correspondent node 210 will contain the TMI in the home address option and in the routing 211 header extension instead of the actual home address. As a result an 212 eavesdropper won't be able to identify the packets belonging to a 213 particular node. 215 4.2. Temporary Mobile Identifier (TMI) 217 4.2.1. TMI generation 219 The TMI of a mobile node should be globally unique and must be 220 locally unique. By locally unique we mean that two mobile nodes 221 communicating with the same correspondent node/or home agent must use 222 different TMIs but two mobile nodes communicating with different 223 correspondent nodes can use the same TMI. The consequences of two 224 mobile nodes using the same TMI with the same correspondent node is 225 similar than the consequences of two mobile nodes using the same home 226 address with standard mobile IPv6. The correspondent node might get 227 confused... 229 We propose derive the TMI from the SHA-1 message digest of the mobile 230 node's home address. The mobile node's home address being globally 231 unique, the TMI collision probability is therefore very small. 232 Furthermore the probably of two mobile nodes generating the same TMI 233 and communicating with the same correspondent node is even smaller 234 and negligible. 236 SHA-1 was chosen because its particular properties were adequate to 237 produce the desired level of randomness and uniqueness. IPv6 nodes 238 are already required to implement SHA-1 as part of IPsec [RFC4301] 239 and [RFC4305]. 241 4.2.2. TMI management 243 The TMI of a mobile user must be changed periodically (every few 244 minutes, hours or days) in order to avoid TMI leakage as explained in 245 [RFC3041]... 247 For example, the digest for the new TMI can be generated as follows: 248 new digest = SHA-112 (home address | old digest), where "|" stands 249 for concatenation and SHA-112 the 112 first bits of SHA-1. 251 A dedicated prefix of 16 bits should used and TMI allocated into this 252 prefix (i.e., an address in this prefix is known to be a TMI). This 253 has some drawbacks and many advantages: 255 - the first 16 bits are fixed (but 112 bits should be enough to keep 256 the collision probability very close to zero). 258 - a TMI is very easy to recognize by bad guys. 260 + any mobile node can be automatically authorized to use any address 261 in this prefix. 263 + this prefix can be marked as unroutable, i.e., a wrong packet to a 264 TMI destination will be dropped by the first router, not the first 265 default free router. In general misuses of TMI become very easy 266 to detect. 268 4.3. Ownership extension 270 The routing optimization evolves towards more security so we propose 271 an extension with an integrated ownership proof. Note that some new 272 protection devices for routing optimization signaling integrate 273 privacy mechanisms as [ID.privacy-omipv6]. 275 The TMI still begins with a dedicated prefix marked as not routable 276 but the digest is derived from a public key and a random value. The 277 new digest generation rule is: digest = SHA-112 (PublicKey | imprint) 278 where imprint is a 128-bit temporary random value. 280 The proof of ownership is the same than for CGAs [RFC3972]: the 281 PublicKey and the imprint are sent to the correspondent and messages 282 are signed by the PrivateKey. 284 There are essentially two ways an adversary can impersonate a mobile 285 node: 286 1. He can try to find a RSA key pair and imprint that result to the 287 same TMI than the target node. Since the size of a TMI is 112 288 bits, the adversary has to try, on average, 2^{111} parameters 289 sets. If the attacker can perform 1 billion hashes per second 290 this would take him 8* 10^{25} years. Note that our scheme is 291 more secure than current Mobile IPv6 schemes that rely on CGA 292 addresses generated from a 59-bit long hash function. 293 2. He can try to retrieve the private key associated with the mobile 294 node's public key. A size of the modulus of at least 1024 bits 295 is commonly assumed to provide a good security level. 297 The TMI of a mobile user must be changed periodically (every few 298 minutes, hours or days) in order to avoid TMI leakage as explained in 299 [RFC3041]. This can easily be performed with the CBIDs by keeping 300 the same private/public key pair but changing the random value 301 imprint periodically. 303 5. Security Considerations 305 This document address some privacy issues in the mobile IPv6 306 protocols. Even if privacy does not provide real security (i.e., 307 security through obscurity is poor security) then it makes the job of 308 bad guys (eavesdroppers, rogue correspondents, ...) harder so should 309 improve the overall security. 311 The ownership extension is modeled on the CBID/CGA idea. Security of 312 this idea is already well known [RFC3972] and in the mobile server 313 case the proof of ownership of the TMI can be coupled with a proof of 314 ownership of the home address, for instance when the home address is 315 a CGA using the same RSA private/public key pair. 317 6. Acknowledgments 319 John Wells (INRIA), Karim El-Malki (Ericsson), Hesham Soliman 320 (Ericsson), Jean-Michel Combes (France Telecom DR&D), Imad Add 321 (INRIA), Pars Mutaf (INRIA)... 323 7. History 325 This document was directly extracted from an old proposition by the 326 first two authors. CBID (Crypto-Based IDentifier) and HMIPv6 327 extensions / improvements were removed to keep the first version of 328 this draft very small. 330 The CGA-like extension was added to the second (-01) version, the 331 original text is from [MWCN04]. 333 The next version could contain more details about the use of this 334 proposal in the [RFC4140] context. SHA-256 could replaces SHA-1 if/ 335 when [RFC4305] is updated. 337 8. IANA Considerations 339 Allocation of the needed prefix is the subject of [ID.khi]. 341 9. References 343 9.1. Normative References 345 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 346 Autoconfiguration", RFC 2462, December 1998. 348 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 349 Stateless Address Autoconfiguration in IPv6", RFC 3041, 350 January 2001. 352 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 353 in IPv6", RFC 3775, June 2004. 355 9.2. Informative References 357 [ID.khi] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 358 for Overlay Routable Cryptographic Hash Identifiers 359 (ORCHID)", draft-laganier-ipv6-khi-02.txt (work in 360 progress), June 2006. 362 [ID.privacy-omipv6] 363 Haddad, W., Ed., "Anonymity and Unlinkability Extension 364 for OMIPv6-CGA", 365 draft-haddad-privacy-omipv6-anonymity-00.txt (work in 366 progress), June 2005. 368 [MWCN04] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple 369 Privacy Extension to Mobile IPv6", IEEE/IFIP International 370 Conference on Mobile and Wireless Communication Networks 371 (MWCN), October 2004. 373 [RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, 374 revised", RFC 3024, December 2001. 376 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 377 RFC 3972, March 2005. 379 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 380 Bellier, "Hierarchical Mobile IPv6 Mobility Management 381 (HMIPv6)", RFC 4140, August 2005. 383 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 384 Internet Protocol", RFC 4301, December 2005. 386 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 387 Requirements for Encapsulating Security Payload (ESP) and 388 Authentication Header (AH)", RFC 4305, December 2005. 390 Authors' Addresses 392 Claude Castelluccia 393 INRIA 395 Email: Claude.Castelluccia@inria.fr 397 Francis Dupont 398 CELAR 400 Email: Francis.Dupont@point6.net 402 Gabriel Montenegro 403 Microsoft 405 Intellectual Property Statement 407 The IETF takes no position regarding the validity or scope of any 408 Intellectual Property Rights or other rights that might be claimed to 409 pertain to the implementation or use of the technology described in 410 this document or the extent to which any license under such rights 411 might or might not be available; nor does it represent that it has 412 made any independent effort to identify any such rights. Information 413 on the procedures with respect to rights in RFC documents can be 414 found in BCP 78 and BCP 79. 416 Copies of IPR disclosures made to the IETF Secretariat and any 417 assurances of licenses to be made available, or the result of an 418 attempt made to obtain a general license or permission for the use of 419 such proprietary rights by implementers or users of this 420 specification can be obtained from the IETF on-line IPR repository at 421 http://www.ietf.org/ipr. 423 The IETF invites any interested party to bring to its attention any 424 copyrights, patents or patent applications, or other proprietary 425 rights that may cover technology that may be required to implement 426 this standard. Please address the information to the IETF at 427 ietf-ipr@ietf.org. 429 Disclaimer of Validity 431 This document and the information contained herein are provided on an 432 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 433 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 434 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 435 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 436 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 437 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 439 Copyright Statement 441 Copyright (C) The Internet Society (2006). This document is subject 442 to the rights, licenses and restrictions contained in BCP 78, and 443 except as set forth therein, the authors retain all their rights. 445 Acknowledgment 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.