Internet DRAFT - draft-petithuguenin-p2psip-reload-anonymous
draft-petithuguenin-p2psip-reload-anonymous
P2PSIP M. Petit-Huguenin
Internet-Draft Impedance Mismatch
Intended status: Standards Track November 5, 2012
Expires: May 9, 2013
Anonymization for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-anonymous-02
Abstract
This document presents a set of techniques that a REsource LOcation
And Discovery (RELOAD) node may use to ensure that the use of high
level RELOAD operations do not reveal the owner of this node. These
high level features are defined as the set of operations related to
data storage, plus the operation that permits to exchange application
layer messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 9, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Petit-Huguenin Expires May 9, 2013 [Page 1]
Internet-Draft RELOAD Anonymization November 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operations . . . . . . . . . . . . . . . . . . . . 5
2.1. Anonymous Certificate . . . . . . . . . . . . . . . . . . 5
2.2. End to end encryption . . . . . . . . . . . . . . . . . . 5
2.3. Onion Routing . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Sending anonymous requests . . . . . . . . . . . . . . . . 8
2.5. Receiving requests anonymously . . . . . . . . . . . . . . 11
2.6. End to end encryption over onion routing . . . . . . . . . 12
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Normative sections . . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 17
A.1. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Petit-Huguenin Expires May 9, 2013 [Page 2]
Internet-Draft RELOAD Anonymization November 2012
1. Introduction
The goal of [RELOAD] is to provide a standardized and NAT friendly
access to a peer-to-peer network, with a strong security model. This
security model is designed to provide strong security guarantees even
in the face of a large number of malicious nodes, but what it is not
designed to do is to provide anonymity for any of the nodes.
There is a lot of reasons why the owner of a RELOAD node may be
reluctant to disclose this ownership, but the main motivation for
this document is to alleviate the concerns that commercial entities
may have to store data in a RELOAD overlay that is shared with
competitors. Commercial entities that needs to share such data
generally provide a way to query their database to their competitors
because they can control the access and detect datamining attempts.
A overlay definitively makes datamining more challenging but on the
other hand does not let a data owner know the rate of access to its
data. Besides, the problem is more one of perception as even if the
properties of the overlay are completely understood nobody can
guarantee that someone will not come up with a new way of harvesting
data in an overlay, making the act of storing such data a
perceptively risky operation. Adding some guarantee of anonymity to
the data stored would dissipate any reluctance because even if the
complete set of data stored is somehow captured by an hostile entity,
there is no way that this data can be linked to its owner, with the
added bonus that the processes to detect and manage datamining are no
longer needed, making an overlay a better proposition than a shared
database. In addition to anonymous storage, a node may want to be
able to retrieve data or to exchange application messages in an
anonymous way too, so this document will also apply to such
operations.
This document focuses only on anonymizing high level operations,
excluding all the overlay topology operations (Join, Leave, Update,
RouteQuery and Probe) and all the forwarding and link management
operations (Attach, AppAttach, Ping, ConfigUpdate and PathTrack
[I-D.ietf-p2psip-diagnostics] ), leaving only the data store
operations up for anonymization (Store, Fetch, Stat and Find).
AppAttach, although an application level operation, cannot be
completely anonymized and so had to be replaced by a new mechanism
that can be anonymized.
A standard RELOAD overlay leaks ownership information in various
places for the selected set of anonymizable operations:
1. Any request is signed by the originating node and is accompanied
with the certificate of the signer. This certificate may contain
information on the owner of the node, particularly in the Subject
Petit-Huguenin Expires May 9, 2013 [Page 3]
Internet-Draft RELOAD Anonymization November 2012
section.
2. Even if the certificate accompanying the request does not contain
private information, a node can send an Attach or AppAttach to
the Node-ID in the certificate to find the IP address of the node
and deduce private information.
3. The data contained in a Store request or a Fetch answer is also
signed by the owner of the data, and again accompanied by the
certificate of the owner, thus disclosing a second time the same
information than in points 1 and 2.
4. Some standard RELOAD Usages disclose the owner's Node-ID in the
data itself. This is the case for P2PSIP [I-D.ietf-p2psip-sip] ,
[REDIR] and probably more existing and future usages.
Note that RELOAD anonymization, like all security subjects, is not
some kind of magic feature that will guarantee anonymization of a
specific application - as an example, the techniques described in
this document cannot do anything to protect a node that tries to
anonymously store data containing the name of its owner.
Petit-Huguenin Expires May 9, 2013 [Page 4]
Internet-Draft RELOAD Anonymization November 2012
2. Overview of Operations
2.1. Anonymous Certificate
The first step to achieve anonymity is to separate the certificate
used for establishing connectivity from the certificate used for
signing message and data. The certificate used to establish
connectivity (i.e. used with the link layer protocols) is the one
that is already described by [RELOAD] . The certificate used to sign
messages and data must not reveal anything about its owner, so it
must contain a different Node-ID than the standard RELOAD
certificate, must contain an anonymous rfc822Name (e.g.
anonymous@overlay.example.org), must have an empty Subject and must
be a Traceable Anonymous Certificate (PAC) [RFC5636] , created from a
different key pair.
The standard certificate may be used for signing messages and data
that does not need to be anonymous, but the PAC must never be used
for connectivity, as it would unmask this identity to the neighbors
of the node. For the same reason if the PAC is used for signing a
StoreReq message it must also be used used to sign the data inside
the message. Similarly if the PAC is used to sign data in a StoreReq
message, then it must also be used to sign the StoreReq message
carrying this data. Not doing this would unmask the identity of the
sending node.
2.2. End to end encryption
This document defines a new RELOAD transaction called Tunnel, which
carries DTLS [RFC6347] messages. A successful handshake will be made
of 3 Tunnel transactions, as follow:
1. The tunnel_req message contains a ClientHello DTLS message and
the tunnel_ans message contains an HelloVerifyRequest DTLS
message.
2. The tunnel_req message contains a ClientHello DTLS message and
the tunnel_ans message contains a ServerHello, ServerKeyExchange
and ServerHelloDone DTLS messages.
3. The tunnel_req message contains a ClientKeyExchange and a
Finished DTLS message and the tunnel_ans message contains a
Finished DTLS message.
The RELOAD end to end retransmission mechanism replaces the standard
DTLS retransmission mechanism. The client and server sides of the
DTLS connection use a key pair different than the key pairs used for
the RELOAD certificates. After the handshake successfully completed,
Tunnel transactions can be used to carry ApplicationData DTLS
messages in both directions. Note that tunnelling DTLS over RELOAD
Petit-Huguenin Expires May 9, 2013 [Page 5]
Internet-Draft RELOAD Anonymization November 2012
imposes to exchange ApplicationData messages in client/server mode,
which is different from the way DTLS traditionally operates after the
handshake. Figure 1 shows the messages exchanges. Intermediate
peers are not shown in this diagram.
Alice Bob
| |
| tunnel_req(ClientHello) |
|-------------------------------------------------------------->|
| tunnel_ans(ServerHello|HelloVerifyRequest) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ClientHello) |
|-------------------------------------------------------------->|
| tunnel_ans(ServerHello|ServerKeyExchange|ServerHelloDone) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ClientKeyExchange|Finished) |
|-------------------------------------------------------------->|
| tunnel_ans(Finished) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ApplicationData) |
|-------------------------------------------------------------->|
| tunnel_ans(ApplicationData) |
|<--------------------------------------------------------------|
| |
Figure 1
The end to end encryption mechanism described here seems to offering
much when compared to running (D)TLS over a connection established by
an AppAttach transaction. The problem with AppAttach is that the IP
addresses are exchanged before the establishment of the secure
connection, which would indirectly unmask the identity of both sides.
This can be acceptable for some applications, but there are
applications that may require an additional step before revealing the
identity (e.g. by using a zero-knowledge proof) or may require to
never unmask the identity for one or both sides of a communication.
For these cases the mechanism described here will assure that each
side will be able to communicate and choose if and when they want to
reveal information that can unmask identity.
2.3. Onion Routing
To be able to hide the origin of a RELOAD message, some peers in an
overlay implement, in addition to the normal message routing
described in RELOAD, a new routing algorithm called onion routing.
Petit-Huguenin Expires May 9, 2013 [Page 6]
Internet-Draft RELOAD Anonymization November 2012
This routing mode uses a new ID called an Onion-ID and an associated
new DestinationType so this ID can be inserted in a Destination. An
Onion-ID contains a session key index and an opaque array containing
a list of DestinationS encrypted with the session key indicated by
the index.
When a peer implementing onion routing receives a message that have
an Onion-ID on the top of the destination_list (after removing its
own Node-ID), it uses the index to find the session key and decrypt
the opaque array. The resulting Destination list is then inserted in
place of the current list.
If the message received is a request, then the peer takes the current
via_list (after inserting the Node-ID of the previous peer), inverts
it, then encrypts it with the same session key than previously, and
replaces the current via_list with a new list containing the
resulting Onion-ID.
If the received message is a Tunnel message and if the signer of the
message received is also the node that requested the creation of the
session key used to decrypt the Onion-ID, then it is decrypted with
the same session key, and send as for a new message, signed by the
current node, unless the decrypted message is not a Tunnel message,
in which case the decrypted data also contains the transaction_id and
SecurityBlock, so the message can be sent signed by the original
peer.
If the received message is a Tunnel message but the the signer of the
message is not the same than the node that requested the creation of
the session key, then the session key is used to encrypt the content
of the message which is then inserted in an ApplicationData DTLS
message, itself inserted in a Tunnel message. and send as for a new
message, signed by the current node.
If the received message is not a Tunnel message then the session key
is used to encrypt the content of the message plus the transaction_id
and SecurityBlock, which is then inserted in an ApplicationData DTLS
message, itself inserted in a Tunnel message, and send as for a new
message, signed by the current node.
In all cases the new message is sent without end-to-end
retransmission. That requires the node to keep some state in case
the message received is retransmitted.
This mechanism is inspired by the design of TOR [DINGLEDINE 04] .
Petit-Huguenin Expires May 9, 2013 [Page 7]
Internet-Draft RELOAD Anonymization November 2012
2.4. Sending anonymous requests
A RELOAD overlay providing anonymity must contain a number of peers
that also implement both onion routing and the server part of the
end-to-end encryption mechanism described in the previous sections.
To permit each node requiring anonymity to find the peers that
provide this service, these peers register themselves using [REDIR] .
A node requiring anonymity shoudl implement the client part of the
end-to-end encryption mechanism. Each of theses nodes will randomly
select a number of peers providing anonymous service, and will create
a telescoping path, by first establishing a end-to-end encryption
path with the first peer, then a second encryption path through the
first encryption path, to the second peer, and so on until an end-to-
end encryption path is established with the last peer of the list.
Figure 2 shows a simplified view of this process, by replacing the 3
DTLS transactions by one named "Keys" and by using "Encrypted(Keys)"
as a shortcut for these 3 transactions inside the ApplicationData of
the Tunnel message.
Alice Onion 1 Onion 2 Onion 3
| | | |
| Keys | | |
|---------------------------->| | |
| Keys | | |
|<----------------------------| | |
| | | |
| Encrypted(Keys) | | |
|---------------------------->| Keys | |
| |----------------->| |
| | Keys | |
| Encryption(Keys) |<-----------------| |
|<----------------------------| | |
| | | |
| Encrypted(Encrypted(Keys)) | | |
|---------------------------->| Encrypted(Keys) | |
| |----------------->| Keys |
| | |------------>|
| | | Keys |
| | Encrypted(Keys) |<------------|
| Encrypted(Encrypted(Keys)) |<-----------------| |
|<----------------------------| | |
| | | |
Figure 2
The node stores the session key created by each successive peer in
the telescoping path, and will use them to prepare the
Petit-Huguenin Expires May 9, 2013 [Page 8]
Internet-Draft RELOAD Anonymization November 2012
destination_list for sending an anonymous message. The
destination_list is built by first encrypting the final destination
Node-ID with the key of the last peer in the telescopic path, and
store it as an Onion-ID, then adding the Node-ID of the final
destination on top of the Onion-ID. The rest of the destination_list
is built by encrypting the whole resulting destination_list with the
session key of the preceding peer in an Onion-ID, and adding the
Node-ID of the peer, and this recursively until all the peers in the
list have been added.
E.g. after the exchange in Figure 2 , the following destination_list
can be built to anonymously reach Bob:
[Node-ID(Onion 1), Onion-ID(Onion 1,
Node-ID(Onion 2), Onion-ID(Onion 2,
Node-ID(Onion 3), Onion-ID(Onion 3, Bob)))]
To send an anonymous message, the node will successsively encrypt it
with each session key, in the reserse order of the destination_list,
encapsulating each encryption result in an ApplicationData DTLS
message and then in a Tunnel message. When receiving a response to
its anonymous request, the node will decrypt the content of each
ApplicationData DTLS message inside a Tunnel message by using the
session keys in the same order than the destination_list of the
request sent.
By applying the onion routing rules, the data sent by Alice is
successively decrypted by each onion peer, and the response back is
successively encrypted by each onion peer, as shown in Figure 3 (T
stands for an ApplicationData DTLS message inside a Tunnel message).
Petit-Huguenin Expires May 9, 2013 [Page 9]
Internet-Draft RELOAD Anonymization November 2012
Alice Onion 1 Onion 2 Onion 3 Bob
| | | | |
|T(T(T(FetchReq))) | | | |
|----------------->| | | |
| Decrypt | | |
| |T(T(FetchReq)) | | |
| |--------------->| | |
| | Decrypt | |
| | |T(FetchReq) | |
| | |------------->| |
| | | Decrypt |
| | | |FetchReq |
| | | |---------->|
| | | | FetchAns|
| | | |<----------|
| | | Encrypt |
| | | T(FetchAns)| |
| | |<-------------| |
| | Encrypt | |
| | T(T(FetchAns))| | |
| |<---------------| | |
| Encrypt | | |
| T(T(T(FetchAns)))| | | |
|<-----------------| | | |
| | | | |
Figure 3
Petit-Huguenin Expires May 9, 2013 [Page 10]
Internet-Draft RELOAD Anonymization November 2012
2.5. Receiving requests anonymously
Some RELOAD usages store a Node-ID in the RELOAD distributed storage
so it can be used later by another node to connect to a service.
This is the case for example for P2PSIP [I-D.ietf-p2psip-sip] and
[REDIR] . A node that want to use this technique but do not want to
disclose its identity will store, in place of its Node-ID, a
Destination list similar to the one it could use to send an anonymous
request.
E.g. if the destination_list shown in Section 2.4 was stored by Alice
in the overlay, Carol could retrieve it and anonymously reach her by
using it in a request, as shown in Figure 4 .
Carol Onion 3 Onion 2 Onion 1 Alice
| | | | |
| Request | | | |
|---------->| | | |
| Encrypt | | |
| | T(Request) | | |
| |------------>| | |
| | Encrypt | |
| | | T(T(Request)) | |
| | |--------------->| |
| | | Encrypt |
| | | | T(T(T(Request))) |
| | | |------------------>|
| | | | T(T(T(Answer))) |
| | | |<------------------|
| | | Decrypt |
| | | T(T(Answer)) | |
| | |<---------------| |
| | Decrypt | |
| | T(Answer) | | |
| |<------------| | |
| Decrypt | | |
| Answer | | | |
|<----------| | | |
| | | | |
Figure 4
Petit-Huguenin Expires May 9, 2013 [Page 11]
Internet-Draft RELOAD Anonymization November 2012
2.6. End to end encryption over onion routing
Combining the techniques in the two previous sections guarantees
anonymity for both the sender and the receiver. But the exit onion
peer from the point of view of the sender and the admitting onion
peer from the point of view of the receiver (and all the intermediate
peers between those two) will see the data exchanged, as shown in
Figure 5 .
Petit-Huguenin Expires May 9, 2013 [Page 12]
Internet-Draft RELOAD Anonymization November 2012
Carol O4 O5 06 03 02 01 Alice
| | | | | | | |
|T(T(T(Req) | | | | | | |
|---------->| | | | | | |
| D | | | | | |
| |T(T(Req)) | | | | | |
| |--------->| | | | | |
| | D | | | | |
| | |T(Req) | | | | |
| | |------>| | | | |
| | | D | | | |
| | | |Req | | | |
| | | |--->| | | |
| | | | E | | |
| | | | |T(Req) | | |
| | | | |------>| | |
| | | | | E | |
| | | | | |T(T(Req)) | |
| | | | | |--------->| |
| | | | | | E |
| | | | | | |T(T(T(Req) |
| | | | | | |---------->|
| | | | | | | |
| | | | | | | T(T(T(Ans)|
| | | | | | |<----------|
| | | | | | D |
| | | | | | T(T(Ans))| |
| | | | | |<---------| |
| | | | | D | |
| | | | | T(Ans)| | |
| | | | |<------| | |
| | | | D | | |
| | | | Ans| | | |
| | | |<---| | | |
| | | E | | | |
| | | T(Ans)| | | | |
| | |<------| | | | |
| | E | | | | |
| | T(T(Ans))| | | | | |
| |<---------| | | | | |
| E | | | | | |
| T(T(T(Ans)| | | | | | |
|<----------| | | | | | |
| | | | | | | |
Figure 5
If this is a concern, then the receiving node must also implement the
Petit-Huguenin Expires May 9, 2013 [Page 13]
Internet-Draft RELOAD Anonymization November 2012
server part of the peer-to-peer encryption so the sender can
establish an end-to-end encryption eventually through the telescoping
paths on one or both sides.
Petit-Huguenin Expires May 9, 2013 [Page 14]
Internet-Draft RELOAD Anonymization November 2012
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are
appropriate when valid exceptions to a general requirement are known
to exist or appear to exist, and it is infeasible or impractical to
enumerate all of them. However, they must not be interpreted as
permitting implementors to fail to implement the general requirement
when such failure would result in interoperability failure.
Onion peer: An onion peer is a RELOAD peer that has onion routing
capabilities.
Anonymous node: An anonymous node is a RELOAD node that may want to
use anonymity for some or all of its application level operations.
4. Normative sections
Coming soon.
5. Security Considerations
Coming soon.
Petit-Huguenin Expires May 9, 2013 [Page 15]
Internet-Draft RELOAD Anonymization November 2012
6. IANA Considerations
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent,
"Traceable Anonymous Certificate", RFC 5636, August 2009.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-22 (work in
progress), July 2012.
[REDIR] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-06 (work in progress),
October 2012.
7.2. Informative References
[I-D.ietf-p2psip-diagnostics]
Song, H., Jiang, X., Even, R., and D. Bryan, "P2PSIP
Overlay Diagnostics", draft-ietf-p2psip-diagnostics-09
(work in progress), August 2012.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-07 (work in progress), January 2012.
[DINGLEDINE 04]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", In Proceedings of the
13th Usenix Security Symposium, 2004.
<https://svn.torproject.org/svn/projects/design-paper/
tor-design.pdf>
Petit-Huguenin Expires May 9, 2013 [Page 16]
Internet-Draft RELOAD Anonymization November 2012
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. TODO List
o Add normative sections.
Author's Address
Marc Petit-Huguenin
Impedance Mismatch
Email: petithug@acm.org
Petit-Huguenin Expires May 9, 2013 [Page 17]
