idnits 2.17.00 (12 Aug 2021) /tmp/idnits56619/draft-haddad-momipriv-threat-model-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 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 768. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 26, 2006) is 5801 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) == Unused Reference: 'I-D.arkko-mipshop-cga-cba' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'I-D.haddad-momipriv-problem-statement' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-radius-lo' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-privacy-addrs-v2' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-rfc2462bis' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip6-precfgkbm' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-multi6-multihoming-threats' is defined on line 642, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MIP6' == Outdated reference: A later version (-04) exists of draft-arkko-mipshop-cga-cba-03 == Outdated reference: A later version (-06) exists of draft-haddad-alien-privacy-terminology-00 == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-02 == Outdated reference: draft-ietf-geopriv-radius-lo has been published as RFC 5580 == Outdated reference: draft-ietf-ipv6-privacy-addrs-v2 has been published as RFC 4941 == Outdated reference: draft-ietf-ipv6-rfc2462bis has been published as RFC 4862 == Outdated reference: draft-ietf-mip6-auth-protocol has been published as RFC 4285 == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-02 == Outdated reference: draft-ietf-mip6-precfgkbm has been published as RFC 4449 == Outdated reference: draft-ietf-multi6-multihoming-threats has been published as RFC 4218 == Outdated reference: draft-ietf-radext-rfc2486bis has been published as RFC 4282 Summary: 3 errors (**), 0 flaws (~~), 21 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Ericsson Research 4 Expires: December 28, 2006 E. Nordmark 5 Sun Microsystems, Inc. 6 F. Dupont 7 CELAR 8 M. Bagnulo 9 Universidad Carlos III de Madrid 10 S. Soohong Daniel Park 11 Samsung Electronics 12 B. Patil 13 Nokia 14 H. Tschofenig 15 Siemens 16 June 26, 2006 18 Anonymous Identifiers (ALIEN): Privacy Threat Model for Mobile and 19 Multi-Homed Nodes 20 draft-haddad-momipriv-threat-model-02.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on December 28, 2006. 47 Copyright Notice 48 Copyright (C) The Internet Society (2006). 50 Abstract 52 This memo describes threats violating the privacy based on 53 identifiers used at the MAC and IP layers, in the context of a mobile 54 and multi-homed environment. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Threat Model Applied to Privacy . . . . . . . . . . . . . . . 5 61 4. Threat Model Applied to Privacy on the MAC Layer . . . . . . . 7 62 4.1. Threats from Collecting Data . . . . . . . . . . . . . . . 7 63 4.1.1. Discovering the Identity Presence . . . . . . . . . . 7 64 4.1.2. Determining the Location . . . . . . . . . . . . . . . 8 65 5. Threat Model Applied to Privacy on the IP Layer . . . . . . . 10 66 5.1. Threats Against Privacy in Mobile IPv6 . . . . . . . . . . 10 67 5.1.1. Quick Overview of MIPv6 . . . . . . . . . . . . . . . 10 68 5.1.2. Threats Related to MIPv6 BT Mode . . . . . . . . . . . 10 69 5.1.3. Threats Related to MIPv6 RO Mode . . . . . . . . . . . 11 70 6. Threat Model Applied to a Static Multi-homed Node . . . . . . 13 71 6.1. Threats againt Privacy on the MAC Layer . . . . . . . . . 13 72 6.2. Threats against Privacy on the IP Layer . . . . . . . . . 14 73 7. Threats related to Network Access Authentication . . . . . . . 15 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 Intellectual Property and Copyright Statements . . . . . . . . . . 24 82 1. Introduction 84 The MoMiPriv problem statement document [I-D.haddad-momipriv-problem- 85 statement] introduced new attributes related to the privacy and 86 described critical issues related to providing these attributes on 87 both the IP and MAC layers. In addition, MOMPS highlighted the 88 interdependency between issues on the MAC and IP layers and the need 89 to solve them all together. 91 This memo describes threats and possible attacks against privacy at 92 the MAC and IP layers, in the context of a mobile and multi-homed 93 environment. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 It would also be useful to clarify the following entities involved in 102 defining threats against privacy: 104 Target We use the term "target" to specify an entity who's privacy is 105 threatened by an adversary/malicious node. 107 Adversary/Malicious Node This term refers to the entity that is 108 trying to violate the privacy of its target. 110 In addition, this draft uses the terminology described in 111 [I-D.haddad-alien-privacy-terminology]. 113 3. Threat Model Applied to Privacy 115 Before listing threats against privacy, we start by describing the 116 privacy threat model, which will be applied on the MAC and IP layers 117 in order to perform our analysis. The location of adversaries 118 violating privacy must be taken into account when analyzing the 119 different threats. 121 In a mobile environment, the three main threats against privacy are 122 the following: 124 o Identifying 126 o Locating 128 o Tracing 130 In the MoMiPriv context, a malicious node can identify its target via 131 its device identifier(s), i.e., MAC address and/or its IPv6 132 address(es). Once the identification procedure is achieved, it 133 becomes by itself a threat against privacy, since a malicious node 134 located in one particular place will be able to claim with certain 135 confidence that its target was present in the same place at a 136 specific time, by just capturing its MAC address. 138 The next logic step after identifying a target is to locate it with 139 maximum accuracy. The third step consists on tracing the target 140 (possibly in real-time) while it is moving across the Internet. 142 Performing these three steps allow the malicious node to gradually 143 increase its knowledge about its target by gathering more and more 144 information about it. These information may allow, for example to 145 build a profile of the target and then to launch specific attacks or 146 to misuse the obtained information in other ways (e.g., marketing 147 purposes, statistics, etc). Data gathered may include higher-layer 148 identifiers (e.g., email addresses) or pseudonyms, location 149 information, temporal information, mobility patterns, etc. 151 In order to access the MAC address of a targeted node in a WLAN, the 152 malicious node needs to be either on the same link or within the 153 distributed system (DS). However, in other scenarios, especially in 154 the ongoing deployment of public outdoor WLAN technologies, more 155 complex attacks involving multiple malicious nodes need to be 156 considered. 158 Actually, taking a look at today's WLAN deployments in some cities 159 like Chicago and New York [WIGLE] gives a clear picture of the high 160 density of APs already deployed. These examples of today's WLAN 161 deployment leads to the following conclusions: 163 o the high density of APs deployed nowadays greatly extends the 164 spatial and temporal coverage of the three main threats against 165 privacy mentioned above. 167 o the MAC address is becoming easier to detect and thus is causing a 168 growing privacy concern, in particular for mobility. 170 o in some existing public areas covered by WLAN technologies, any 171 efficient tracing of a designed target is greatly improved 172 whenever multiple co-operative malicious nodes are deployed in 173 different locations covered by WLAN technologies. 175 Based on the above, the suggested threat model when applied to the 176 MAC layer should take into consideration the classic scenario, where 177 one malicious node is collecting data on the link/DS and the scenario 178 where many malicious nodes are deployed in different locations, 179 within the WLAN covered area, and performing data collection while 180 collaborating together for identifying, locating and tracking 181 purposes. 183 4. Threat Model Applied to Privacy on the MAC Layer 185 We start our analyze by applying the threat model to the MAC layer. 187 4.1. Threats from Collecting Data 189 4.1.1. Discovering the Identity Presence 191 The WLAN technologies discloses the user's device identifier, i.e., 192 the MAC address, in each data frame sent/received by the mobile node 193 (MN) within the distribution system (DS) thus, making the device 194 identifier readable/available to any malicious eavesdropper located 195 on the link or in the same DS. 197 Based on this observation, collecting data on one particular link/DS, 198 coupled with prior knowledge of the targeted node's MAC address 199 allows the malicious node to check first if its target is located 200 within the covered area or not. 202 An eavesdropper can perform data collecting via two ways. The first 203 one is by positioning itself on the link/DS and sniffing packets 204 exchanged between the MNs and the APs. The second way consists on 205 deploying rogue access points in some particular areas. The ability 206 to deploy rogue access points requires a missing security protection 207 of the WLAN network. 209 In WLAN, the targeted MN does not even need to exchange data packets 210 with another node, to disclose its MAC address to a malicious node 211 eavesdropping on the same link than the MN. In fact, the target's 212 MAC address appears in control messages exchanged between the MN and 213 the AP(s) or between different MNs (adhoc mode). 215 In addition, identifying the target allows the malicious node to 216 learn the target's IPv6 address and the data sequence number. 218 On the other side, a malicious node collecting data from one 219 particular DS, may also try to conduct an active search for its 220 target within the DS by trying to connect to the target, using the 221 IPv6 address derived from the link local address, according to the 222 stateless address configuration protocol defined in [I-D.ietf-ipv6- 223 rfc2462bis]. In such scenario, if the targeted node replies to the 224 malicious node's request while being located within the same DS, then 225 its presence will immediately be detected. 227 A malicious node may also choose and add new targets to its list, 228 based on other criterias, which are learned from collecting data. 229 For example, the frequency, timing and the presence duration of one 230 particular node may encourage the malicious eavsedeopper to learn 231 more in order to gradually build a profile for that node. 233 4.1.2. Determining the Location 235 After identifying its target within a DS, a malicious node may 236 attempt to determine its location. Such step can be performed by 237 different means. 239 But it should be noted first, that discovering the target's presence 240 on the MAC layer, implicitly maps its geographical location within a 241 specific area. Depending on the network topology and the link layer 242 technology, this area might be quite large or might have a fairly 243 irregular shape. Hence, the malicious node may want to learn the 244 most accurate location of its target. 246 It is also possible to determine the geographical location of the MN 247 with a certain accuracy at the physical layer. This is done by 248 identifying the Access Point (AP) to which, the MN is currently 249 attached and then trying to determine the geographical location of 250 the corresponding AP. 252 4.1.2.1. Tracing the Target 254 After identifying and locating its target, a malicious node located 255 in a particular DS, can use data collecting to trace its target in 256 real time within the entire ESS. 258 Tracing can be done either via the target's MAC address or its IPv6 259 address or via the data sequence number carried in each data frame or 260 through combining them. 262 On the other side, these information allow the malicious node to 263 break the unlinkability protection provided by changing the MAC 264 address, e.g., during a L2 handoff, since it will always be possible 265 to trace the MN by other tools than its MAC address. 267 4.1.2.2. Threats from Various Malicious Nodes 269 An efficient way to trace a target within an area covered by wireless 270 link layer technologies is by deploying many malicious nodes within 271 one specific area. 273 As it has been mentioned above, a malicious node located within a 274 specific DS can trace its target only within the DS. However, there 275 may be scenarios where tracing a particular target needs to go beyond 276 one specific DS boundaries. In addition, the target MN's MAC address 277 may change many times before the MN leaves the DS. Consequently, 278 even if the new DS is monitored by a malicious eavesdropper, it will 279 not be possible for him/her to identify the target anymore. 281 If the malicious nodes collaborate with each other, it would be 282 possible to keep tracing the target within a specific region. In 283 fact, the main goals behind collaborative tracing is to break the 284 unlinkability protection when provided in a independent way at the 285 MAC and IP layers. In fact, changing the MAC address alone while 286 keeping using the same IP address will always make the target 287 identifiable and traceable through different DSs. 289 Note that in addition to using the MAC and IP addresses, the sequence 290 number can also be used for tracing purposes. 292 5. Threat Model Applied to Privacy on the IP Layer 294 Learning the target's IP address discloses the topological location, 295 which may in turn reveal also geographical location information of 296 the target. For example, location specific extensions to the DNS 297 directory [LOC_DNS] can help to reveal further information about the 298 geographical location of a particular IP address. Tools are also 299 available [HEO] that allows everyone to querry this information using 300 a graphical interface. Note that the location information cannot be 301 always correct, for example due to state entries in the DNS, NATed IP 302 addresses, usage of tunnels (e.g., VPN, Mobile IP, etc.). 304 This information can be used to link the current target's location(s) 305 to the regular one and provide the eavesdropper more information 306 about its target's movements in real time. 308 5.1. Threats Against Privacy in Mobile IPv6 310 In Mobile IPv6, threats against privacy can originate from the 311 correspondent node (CN) and/or from a malicious node(s) located 312 either between the MN and the CN or between the MN and its home 313 agent. 315 5.1.1. Quick Overview of MIPv6 317 Mobile IPv6[MIP6] protocol allows a mobile node to switch between 318 different networks, while keeping ongoing session(s) alive. For this 319 purpose, MIPv6 offers two modes to handle the mobility problem. The 320 first mode is the bidirectional tunnelling (BT) mode, which hides the 321 MN's movements from the CN by sending all data packets through the 322 MN's HA. Consequently, the BT mode provides a certain level of 323 location privacy by hiding the MN's current location from the CN. 325 The other mode is the route optimization (RO) mode, which allows the 326 MN to keep exchanging data packets on the direct path with the CN, 327 while moving outside its home network. For this purpose, the MN 328 needs to update the CN with its current new location each time it 329 switches to a new network. This is done by sending a binding update 330 (BU) message to the CN to update its binding cache entry (BCE) with 331 the MN's new location, i.e., care-of address. In addition, the RO 332 mode requires the MN and the CN to insert the MN's home address in 333 each data packet exchanged between them. 335 5.1.2. Threats Related to MIPv6 BT Mode 337 As mentioned above, the BT mode keeps the CN totally unaware of the 338 MN's movements across the Internet. However, the MN must update its 339 HA with its new current location each time it switches to a new 340 network, in order to enable the HA to encapsulate data packets to its 341 new location, i.e., new care-of address (CoA). 343 In the BT mode, tracing the MN can either be done via the MAC address 344 as described earlier, or by having a malicious node located somewhere 345 between the MN and the HA, and looking into the inner data packet 346 header. 348 On the other side, the MIPv6 protocol suggests that the tunnel 349 between the MN and the HA can be protected with ESP. In such case, 350 the malicious node won't be able anymore to identify its target (when 351 located between the mobile node and the home agent) thus making the 352 tracing impossible. However, tracing can always be possible at the 353 MAC layer. 355 5.1.3. Threats Related to MIPv6 RO Mode 357 The MIPv6 RO mode and all new optimizations, e.g., [I-D.arkko- 358 mipshop-cga-cba], [I-D.ietf-mip6-cn-ipsec] and [I-D.ietf-mip6- 359 precfgkbm], requires the MN to send a BU message to update the CN in 360 order to announce its new current location after each IP handover, 361 and to insert the MN's home address in each data packets sent to/from 362 the MN. 364 Consequently, threats against MN's privacy can emanate from a 365 malicious CN, which starts by establishing a session with the target, 366 i.e., by using its target's IPv6 home address, sending it enough data 367 packets and then waiting till its target switches to the RO mode. 369 But it should be noted that the MN may not decide to switch to the RO 370 mode but keep using instead the BT mode, in order to avoid disclosing 371 its current location to the CN. 373 On the other side, a malicious node may position itself somewhere on 374 the direct path between the MN and the CN and learn the MN's current 375 location from sniffing the BU message(s) and/or the data packets 376 exchanged between the two entities. 378 Another possibility is to do the tracing on the MAC address. As 379 mentioned above, this requires the malicious node to be located on 380 the same link/DS than the MN. 382 The MIPv6 RO mode requires protecting all signalling messages 383 exchanged between the MN and the HA by an ESP tunnel. In such case, 384 a malicious node located between the MN and the HA cannot identify 385 its target. 387 However, the IETF has recently adopted a new authentication protocol 388 for MIPv6 [I-D.ietf-mip6-auth-protocol], which allows securing the 389 BU/BA signalling messages exchanged between the HA and the MN by 390 using an authentication option carried in the BU/BA messages. 392 MIPAUTH protocol may have a serious impact on the MN's privacy, since 393 it offers the malicious node a new location, i.e., the path between 394 the targeted MN and its HA, to identify, locate and trace its target. 395 This is in addition to positioning itself on the path between the 396 targeted MN and the CN. It should be noted also that the path 397 between the MN and the HA may be more interesting to use in order to 398 break the MN's privacy, since the MN may try to hide its real 399 identity (and consequently its location) from the CN, as proposed in 400 [MIPLOP] while still using the real IPv6 home address to exchange 401 signalling messages with its HA. 403 Furthermore, it would also be possible to learn the MN's pseudo- 404 identifier(s) used in exchanging data packets and signalling messages 405 between the MN and the CN on the direct path, by having two malicious 406 nodes located between the MN and the HA and between the MN and the CN 407 and collaborating together. 409 6. Threat Model Applied to a Static Multi-homed Node 411 A multi-homed node can be described as being attached to more than 412 one Internet Service Provider (ISP). Consequently, the multiple 413 addresses available to a multi-homed node are pre-defined and known 414 in advance in most of the cases. 416 The main goals behind providing the multi-homing feature are to allow 417 the multi-homed node to use multiple attachments in parallel and the 418 ability to switch between these different attachments during an 419 ongoing session(s), e.g., in case of a failure. 421 For these purposes, the multi6 WG introduced recently a new proposal 422 to address multi-homing issues, based on using the Hash Based 423 Addresses [I-D.ietf-multi6-hba] and a Layer 3 Shim Approach 424 [I-D.ietf-multi6-l3shim]. 426 The HBA technology offers a new mechanism to provide a secure binding 427 between multiple addresses with different prefixes available to a 428 host within a multihomed site. This is achieved by generating the 429 interface identifiers of the addresses of a host as hashes of the 430 available prefixes and a random number. Then, the multiple addresses 431 are generated by prepending the different prefixes to the generated 432 interface identifiers. The result is a set of addresses that are 433 inherently bound. In addition, the HBA technology allows the CN to 434 verify if two HBA addresses belong to the same HBA set. 436 The Layer 3 Shim approach aims to eliminate any impact on upper layer 437 protocols by ensuring that they can keep operating unmodified in a 438 multi-homed environment while still seeing a stable IPv6 address. 440 For a static multi-homed, the main privacy concern are the ability to 441 identify the multi-homed node by an untrusted party and to discover 442 its available addresses. The untrusted party can be the CN itself or 443 a third party located somewhere between the multi-homed node and the 444 CN. 446 6.1. Threats againt Privacy on the MAC Layer 448 A malicious node can identify the targeted multi-homed node via its 449 MAC address. The ability to identify the target at the MAC layer 450 allows the malicious node to learn part or all available locators 451 used by the targeted node. However, it should be noted that for a 452 static target, a successful identification of the MAC address may 453 probably require more precise information concerning the geographical 454 location of the target. 456 6.2. Threats against Privacy on the IP Layer 458 In a multi-homed environment, threats against privacy on the IP layer 459 can emanate from the CN itself, in an attempt to learn part/all 460 multi-homed node's available locators [I-D.ietf-multi6-multihoming- 461 threats]. 463 For example, a malicious CN can use one pre-identified locator 464 belonging to its target, to establish a session with the target. 465 After that, the CN can try to push its target to switch (i.e., 466 disclose) to new locator(s) by stopping replying to packets sent with 467 the initial address, i.e., pretending a failure. In such scenario, 468 and in order to avoid interrupting ongoing session, the targeted node 469 may decide to switch to another (or more) locator(s), depending on 470 the CN willingness to re-start sending packets to the new locator. 472 On the other side, an untrusted third party located near its target 473 (e.g., based on prior knowledge of one of the target's locator) or 474 one particular CN, can correlate between different locators used by 475 the targeted node by eavesdropping on packets exchanged between the 476 two entities. 478 Depending on the final solution adopted, the attacker can also sniff 479 context establishment packets that will probably contain some or all 480 the locators available to the multi-homed node. 482 7. Threats related to Network Access Authentication 484 This section talks about privacy aspect with the transmission of 485 identity information as part of network access authentication and the 486 problem of making location information available as part of this 487 procedure. 489 In many cases the location information of the network also reveals 490 the current location of the user with a certain degree of precision 491 depending on the mechanism used, the positioning system, update 492 frequency, where the location was generated, size of the network and 493 other mechanisms (such as movement traces or interpolation). 495 A number of parties might gain access to location information of the 496 user: the access network, the home network, eavesdroppers at the 497 wireless link, the AAA infrastructure (such as AAA proxies) and other 498 communication peers. If location information cannot be associated 499 with a particular long-term identifier then the ability to create 500 profiles might be limited but still there might be a problem (see, 501 for example, the usage of storing location information in the DNS 502 [RFC1876]). Tracing the location of a user to create a location- 503 profile of the movements is certainly a big concern. 505 For the envisioned usage scenarios, the identity of the user and his 506 device is tightly coupled to the transfer of location information. 507 If the identity can be determined by the visited network or AAA 508 brokers, then it is possible to correlate location information with a 509 particular user. As such, it allows the visited network and brokers 510 to learn movement patterns of users. 512 The home network might need to learn the location of the visited 513 network and the user in many cases, as motivated in [I-D.ietf- 514 geopriv-radius-lo]. Unlike work in other standardization 515 organizations, this work aims to incorporate the usage of 516 authorization policies and to avoid the transmission of location 517 information with every request. The success of this approach, 518 however, depends to some degree to the privacy policy of the home 519 network and laws. 521 Since the home network and the user share some form of business 522 relationship, it is more reasonable to assume that the home network 523 might act in a way that the user desires (e.g., by enforcing privacy 524 policies). The situation is different with the visited network. The 525 identity of the user can "leak" to the visited network or AAA brokers 526 in a number of ways: 528 o The user's device may employ a fixed MAC address or uses higher 529 layer identifiers that allows the visited network to re-recognize 530 the user. This enables the correlation of the particular device 531 to its different locations. Techniques exist to avoid the use of 532 an IP address that is based on MAC address [I-D.ietf-ipv6-privacy- 533 addrs-v2]. Some link layers make it possible to avoid MAC 534 addresses or change them dynamically. 536 o Network access authentication procedures such as PPP CHAP 537 [RFC1994] or EAP [RFC3748] may reveal the user's identity as a 538 part of the authentication procedure to the eavesdropper on the 539 wireless link, to the visited network and to the AAA proxies. 540 Techniques exist to avoid this problem in EAP, for instance by 541 employing private Network Access Identifiers (NAIs) in the EAP 542 Identity Response message [I-D.ietf-radext-rfc2486bis] and by a 543 method-specific private identity exchange in the EAP method (e.g., 544 [RFC4187] or [I-D.josefsson-pppext-eap-tls-eap]). Support for 545 identity privacy within CHAP is not available. 547 o AAA protocols may return information from the home network to the 548 visited in a manner that makes it possible to either identify the 549 user or at least correlate his session with other sessions, such 550 as the use of static data in a Class attribute [RFC2865] or in 551 some accounting attribute usage scenarios [RFC4372]. 553 o Mobility mechanisms may reveal some permanent identifier (such as 554 a home address) in cleartext in the packets relating to mobility 555 signaling. 557 o Application protocols may reveal other permanent identifiers. 559 8. Security Considerations 561 This document aims to formalize a privacy threat model for the MAC 562 and IP layers and does not suggest any solutions to counter these 563 threats. Based on that, the suggested threat model does not add nor 564 amplify any existing attacks against the mobile or multi-homed node. 566 9. IANA Considerations 568 This document does not require actions by IANA. 570 10. References 572 10.1. Normative References 574 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 575 in IPv6", June 2004. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", March 1997. 580 10.2. Informative References 582 [HEO] "High Earth Orbit", Febraury 2005. 584 [I-D.arkko-mipshop-cga-cba] 585 Arkko, J., "Applying Cryptographically Generated Addresses 586 and Credit-Based Authorization to Mobile IPv6", 587 draft-arkko-mipshop-cga-cba-03 (work in progress), 588 March 2006. 590 [I-D.haddad-alien-privacy-terminology] 591 Haddad, W. and E. Nordmark, "Privacy Terminology", 592 draft-haddad-alien-privacy-terminology-00 (work in 593 progress), October 2005. 595 [I-D.haddad-momipriv-problem-statement] 596 Haddad, W., "Privacy for Mobile and Multi-homed Nodes: 597 MoMiPriv Problem Statement", 598 draft-haddad-momipriv-problem-statement-02 (work in 599 progress), October 2005. 601 [I-D.ietf-geopriv-radius-lo] 602 Tschofenig, H., "Carrying Location Objects in RADIUS", 603 draft-ietf-geopriv-radius-lo-06 (work in progress), 604 March 2006. 606 [I-D.ietf-ipv6-privacy-addrs-v2] 607 Narten, T., "Privacy Extensions for Stateless Address 608 Autoconfiguration in IPv6", 609 draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), 610 December 2005. 612 [I-D.ietf-ipv6-rfc2462bis] 613 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 614 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 615 May 2005. 617 [I-D.ietf-mip6-auth-protocol] 618 Leung, K., "Authentication Protocol for Mobile IPv6", 619 draft-ietf-mip6-auth-protocol-07 (work in progress), 620 September 2005. 622 [I-D.ietf-mip6-cn-ipsec] 623 Dupont, F. and J. Combes, "Using IPsec between Mobile and 624 Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-02 625 (work in progress), December 2005. 627 [I-D.ietf-mip6-precfgkbm] 628 Perkins, C., "Securing Mobile IPv6 Route Optimization 629 Using a Static Shared Key", draft-ietf-mip6-precfgkbm-04 630 (work in progress), December 2005. 632 [I-D.ietf-multi6-hba] 633 Bagnulo, M., "Hash Based Addresses (HBA)", 634 draft-ietf-multi6-hba-00 (work in progress), 635 December 2004. 637 [I-D.ietf-multi6-l3shim] 638 Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim 639 Approach", draft-ietf-multi6-l3shim-00 (work in progress), 640 January 2005. 642 [I-D.ietf-multi6-multihoming-threats] 643 Nordmark, E., "Threats relating to IPv6 multihoming 644 solutions", draft-ietf-multi6-multihoming-threats-03 (work 645 in progress), January 2005. 647 [I-D.ietf-radext-rfc2486bis] 648 Aboba, B., "The Network Access Identifier", 649 draft-ietf-radext-rfc2486bis-06 (work in progress), 650 July 2005. 652 [I-D.josefsson-pppext-eap-tls-eap] 653 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, 654 "Protected EAP Protocol (PEAP) Version 2", 655 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 656 October 2004. 658 [LOC_DNS] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 659 Means for Expressing Location Information in the Domain 660 Name System", RFC 1876, January 1996. 662 [MIPLOP] Montenegro, G., Castelluccia, C., and F. Dupont, "A 663 Simple Privacy Extension for Mobile IPv6", Mobile and 664 Wireless Communication Networks", IEEE MCWN, October 2004. 666 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 667 Means for Expressing Location Information in the Domain 668 Name System", RFC 1876, January 1996. 670 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 671 Protocol (CHAP)", RFC 1994, August 1996. 673 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 674 "Remote Authentication Dial In User Service (RADIUS)", 675 RFC 2865, June 2000. 677 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 678 Levkowetz, "Extensible Authentication Protocol (EAP)", 679 RFC 3748, June 2004. 681 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 682 Protocol Method for 3rd Generation Authentication and Key 683 Agreement (EAP-AKA)", RFC 4187, January 2006. 685 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 686 "Chargeable User Identity", RFC 4372, January 2006. 688 [WIGLE] "Wireless Geographic Logging Engine, 689 http://wigle.net/gps/gps/Map/", 2006. 691 Authors' Addresses 693 Wassim Haddad 694 Ericsson Research 695 Torshamnsgatan 23 696 SE-164 80 Stockholm 697 Sweden 699 Phone: +46 8 4044079 700 Email: Wassim.Haddad@ericsson.com 702 Erik Nordmark 703 Sun Microsystems, Inc. 704 17 Network Circle 705 Mountain View, CA 706 USA 708 Email: Erik.Nordmark@sun.com 710 Francis Dupont 711 CELAR 713 Email: Francis.Dupont@point6.net 715 Marcelo Bagnulo 716 Universidad Carlos III de Madrid 717 Av. Universidad 30, leganes 718 Madrid 28911 719 Spain 721 Email: Marcelo@it.uc3m.es 723 Soohong Daniel Park 724 Samsung Electronics 725 416. Maetan-Dong, Yeongtong-Gu, 726 Suwon 727 Korea 729 Email: soohong.park@samsung.com 730 Basavaraj Patil 731 Nokia 732 6000 Connection Drive 733 Irving, Tx 75039 734 USA 736 Email: HBasavaraj.Patil@nokia.com 738 Hannes Tschofenig 739 Siemens 740 Otto-Hahn-Ring 6 741 Munich, Bayern 81739 742 Germany 744 Email: Hannes.Tschofenig@siemens.com 746 Intellectual Property Statement 748 The IETF takes no position regarding the validity or scope of any 749 Intellectual Property Rights or other rights that might be claimed to 750 pertain to the implementation or use of the technology described in 751 this document or the extent to which any license under such rights 752 might or might not be available; nor does it represent that it has 753 made any independent effort to identify any such rights. Information 754 on the procedures with respect to rights in RFC documents can be 755 found in BCP 78 and BCP 79. 757 Copies of IPR disclosures made to the IETF Secretariat and any 758 assurances of licenses to be made available, or the result of an 759 attempt made to obtain a general license or permission for the use of 760 such proprietary rights by implementers or users of this 761 specification can be obtained from the IETF on-line IPR repository at 762 http://www.ietf.org/ipr. 764 The IETF invites any interested party to bring to its attention any 765 copyrights, patents or patent applications, or other proprietary 766 rights that may cover technology that may be required to implement 767 this standard. Please address the information to the IETF at 768 ietf-ipr@ietf.org. 770 Disclaimer of Validity 772 This document and the information contained herein are provided on an 773 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 774 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 775 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 776 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 777 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 778 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 780 Copyright Statement 782 Copyright (C) The Internet Society (2006). This document is subject 783 to the rights, licenses and restrictions contained in BCP 78, and 784 except as set forth therein, the authors retain all their rights. 786 Acknowledgment 788 Funding for the RFC Editor function is currently provided by the 789 Internet Society.