Internet Engineering Task Force Wassim Haddad
Mobility and Multi-homing Privacy Ericsson
Internet Draft Erik Nordmark
Expires April 2006 Sun Microsystems
Francis Dupont
Point6
Marcelo Bagnulo
UC3M
Soohong Daniel Park
Samsung Electronics
Basavaraj Patil
Nokia
Hannes Tschofenig
Siemens
October 2005
Privacy for Mobile and Multi-homed Nodes (MoMiPriv):
Formalizing the Threat Model
<draft-haddad-momipriv-threat-model-01>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes threats violating the privacy based on
identifiers used at the MAC and IP layers, in the context of
a mobile and multi-homed environment.
Haddad et al. Expires April 2005 [Page 1]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. Threat Model Applied to Privacy...............................4
4. Threat Model Applied to Privacy on the MAC Layer..............5
4.1. Threats from Data Collectors..............................5
4.1.1. Discovering the Identity Presence.....................5
4.1.2. Determining the Location..............................6
4.1.3. Tracing the Target....................................7
4.1.4. Threats from Various Malicious Nodes..................7
5. Threat Model Applied to Privacy on the IP Layer...............8
5.1. Threats Against Privacy in Mobile IPv6....................8
5.1.1. Quick Overview of MIPv6...............................8
5.1.2. Threats against MIPv6 Bidirectionnal Tunneling Mode...9
5.1.3. Threats Related to MIPv6 RO Mode......................9
6. Threat Model Applied to a Static Multi-homed Node............10
6.1. Threats againt Privacy on the MAC Layer..................11
6.2. Threats against Privacy on the IP Layer..................11
7. Threats related to Network Access Authentication.............13
8. Security Considerations......................................14
9. IANA Considerations..........................................14
10. Informative References......................................15
11. Normative References........................................17
12. Authors'Addresses...........................................18
Intellectual Property Statement.................................20
Disclaimer of Validity..........................................20
Copyright Statement.............................................20
Haddad et al. Expires April 2006 [Page 2]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
1. Introduction
The MoMiPriv problem statement document [MOMPS] introduced new
attributes related to the privacy and described critical issues
related to providing these attributes on both the IP and MAC
layers. In addition, MOMPS highlighted the interdependency
between issues on the MAC and IP layers and the need to solve
them all together.
This memo describes threats and possible attacks against
privacy at the MAC and IP layers, in the context of a mobile
and multi-homed environment.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
in this document are to be interpreted as described in RFC 2219
[TERM].
It would also be useful to clarify the following entities
involved in defining threats against privacy:
Target
We use the term "target" to specify an entity who's privacy
is threatened by an adversary/malicious node.
Adversary/Malicious Node
This term refers to the entity that is trying to violate
the privacy of its target.
In addition, this draft uses the terminology described in
[PRITERM].
Haddad et al. Expires April 2006 [Page 3]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
3. Threat Model Applied to Privacy
Before listing threats against privacy, we start by describing
the privacy threat model, which will be applied on the MAC and
IP layers in order to perform our analysis. The location of
adversaries violating privacy must be taken into account when
analyzing the different threats.
In a mobile environment, the three main threats against privacy
are the following:
- Identifying
- Locating
- Tracing
In the MoMiPriv context, a malicious node can identify its
target via its device identifier(s), i.e., MAC address and/or
its IPv6 address(es). Once the identification procedure is
achieved, it becomes by itself a threat against privacy, since
a malicious node located in one particular place will be able
to claim with certain confidence that its target was present
in the same place at a specific time, by just capturing its MAC
address.
The next logic step after identifying a target is to locate it
with maximum accuracy. The third step consists on tracing the
target (possibly in real-time) while it is moving across the
Internet.
Performing these three steps allow the malicious node to
gradually increase its knowledge about its target by gathering
more and more information about it. These information may allow,
for example to build a profile of the target and then to launch
specific attacks or to misuse the obtained information in other
ways (e.g., marketing purposes, statistics, etc). Data gathered
may include higher-layer identifiers (e.g., email addresses) or
pseudonyms, location information, temporal information, mobility
patterns, etc.
In order to access the MAC address of a targeted node in a
WLAN, the malicious node needs to be either on the same link or
within the distributed system (DS). However, in other scenarios,
especially in the ongoing deployment of public outdoor WLAN
technologies, more complex attacks involving multiple malicious
nodes need to be considered.
Haddad et al. Expires April 2006 [Page 4]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
Actually, taking a look at today's WLAN deployments in some
cities like Chicago and New York [WIGLE] gives a clear picture
of the high density of APs already deployed. These examples of
today's WLAN deployment leads to the following conclusions:
a) the high density of APs deployed nowadays greatly extends
the spatial and temporal coverage of the three main threats
against privacy mentioned above.
b) the MAC address is becoming easier to detect and thus is
causing a growing privacy concern, in particular for
mobility.
c) in some existing public areas covered by WLAN technologies,
any efficient tracing of a designed target is greatly
improved whenever multiple co-operative malicious nodes are
deployed in different locations covered by WLAN technologies.
Based on the above, the suggested threat model when applied to
the MAC layer should take into consideration the classic
scenario, where one malicious node is collecting data on the
link/DS and the scenario where many malicious nodes are
deployed in different locations, within the WLAN covered area,
and performing data collection while collaborating together
for identifying, locating and tracking purposes.
4. Threat Model Applied to Privacy on the MAC Layer
We start our analyze by applying the threat model to the MAC
layer.
4.1. Threats from Collecting Data
4.1.1. Discovering the Identity Presence
The WLAN technologies discloses the user's device identifier,
i.e., the MAC address, in each data frame sent/received by the
mobile node (MN) within the distribution system (DS) thus,
making the device identifier readable/available to any malicious
eavesdropper located on the link or in the same DS.
Haddad et al. Expires April 2006 [Page 5]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
Based on this observation, collecting data on one particular
link/DS, coupled with prior knowledge of the targeted node's MAC
address allows the malicious node to check first if its target is
located within the covered area or not.
An eavesdropper can perform data collecting via two ways. The
first one is by positioning itself on the link/DS and sniffing
packets exchanged between the MNs and the APs. The second way
consists on deploying rogue access points in some particular
areas. The ability to deploy rogue access points requires a
missing security protection of the WLAN network.
In WLAN, the targeted MN does not even need to exchange data
packets with another node, to disclose its MAC address to a
malicious node eavesdropping on the same link than the MN. In
fact, the target's MAC address appears in control messages
exchanged between the MN and the AP(s) or between different
MNs (adhoc mode).
In addition, identifying the target allows the malicious node to
learn the target's IPv6 address and the data sequence number.
On the other side, a malicious node collecting data from one
particular DS, may also try to conduct an active search for its
target within the DS by trying to connect to the target, using
the IPv6 address derived from the link local address, according
to the stateless address configuration protocol defined in
[STAT]. In such scenario, if the targeted node replies to the
malicious node's request while being located within the same DS,
then its presence will immediately be detected.
A malicious node may also choose and add new targets to its list,
based on other criterias, which are learned from collecting data.
For example, the frequency, timing and the presence duration of
one particular node may encourage the malicious eavsedeopper to
learn more in order to gradually build a profile for that node.
4.1.2. Determining the Location
After identifying its target within a DS, a malicious node may
attempt to determine its location. Such step can be performed
by different means.
But it should be noted first, that discovering the target's
presence on the MAC layer, implicitly maps its geographical
location within a specific area. Depending on the network
topology and the link layer technology, this area might be quite
Haddad et al. Expires April 2006 [Page 6]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
large or might have a fairly irregular shape. Hence, the
malicious node may want to learn the most accurate location of
its target.
It is also possible to determine the geographical location of
the MN with a certain accuracy at the physical layer. This is
done by identifying the Access Point (AP) to which, the MN is
currently attached and then trying to determine the geographical
location of the corresponding AP.
4.1.3. Tracing the Target
After identifying and locating its target, a malicious node
located in a particular DS, can use data collecting to trace
its target in real time within the entire ESS.
Tracing can be done either via the target's MAC address or its
IPv6 address or via the data sequence number carried in each
data frame or through combining them.
On the other side, these information allow the malicious node
to break the unlinkability protection provided by changing the
MAC address, e.g., during a L2 handoff, since it will always be
possible to trace the MN by other tools than its MAC address.
4.1.4. Threats from Various Malicious Nodes
An efficient way to trace a target within an area covered by
wireless link layer technologies is by deploying many malicious
nodes within one specific area.
As it has been mentioned above, a malicious node located
within a specific DS can trace its target only within the DS.
However, there may be scenarios where tracing a particular
target needs to go beyond one specific DS boundaries.
In addition, the target MN's MAC address may change many times
before the MN leaves the DS. Consequently, even if the new DS
is monitored by a malicious eavesdropper, it will not be possible
for him/her to identify the target anymore.
If the malicious nodes collaborate with each other, it would be
possible to keep tracing the target within a specific region. In
fact, the main goals behind collaborative tracing is to break the
unlinkability protection when provided in a independent way at the
Haddad et al. Expires April 2006 [Page 7]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
MAC and IP layers. In fact, changing the MAC address alone while
keeping using the same IP address will always make the target
identifiable and traceable through different DSs.
Note that in addition to using the MAC and IP addresses, the
sequence number can also be used for tracing purposes.
5. Threat Model Applied to Privacy on the IP Layer
Learning the target's IP address discloses the topological
location, which may in turn reveal also geographical location
information of the target. For example, location specific
extensions to the DNS directory [LOC_DNS] can help to reveal
further information about the geographical location of a
particular IP address. Tools are also available [HEO] that allows
everyone to querry this information using a graphical interface.
Note that the location information cannot be always correct, for
example due to state entries in the DNS, NATed IP addresses, usage
of tunnels (e.g., VPN, Mobile IP, etc.).
This information can be used to link the current target's
location(s) to the regular one and provide the eavesdropper more
information about its target's movements in real time.
5.1. Threats Against Privacy in Mobile IPv6
In Mobile IPv6, threats against privacy can originate from the
correspondent node (CN) and/or from a malicious node(s) located
either between the MN and the CN or between the MN and its home
agent.
5.1.1. Quick Overview of MIPv6
Mobile IPv6 [MIP6] protocol allows a mobile node to switch
between different networks, while keeping ongoing session(s)
alive. For this purpose, MIPv6 offers two modes to handle the
mobility problem. The first mode is the bidirectional tunnelling
(BT) mode, which hides the MN's movements from the CN by sending
all data packets through the MN's HA. Consequently, the BT mode
provides a certain level of location privacy by hiding the MN's
current location from the CN.
Haddad et al. Expires April 2006 [Page 8]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
The other mode is the route optimization (RO) mode, which allows
the MN to keep exchanging data packets on the direct path with
the CN, while moving outside its home network. For this purpose,
the MN needs to update the CN with its current new location each
time it switches to a new network. This is done by sending a
binding update (BU) message to the CN to update its binding cache
entry (BCE) with the MN's new location, i.e., care-of address.
In addition, the RO mode requires the MN and the CN to insert the
MN's home address in each data packet exchanged between them.
5.1.2. Threats Related to MIPv6 BT Mode
As mentioned above, the BT mode keeps the CN totally unaware of
the MN's movements across the Internet. However, the MN must
update its HA with its new current location each time it switches
to a new network, in order to enable the HA to encapsulate data
packets to its new location, i.e., new care-of address (CoA).
In the BT mode, tracing the MN can either be done via the MAC
address as described earlier, or by having a malicious node
located somewhere between the MN and the HA, and looking into
the inner data packet header.
On the other side, the MIPv6 protocol suggests that the tunnel
between the MN and the HA can be protected with ESP. In such
case, the malicious node won't be able anymore to identify its
target (when located between the mobile node and the home agent)
thus making the tracing impossible. However, tracing can always be
possible at the MAC layer.
5.1.3. Threats Related to MIPv6 RO Mode
The MIPv6 RO mode and all new optimizations, e.g., [OMIPv6],
[MIPsec] and [PreKbm], requires the MN to send a BU message to
update the CN in order to announce its new current location after
each IP handover, and to insert the MN's home address in each
data packets sent to/from the MN.
Consequently, threats against MN's privacy can emanate from a
malicious CN, which starts by establishing a session with the
target, i.e., by using its target's IPv6 home address, sending
it enough data packets and then waiting till its target switches
to the RO mode.
But it should be noted that the MN may not decide to switch to
Haddad et al. Expires April 2006 [Page 9]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
the RO mode but keep using instead the BT mode, in order to
avoid disclosing its current location to the CN.
On the other side, a malicious node may position itself
somewhere on the direct path between the MN and the CN and learn
the MN's current location from sniffing the BU message(s) and/or
the data packets exchanged between the two entities.
Another possibility is to do the tracing on the MAC address. As
mentioned above, this requires the malicious node to be located
on the same link/DS than the MN.
The MIPv6 RO mode requires protecting all signalling messages
exchanged between the MN and the HA by an ESP tunnel. In such
case, a malicious node located between the MN and the HA cannot
identify its target.
However, the IETF has recently adopted a new authentication
protocol for MIPv6 [MIPAUTH], which allows securing the BU/BA
signalling messages exchanged between the HA and the MN by using
an authentication option carried in the BU/BA messages.
MIPAUTH protocol may have a serious impact on the MN's privacy,
since it offers the malicious node a new location, i.e., the
path between the targeted MN and its HA, to identify, locate and
trace its target. This is in addition to positioning itself on
the path between the targeted MN and the CN.
It should be noted also that the path between the MN and the HA
may be more interesting to use in order to break the MN's
privacy, since the MN may try to hide its real identity (and
consequently its location) from the CN, as proposed in [MIPLOP]
while still using the real IPv6 home address to exchange
signalling messages with its HA.
Furthermore, it would also be possible to learn the MN's pseudo-
identifier(s) used in exchanging data packets and signalling
messages between the MN and the CN on the direct path, by
having two malicious nodes located between the MN and the HA
and between the MN and the CN and collaborating together.
6. Threat Model Applied to a Static Multi-homed Node
A multi-homed node can be described as being attached to more
than one Internet Service Provider (ISP). Consequently, the
multiple addresses available to a multi-homed node are
pre-defined and known in advance in most of the cases.
Haddad et al. Expires April 2006 [Page 10]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
The main goals behind providing the multi-homing feature are to
allow the multi-homed node to use multiple attachments in
parallel and the ability to switch between these different
attachments during an ongoing session(s), e.g., in case of a
failure.
For these purposes, the multi6 WG introduced recently a new
proposal to address multi-homing issues, based on using the Hash
Based Addresses [HBA] and a Layer 3 Shim Approach [SHIM].
The HBA technology offers a new mechanism to provide a secure
binding between multiple addresses with different prefixes
available to a host within a multihomed site. This is achieved
by generating the interface identifiers of the addresses of a
host as hashes of the available prefixes and a random number.
Then, the multiple addresses are generated by prepending the
different prefixes to the generated interface identifiers. The
result is a set of addresses that are inherently bound. In
addition, the HBA technology allows the CN to verify if two HBA
addresses belong to the same HBA set.
The Layer 3 Shim approach aims to eliminate any impact on upper
layer protocols by ensuring that they can keep operating
unmodified in a multi-homed environment while still seeing a
stable IPv6 address.
For a static multi-homed, the main privacy concern are the
ability to identify the multi-homed node by an untrusted party
and to discover its available addresses. The untrusted party
can be the CN itself or a third party located somewhere between
the multi-homed node and the CN.
6.1. Threats againt Privacy on the MAC Layer
A malicious node can identify the targeted multi-homed node via
its MAC address. The ability to identify the target at the MAC
layer allows the malicious node to learn part or all available
locators used by the targeted node. However, it should be noted
that for a static target, a successful identification of the MAC
address may probably require more precise information concerning
the geographical location of the target.
6.2. Threats against Privacy on the IP Layer
In a multi-homed environment, threats against privacy on the IP
Haddad et al. Expires April 2006 [Page 11]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
layer can emanate from the CN itself, in an attempt to learn
part/all multi-homed node's available locators [M6THREATS].
For example, a malicious CN can use one pre-identified locator
belonging to its target, to establish a session with the target.
After that, the CN can try to push its target to switch (i.e.,
disclose) to new locator(s) by stopping replying to packets
sent with the initial address, i.e., pretending a failure.
In such scenario, and in order to avoid interrupting ongoing
session, the targeted node may decide to switch to another (or
more) locator(s), depending on the CN willingness to re-start
sending packets to the new locator.
On the other side, an untrusted third party located near its
target (e.g., based on prior knowledge of one of the target's
locator) or one particular CN, can correlate between different
locators used by the targeted node by eavesdropping on packets
exchanged between the two entities.
Depending on the final solution adopted, the attacker can also
sniff context establishment packets that will probably contain
some or all the locators available to the multi-homed node.
Haddad et al. Expires April 2006 [Page 12]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
7. Threats related to Network Access Authentication
This section talks about privacy aspect with the transmission of
identity information as part of network access authentication and
the problem of making location information available as part of
this procedure.
In many cases the location information of the network also reveals
the current location of the user with a certain degree of precision
depending on the mechanism used, the positioning system, update
frequency, where the location was generated, size of the network
and other mechanisms (such as movement traces or interpolation).
A number of parties might gain access to location information of
the user: the access network, the home network, eavesdroppers at
the wireless link, the AAA infrastructure (such as AAA proxies)
and other communication peers.
If location information cannot be associated with a particular
long-term identifier then the ability to create profiles might be
limited but still there might be a problem (see, for example, the
usage of storing location information in the DNS [DNS_LI]).
Tracing the location of a user to create a location-profile of the
movements is certainly a big concern.
For the envisioned usage scenarios, the identity of the user and
his device is tightly coupled to the transfer of location
information. If the identity can be determined by the visited
network or AAA brokers, then it is possible to correlate location
information with a particular user. As such, it allows the visited
network and brokers to learn movement patterns of users.
The home network might need to learn the location of the visited
network and the user in many cases, as motivated in [GEORADIUS].
Unlike work in other standardization organizations, this work aims
to incorporate the usage of authorization policies and to avoid
the transmission of location information with every request. The
success of this approach, however, depends to some degree to the
privacy policy of the home network and laws.
Since the home network and the user share some form of business
relationship, it is more reasonable to assume that the home
network might act in a way that the user desires (e.g., by
enforcing privacy policies). The situation is different with the
visited network. The identity of the user can "leak" to the
visited network or AAA brokers in a number of ways:
- The user's device may employ a fixed MAC address or uses higher
layer identifiers that allows the visited network to re-recognize
the user. This enables the correlation of the particular device to
Haddad et al. Expires April 2006 [Page 13]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
its different locations. Techniques exist to avoid the use of an IP
address that is based on MAC address [Privacy]. Some link layers
make it possible to avoid MAC addresses or change them dynamically.
- Network access authentication procedures such as PPP CHAP [CHAP]
or EAP [EAP] may reveal the user's identity as a part of the
authentication procedure to the eavesdropper on the wireless link,
to the visited network and to the AAA proxies. Techniques exist to
avoid this problem in EAP, for instance by employing private Network
Access Identifiers (NAIs) in the EAP Identity Response message [NAI]
and by a method-specific private identity exchange in the EAP method
(e.g., [EAP-AKA] or [PEAP]).
Support for identity privacy within CHAP is not available.
- AAA protocols may return information from the home network to the
visited in a manner that makes it possible to either identify the
user or at least correlate his session with other sessions, such as
the use of static data in a Class attribute [RADIUS] or in some
accounting attribute usage scenarios [CUID].
- Mobility mechanisms may reveal some permanent identifier (such as a
home address) in cleartext in the packets relating to mobility
signaling.
- Application protocols may reveal other permanent identifiers.
8. Security Considerations
This document aims to formalize a privacy threat model for the
MAC and IP layers and does not suggest any solutions to counter
these threats. Based on that, the suggested threat model does
not add nor amplify any existing attacks against the mobile or
multi-homed node.
9. IANA Considerations
This document has no IANA considerations.
Haddad et al. Expires April 2006 [Page 14]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
9. Informative References
[CUID] F. Adrangi, A. Lior, J. Korhonen, J. Loughney,
"Chargeable User Identity",
draft-ietf-radext-chargeable-user-id-06,
October 2005.
[GEORADIUS] H. Tschofenig, F. Adrangi, M. Jones, A. Lior,
"Carrying Location Objects in RADIUS",
draft-ietf-geopriv-radius-lo-04, July, 2005.
[HBA] M. Bagnulo, "Hash Based Addresses (HBA)"
draft-ietf-shim6-hba-00, July 2005.
[HEO] High Earth Orbit, available at: http://
highearthorbit.com/projects/geolocation/index.php,
(February 2005).
[LOC_DNS] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A
Means for Expressing Location Information in the
Domain Name System", RFC1876, January 1996.
[M6THREATS] E. Nordmark, T. Li, "Threats relating to IPv6
multihoming solutions",
draft-ietf-multi6-multihoming-threats-03,
January 2005.
[MIPAUTH] A. Patel, K. Leung, M. Khalil, H. Akhtar, K.
Chowdhurry, "Authentication Protocol for Mobile
IPv6", draft-ietf-mip6-auth-protocol-07, September
2005.
[MIPLOP] C. Castelluccia, F. Dupont, G. Montenegro,
"A Simple Privacy Extension for Mobile IPv6",
Mobile and Wireless Communication Networks, IEEE
MWCN, October 2004.
[MIPSec] F. Dupont, JM, Combes, "Using IPsec between Mobile
and Correspondent IPv6 Nodes",
draft-ietf-mip6-cn-ipsec-01, June 2005.
Haddad et al. Expires April 2006 [Page 15]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
[MOMPS] W. Haddad, E. Nordmark, F. Dupont, M. Bagnulo, B. Patil,
"Privacy for Mobile and Multi-homed Nodes: MoMiPriv
Problem Statement",
draft-haddad-momipriv-problem-statement-02, October
2005.
[NAI] B. Aboba, M. Beadles, J. Arkko, P. Eronen, "The Network
Access Identifier", draft-ietf-radext-rfc2486bis-06,
July, 2005.
[OMIPv6] W. Haddad, L. Madour, J. Arkko, F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize
MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-03,
October 2004.
[PRITERM] W. Haddad, E. Nordmark, "Privacy Terminology",
draft-haddad-alien-privacy-terminology-00, October
2005.
[PEAP] A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn, S.
Josefssson, "Protected EAP Protocol (PEAP) Version 2,
draft-josefsson-pppext-eap-tls-eap-10, October 2004.
[PreKbm] C. Perkins, "Precomputable Binding Management Key Kbm
for Mobile IPv6", draft-ietf-mip6-precfgkbm-04.txt,
October 2005.
[Privacy] T. Narten, R. Draves, S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2-04, May, 2005.
[SHIM] E. Nordmark, M. Bagnulo, "Multihoming L3 Shim Approach",
draft-ietf-shim6-l3shim-00, July 2005.
[STAT] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless
Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08, May 2005.
[WIGLE] http://wigle.net/gps/gps/GPSDB/map/
Haddad et al. Expires April 2006 [Page 16]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
10. Normative References
[DNS_LI] C. Davies, P. Vixie, T. Goodwin, I. Dickinson, "A Means
for Expressing Location Information in the Domain Name
System", RFC 1876, January 1996.
[EAP] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H.
Levkowetz, RFC 3748, June 2004.
[EAP-AKA] J. Arkko, H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and
Key Agreement (EAP-AKA), draft-arkko-pppext-eap-aka-15,
December, 2004.
[MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[CHAP] W. Simpson, "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RADIUS] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[TERM] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
Haddad et al. Expires April 2006 [Page 17]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
11. Authors's Addresses
Wassim Haddad
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Phone: +1 514 345 7900
E-Mail: Wassim.Haddad@ericsson.com
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
E-Mail: Erik.Nordmark@sun.com
Francis Dupont
Point6
c/o GET/ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
E-Mail: Francis.Dupont@enst-bretagne.fr
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
E-Mail: Marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Soohong Daniel Park
Samsung Electronics
Haddad et al. Expires April 2006 [Page 18]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
Mobile Platform Laboratory, Samsung Electronics
416. Maetan-Dong, Yeongtong-Gu, Suwon
Korea
Phone: +81 31 200 4508
E-Mail: soohong.park@samsung.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-6709
E-Mail: Basavaraj.Patil@nokia.com
Hannes Tschoefning
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Haddad et al. Expires April 2006 [Page 19]
INTERNET-DRAFT MoMiPriv Threat Model October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the IETF's procedures
with respect to rights in IETF Documents can be found in BCP 78
and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Haddad et al. Expires April 2006 [Page 20]