| P2PSIP | M.P.H. Petit-Huguenin |
| Internet-Draft | Impedance Mismatch |
| Intended status: Standards Track | November 05, 2012 |
| Expires: May 09, 2013 |
Anonymization for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-anonymous-02
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 09, 2013.
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 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.
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.
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:
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.
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.
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:
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 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.
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. 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] .
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 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).
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
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
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 .
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 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.
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.
Coming soon.
Coming soon.
| [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", Internet-Draft draft-ietf-p2psip-base-22, July 2012. |
| [REDIR] | Maenpaa, J and G Camarillo, "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", Internet-Draft draft-ietf-p2psip-service-discovery-06, October 2012. |
| [I-D.ietf-p2psip-diagnostics] | Song, H, Jiang, X, Even, R and D Bryan, "P2PSIP Overlay Diagnostics", Internet-Draft draft-ietf-p2psip-diagnostics-09, August 2012. |
| [I-D.ietf-p2psip-sip] | Jennings, C, Lowekamp, B, Rescorla, E, Baset, S and H Schulzrinne, "A SIP Usage for RELOAD", Internet-Draft draft-ietf-p2psip-sip-07, 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. |
This section must be removed before publication as an RFC.