[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                          W. Haddad
Internet-Draft                                         Ericsson Research
Expires: December 28, 2006                                   E. Nordmark
                                                  Sun Microsystems, Inc.
                                                               F. Dupont
                                                              M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                  S. Soohong Daniel Park
                                                     Samsung Electronics
                                                                B. Patil
                                                           H. Tschofenig
                                                           June 26, 2006

   Anonymous Identifiers (ALIEN): Privacy Threat Model for Mobile and
                           Multi-Homed Nodes

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 28, 2006.

Copyright Notice

Haddad, et al.          Expires December 28, 2006               [Page 1]

Internet-Draft                    ALIEN                        June 2006

   Copyright (C) The Internet Society (2006).


   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Threat Model Applied to Privacy  . . . . . . . . . . . . . . .  5
   4.  Threat Model Applied to Privacy on the MAC Layer . . . . . . .  7
     4.1.  Threats from Collecting Data . . . . . . . . . . . . . . .  7
       4.1.1.  Discovering the Identity Presence  . . . . . . . . . .  7
       4.1.2.  Determining the Location . . . . . . . . . . . . . . .  8
   5.  Threat Model Applied to Privacy on the IP Layer  . . . . . . . 10
     5.1.  Threats Against Privacy in Mobile IPv6 . . . . . . . . . . 10
       5.1.1.  Quick Overview of MIPv6  . . . . . . . . . . . . . . . 10
       5.1.2.  Threats Related to MIPv6 BT Mode . . . . . . . . . . . 10
       5.1.3.  Threats Related to MIPv6 RO Mode . . . . . . . . . . . 11
   6.  Threat Model Applied to a Static Multi-homed Node  . . . . . . 13
     6.1.  Threats againt Privacy on the MAC Layer  . . . . . . . . . 13
     6.2.  Threats against Privacy on the IP Layer  . . . . . . . . . 14
   7.  Threats related to Network Access Authentication . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 24

Haddad, et al.          Expires December 28, 2006               [Page 2]

Internet-Draft                    ALIEN                        June 2006

1.  Introduction

   The MoMiPriv problem statement document [I-D.haddad-momipriv-problem-
   statement] 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

Haddad, et al.          Expires December 28, 2006               [Page 3]

Internet-Draft                    ALIEN                        June 2006

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   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

Haddad, et al.          Expires December 28, 2006               [Page 4]

Internet-Draft                    ALIEN                        June 2006

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:

   o  Identifying

   o  Locating

   o  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

   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

Haddad, et al.          Expires December 28, 2006               [Page 5]

Internet-Draft                    ALIEN                        June 2006

   deployment leads to the following conclusions:

   o  the high density of APs deployed nowadays greatly extends the
      spatial and temporal coverage of the three main threats against
      privacy mentioned above.

   o  the MAC address is becoming easier to detect and thus is causing a
      growing privacy concern, in particular for mobility.

   o  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

Haddad, et al.          Expires December 28, 2006               [Page 6]

Internet-Draft                    ALIEN                        June 2006

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.

   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 [I-D.ietf-ipv6-
   rfc2462bis].  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

Haddad, et al.          Expires December 28, 2006               [Page 7]

Internet-Draft                    ALIEN                        June 2006

   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 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.  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.  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

Haddad, et al.          Expires December 28, 2006               [Page 8]

Internet-Draft                    ALIEN                        June 2006

   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
   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.

Haddad, et al.          Expires December 28, 2006               [Page 9]

Internet-Draft                    ALIEN                        June 2006

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

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.

   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

Haddad, et al.          Expires December 28, 2006              [Page 10]

Internet-Draft                    ALIEN                        June 2006

   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

   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., [I-D.arkko-
   mipshop-cga-cba], [I-D.ietf-mip6-cn-ipsec] and [I-D.ietf-mip6-
   precfgkbm], 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 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

Haddad, et al.          Expires December 28, 2006              [Page 11]

Internet-Draft                    ALIEN                        June 2006

   for MIPv6 [I-D.ietf-mip6-auth-protocol], 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.

Haddad, et al.          Expires December 28, 2006              [Page 12]

Internet-Draft                    ALIEN                        June 2006

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.

   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 [I-D.ietf-multi6-hba] and a Layer 3 Shim Approach

   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

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.

Haddad, et al.          Expires December 28, 2006              [Page 13]

Internet-Draft                    ALIEN                        June 2006

6.2.  Threats against Privacy on the IP Layer

   In a multi-homed environment, threats against privacy on the IP layer
   can emanate from the CN itself, in an attempt to learn part/all
   multi-homed node's available locators [I-D.ietf-multi6-multihoming-

   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 December 28, 2006              [Page 14]

Internet-Draft                    ALIEN                        June 2006

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

   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
   [RFC1876]).  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 [I-D.ietf-
   geopriv-radius-lo].  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:

   o  The user's device may employ a fixed MAC address or uses higher
      layer identifiers that allows the visited network to re-recognize

Haddad, et al.          Expires December 28, 2006              [Page 15]

Internet-Draft                    ALIEN                        June 2006

      the user.  This enables the correlation of the particular device
      to its different locations.  Techniques exist to avoid the use of
      an IP address that is based on MAC address [I-D.ietf-ipv6-privacy-
      addrs-v2].  Some link layers make it possible to avoid MAC
      addresses or change them dynamically.

   o  Network access authentication procedures such as PPP CHAP
      [RFC1994] or EAP [RFC3748] 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 [I-D.ietf-radext-rfc2486bis] and by a
      method-specific private identity exchange in the EAP method (e.g.,
      [RFC4187] or [I-D.josefsson-pppext-eap-tls-eap]).  Support for
      identity privacy within CHAP is not available.

   o  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 [RFC2865] or in
      some accounting attribute usage scenarios [RFC4372].

   o  Mobility mechanisms may reveal some permanent identifier (such as
      a home address) in cleartext in the packets relating to mobility

   o  Application protocols may reveal other permanent identifiers.

Haddad, et al.          Expires December 28, 2006              [Page 16]

Internet-Draft                    ALIEN                        June 2006

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.

Haddad, et al.          Expires December 28, 2006              [Page 17]

Internet-Draft                    ALIEN                        June 2006

9.  IANA Considerations

   This document does not require actions by IANA.

Haddad, et al.          Expires December 28, 2006              [Page 18]

Internet-Draft                    ALIEN                        June 2006

10.  References

10.1.  Normative References

   [MIP6]     Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", June 2004.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

10.2.  Informative References

   [HEO]      "High Earth Orbit", Febraury 2005.

              Arkko, J., "Applying Cryptographically Generated Addresses
              and Credit-Based  Authorization to Mobile IPv6",
              draft-arkko-mipshop-cga-cba-03 (work in progress),
              March 2006.

              Haddad, W. and E. Nordmark, "Privacy Terminology",
              draft-haddad-alien-privacy-terminology-00 (work in
              progress), October 2005.

              Haddad, W., "Privacy for Mobile and Multi-homed Nodes:
              MoMiPriv Problem Statement",
              draft-haddad-momipriv-problem-statement-02 (work in
              progress), October 2005.

              Tschofenig, H., "Carrying Location Objects in RADIUS",
              draft-ietf-geopriv-radius-lo-06 (work in progress),
              March 2006.

              Narten, T., "Privacy Extensions for Stateless Address
              Autoconfiguration in IPv6",
              draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),
              December 2005.

              Thomson, S., "IPv6 Stateless Address Autoconfiguration",
              draft-ietf-ipv6-rfc2462bis-08 (work in progress),
              May 2005.


Haddad, et al.          Expires December 28, 2006              [Page 19]

Internet-Draft                    ALIEN                        June 2006

              Leung, K., "Authentication Protocol for Mobile IPv6",
              draft-ietf-mip6-auth-protocol-07 (work in progress),
              September 2005.

              Dupont, F. and J. Combes, "Using IPsec between Mobile and
              Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-02
              (work in progress), December 2005.

              Perkins, C., "Securing Mobile IPv6 Route Optimization
              Using a Static Shared Key", draft-ietf-mip6-precfgkbm-04
              (work in progress), December 2005.

              Bagnulo, M., "Hash Based Addresses (HBA)",
              draft-ietf-multi6-hba-00 (work in progress),
              December 2004.

              Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim
              Approach", draft-ietf-multi6-l3shim-00 (work in progress),
              January 2005.

              Nordmark, E., "Threats relating to IPv6 multihoming
              solutions", draft-ietf-multi6-multihoming-threats-03 (work
              in progress), January 2005.

              Aboba, B., "The Network Access Identifier",
              draft-ietf-radext-rfc2486bis-06 (work in progress),
              July 2005.

              Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
              "Protected EAP Protocol (PEAP) Version 2",
              draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
              October 2004.

   [LOC_DNS]  Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
              Means for Expressing Location Information in the Domain
              Name System", RFC 1876, January 1996.

   [MIPLOP]    Montenegro, G., Castelluccia, C., and F. Dupont, "A
              Simple Privacy Extension for Mobile IPv6", Mobile and
              Wireless Communication Networks", IEEE MCWN, October 2004.

Haddad, et al.          Expires December 28, 2006              [Page 20]

Internet-Draft                    ALIEN                        June 2006

   [RFC1876]  Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
              Means for Expressing Location Information in the Domain
              Name System", RFC 1876, January 1996.

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
              Protocol Method for 3rd Generation Authentication and Key
              Agreement (EAP-AKA)", RFC 4187, January 2006.

   [RFC4372]  Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
              "Chargeable User Identity", RFC 4372, January 2006.

   [WIGLE]    "Wireless Geographic Logging Engine,
              http://wigle.net/gps/gps/Map/", 2006.

Haddad, et al.          Expires December 28, 2006              [Page 21]

Internet-Draft                    ALIEN                        June 2006

Authors' Addresses

   Wassim Haddad
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm

   Phone: +46 8 4044079
   Email: Wassim.Haddad@ericsson.com

   Erik Nordmark
   Sun Microsystems, Inc.
   17 Network Circle
   Mountain View, CA

   Email: Erik.Nordmark@sun.com

   Francis Dupont

   Email: Francis.Dupont@point6.net

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30, leganes
   Madrid  28911

   Email: Marcelo@it.uc3m.es

   Soohong Daniel Park
   Samsung Electronics
   416. Maetan-Dong, Yeongtong-Gu,

   Email: soohong.park@samsung.com

Haddad, et al.          Expires December 28, 2006              [Page 22]

Internet-Draft                    ALIEN                        June 2006

   Basavaraj Patil
   6000 Connection Drive
   Irving, Tx  75039

   Email: HBasavaraj.Patil@nokia.com

   Hannes Tschofenig
   Otto-Hahn-Ring 6
   Munich, Bayern  81739

   Email: Hannes.Tschofenig@siemens.com

Haddad, et al.          Expires December 28, 2006              [Page 23]

Internet-Draft                    ALIEN                        June 2006

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 procedures with respect to rights in RFC 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Haddad, et al.          Expires December 28, 2006              [Page 24]