Internet DRAFT - draft-dupont-mip6-privacyext
draft-dupont-mip6-privacyext
Network Working Group C. Castelluccia
Internet-Draft INRIA
Expires: January 20, 2007 F. Dupont
CELAR
G. Montenegro
Microsoft
July 19, 2006
A Simple Privacy Extension for Mobile IPv6
draft-dupont-mip6-privacyext-04.txt
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.
This Internet-Draft will expire on January 20, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft presents a simple privacy extension for Mobile IPv6 that
prevents eavesdroppers from identifying the packets sent or received
from a particular mobile node. This extension also allows a mobile
node to hide its identity from correspondent nodes when the mobile
node initiates the communication.
Castelluccia, et al. Expires January 20, 2007 [Page 1]
Internet-Draft MIPv6 Privacy Ext July 2006
1. Introduction
In Mobile IPv6 [RFC3775], the home address of a mobile node is
included in the packets that it sends and receives.
As a result any node in the network can identify packets that belong
to a particular mobile node (and use them to perform some kind of
traffic analysis) and track its movements (i.e., its care-of address)
and usage. We propose a solution to prevent such tracking while
still using route optimization.
In particular our proposal solves the two following problems:
- Privacy of mobile client from its correspondent node and from any
eavesdroppers in the network: the mobile node connects to a remote
node (a server for example) and wants to hide it identity (i.e.,
its home address) from this node and from any eavesdropper in the
network while still being able to move.
- Privacy of mobile server from eavesdroppers: the remote node
initiates the communication and the mobile node is able to hide
its identity (and therefore its locations) from any eavesdropper
in the network (but not from the remote node).
We do not solve the problem of privacy of a mobile server from its
correspondent nodes. In this case a mobile node still needs to
reveal its care-of address to its correspondent nodes to ensure
optimal routing. If this level of privacy is desired, one possible
solution is bi-directional encrypted tunneling via the home agent.
Full privacy is then provided at the cost of routing performance. It
should be noted that [RFC4140] in revealing the regional care-of
address (RCoA) instead of the care-of address might be an other
alternative.
In this draft we only look at privacy issues in Mobile IPv6 and
assume that a mobile node's identity is not revealed by other
protocols such as AAA, IKE,...and by the applications (i.e.
applications must not include any IP address in their payloads.)
2. Problem statement
In Mobile IPv6, the home address of a mobile node is included in
clear text in the packets it sends and receives. In fact, packets
sent by a mobile node includes a home address option that contains
its home address. Packets sent by a correspondent node to a given
mobile node contains a routing header that includes the mobile home
address. As a result, any eavesdropper within the network can easily
Castelluccia, et al. Expires January 20, 2007 [Page 2]
Internet-Draft MIPv6 Privacy Ext July 2006
identify packets that belong to a particular mobile node (and use
them to perform some kind of traffic analysis) and track mobile
movements and usage.
3. Possible solutions
Several solutions are possible, all with their limitations:
- IPv6 privacy extension: a solution could be to used the privacy
extension described in [RFC3041] to configure the home address and
the care-of addresses. While this solution represents a marked
improvement over the default address configuration methods
[RFC2462], and should be used for the home and care-of addresses,
we contend that this is not sufficient. [RFC3041] causes nodes to
generate global-scope addresses from interface identifiers that
change over time, even in cases where the interface contains an
embedded IEEE identifier. As a result if [RFC3041] is used to
generate the home address, this address will change periodically
but the network prefix (64 highest bits) will remain unchanged.
This network prefix can still reveal much information about the
mobile node's identity to an eavesdropper. This mechanism
described in [RFC3041] must be used for the home address and
care-of addresses in Mobile IPv6 but one should not rely on it to
get full privacy protection.
- Home address option encryption: an other solution could be to
encrypt the home address option. This solution is not
satisfactory because
(1) it would require to modify IPsec implementation (security
associations should then be indexed with the care-of address
and therefore would need to be updated at each movement of the
mobile node) and
(2) it would make the usage of firewalls difficult (currently
firewalls look at the home address option to perform some
filtering).
Furthermore this solution does not solve the problem of incoming
packets that contain a routing header which reveals the home
address.
- IPsec bi-directional Tunnel (mobile VPN): A solution could be to
open a bi-directional IPsec tunnel between the mobile node and its
home agent [RFC3024]. This solution has the following
disadvantages:
(1) addition of extra bandwidth (packets need to be
encapsulated) and processing overhead,
Castelluccia, et al. Expires January 20, 2007 [Page 3]
Internet-Draft MIPv6 Privacy Ext July 2006
(2) the routing is suboptimal.
4. Our Proposal
In our scheme a mobile node uses the privacy extension described in
[RFC3041] to configure its home address and care-of addresses. A
mobile node must use an interface identifier for its home address
that is different from the one used for its care-of addresses. It
should also use a new interface identifier when configuring a new
care-of address. As a result, it would be more difficult for an
eavesdropper to identify a mobile node's identity and track its
movement.
We also propose to assign to each mobile node a TMI (Temporary Mobile
Identifier) that is a 128-bit long random number. This TMI is used
by the mobile node's home agent and correspondent nodes to identify
the mobile node. This TMI might be used by the correspondent node to
index the correspondent IPsec security association to the mobile and
might be used by firewalls to do filtering.
4.1. Protocol description
Two cases must be considered:
- Mobile Client (The mobile node initiates the communication).
- Mobile Server (the correspondent node initiates the
communication).
4.1.1. Mobile client
The mobile then uses standard Mobile IPv6 with the TMI as its home
address. Packets sent and received by a mobile node will contain its
TMI instead of its home address. As a result, the mobile identity is
hidden from the correspondent node and from potential eavesdroppers
in the network.
Note that in this case the correspondent node must never use the home
address, i.e., the TMI that is not routable, but must use the care-of
address (Mobile IPv6 should be modified to provide such
functionality.)
4.1.2. Mobile Server
In this case, the correspondent node knows the mobile identity by
definition. If a mobile node wants to hide its mobility, i.e., its
care-of address, to a particular correspondent node, it must not send
Castelluccia, et al. Expires January 20, 2007 [Page 4]
Internet-Draft MIPv6 Privacy Ext July 2006
any binding update to this correspondent node and use bi-directional
tunneling. As a result the packets that are sent to the mobile node
are addressed to its home address and encapsulated by the home agent
to its current care-of address. The decision to send or not to send
a binding update to a correspondent node is a policy issue that is
out of the scope of this draft. Any eavesdroppers between the home
agent and the mobile node is able to identify and track the mobile
movement by looking at the inner packet. Therefore we suggest to
encrypt the packets that are sent between the mobile node and its
home agent.
If the mobile node decides to use route optimization, it then sends a
binding update to its correspondent node. This binding update
contains the TMI in the home address option and the actual home
address is encoded in a newly defined binding update sub-option. Of
course to preserve privacy the binding update must be encrypted (the
security association should be indexed with the TMI and not the home
address). The correspondent node uses the binding update to bind the
TMI with the home address and the care-of address.
Subsequent packets between the mobile node and the correspondent node
will contain the TMI in the home address option and in the routing
header extension instead of the actual home address. As a result an
eavesdropper won't be able to identify the packets belonging to a
particular node.
4.2. Temporary Mobile Identifier (TMI)
4.2.1. TMI generation
The TMI of a mobile node should be globally unique and must be
locally unique. By locally unique we mean that two mobile nodes
communicating with the same correspondent node/or home agent must use
different TMIs but two mobile nodes communicating with different
correspondent nodes can use the same TMI. The consequences of two
mobile nodes using the same TMI with the same correspondent node is
similar than the consequences of two mobile nodes using the same home
address with standard mobile IPv6. The correspondent node might get
confused...
We propose derive the TMI from the SHA-1 message digest of the mobile
node's home address. The mobile node's home address being globally
unique, the TMI collision probability is therefore very small.
Furthermore the probably of two mobile nodes generating the same TMI
and communicating with the same correspondent node is even smaller
and negligible.
SHA-1 was chosen because its particular properties were adequate to
Castelluccia, et al. Expires January 20, 2007 [Page 5]
Internet-Draft MIPv6 Privacy Ext July 2006
produce the desired level of randomness and uniqueness. IPv6 nodes
are already required to implement SHA-1 as part of IPsec [RFC4301]
and [RFC4305].
4.2.2. TMI management
The TMI of a mobile user must be changed periodically (every few
minutes, hours or days) in order to avoid TMI leakage as explained in
[RFC3041]...
For example, the digest for the new TMI can be generated as follows:
new digest = SHA-112 (home address | old digest), where "|" stands
for concatenation and SHA-112 the 112 first bits of SHA-1.
A dedicated prefix of 16 bits should used and TMI allocated into this
prefix (i.e., an address in this prefix is known to be a TMI). This
has some drawbacks and many advantages:
- the first 16 bits are fixed (but 112 bits should be enough to keep
the collision probability very close to zero).
- a TMI is very easy to recognize by bad guys.
+ any mobile node can be automatically authorized to use any address
in this prefix.
+ this prefix can be marked as unroutable, i.e., a wrong packet to a
TMI destination will be dropped by the first router, not the first
default free router. In general misuses of TMI become very easy
to detect.
4.3. Ownership extension
The routing optimization evolves towards more security so we propose
an extension with an integrated ownership proof. Note that some new
protection devices for routing optimization signaling integrate
privacy mechanisms as [ID.privacy-omipv6].
The TMI still begins with a dedicated prefix marked as not routable
but the digest is derived from a public key and a random value. The
new digest generation rule is: digest = SHA-112 (PublicKey | imprint)
where imprint is a 128-bit temporary random value.
The proof of ownership is the same than for CGAs [RFC3972]: the
PublicKey and the imprint are sent to the correspondent and messages
are signed by the PrivateKey.
There are essentially two ways an adversary can impersonate a mobile
Castelluccia, et al. Expires January 20, 2007 [Page 6]
Internet-Draft MIPv6 Privacy Ext July 2006
node:
1. He can try to find a RSA key pair and imprint that result to the
same TMI than the target node. Since the size of a TMI is 112
bits, the adversary has to try, on average, 2^{111} parameters
sets. If the attacker can perform 1 billion hashes per second
this would take him 8* 10^{25} years. Note that our scheme is
more secure than current Mobile IPv6 schemes that rely on CGA
addresses generated from a 59-bit long hash function.
2. He can try to retrieve the private key associated with the mobile
node's public key. A size of the modulus of at least 1024 bits
is commonly assumed to provide a good security level.
The TMI of a mobile user must be changed periodically (every few
minutes, hours or days) in order to avoid TMI leakage as explained in
[RFC3041]. This can easily be performed with the CBIDs by keeping
the same private/public key pair but changing the random value
imprint periodically.
5. Security Considerations
This document address some privacy issues in the mobile IPv6
protocols. Even if privacy does not provide real security (i.e.,
security through obscurity is poor security) then it makes the job of
bad guys (eavesdroppers, rogue correspondents, ...) harder so should
improve the overall security.
The ownership extension is modeled on the CBID/CGA idea. Security of
this idea is already well known [RFC3972] and in the mobile server
case the proof of ownership of the TMI can be coupled with a proof of
ownership of the home address, for instance when the home address is
a CGA using the same RSA private/public key pair.
6. Acknowledgments
John Wells (INRIA), Karim El-Malki (Ericsson), Hesham Soliman
(Ericsson), Jean-Michel Combes (France Telecom DR&D), Imad Add
(INRIA), Pars Mutaf (INRIA)...
7. History
This document was directly extracted from an old proposition by the
first two authors. CBID (Crypto-Based IDentifier) and HMIPv6
extensions / improvements were removed to keep the first version of
this draft very small.
Castelluccia, et al. Expires January 20, 2007 [Page 7]
Internet-Draft MIPv6 Privacy Ext July 2006
The CGA-like extension was added to the second (-01) version, the
original text is from [MWCN04].
The next version could contain more details about the use of this
proposal in the [RFC4140] context. SHA-256 could replaces SHA-1 if/
when [RFC4305] is updated.
8. IANA Considerations
Allocation of the needed prefix is the subject of [ID.khi].
9. References
9.1. Normative References
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
9.2. Informative References
[ID.khi] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", draft-laganier-ipv6-khi-02.txt (work in
progress), June 2006.
[ID.privacy-omipv6]
Haddad, W., Ed., "Anonymity and Unlinkability Extension
for OMIPv6-CGA",
draft-haddad-privacy-omipv6-anonymity-00.txt (work in
progress), June 2005.
[MWCN04] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple
Privacy Extension to Mobile IPv6", IEEE/IFIP International
Conference on Mobile and Wireless Communication Networks
(MWCN), October 2004.
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, December 2001.
Castelluccia, et al. Expires January 20, 2007 [Page 8]
Internet-Draft MIPv6 Privacy Ext July 2006
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
Castelluccia, et al. Expires January 20, 2007 [Page 9]
Internet-Draft MIPv6 Privacy Ext July 2006
Authors' Addresses
Claude Castelluccia
INRIA
Email: Claude.Castelluccia@inria.fr
Francis Dupont
CELAR
Email: Francis.Dupont@point6.net
Gabriel Montenegro
Microsoft
Castelluccia, et al. Expires January 20, 2007 [Page 10]
Internet-Draft MIPv6 Privacy Ext July 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
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.
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Castelluccia, et al. Expires January 20, 2007 [Page 11]
