Anonymization for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-anonymous-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Marc Petit-Huguenin | ||
Last updated | 2012-10-15 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-petithuguenin-p2psip-reload-anonymous-00
P2PSIP M. Petit-Huguenin Internet-Draft Impedance Mismatch Intended status: Standards Track October 15, 2012 Expires: April 18, 2013 Anonymization for REsource LOcation And Discovery (RELOAD) draft-petithuguenin-p2psip-reload-anonymous-00 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 April 18, 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 April 18, 2013 [Page 1] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 2] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 3] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 4] Internet-Draft RELOAD Anonymization October 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 should not reveal anything about its owner, so it should contain a different Node-ID than the standard RELOAD certificate, may contain an anonymous rfc822Name (e.g. anonymous@overlay.example.org), should have an empty Subject and should 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 should 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 should 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 should 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 April 18, 2013 [Page 5] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 6] Internet-Draft RELOAD Anonymization October 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 list of DestinationS s then inserted in place of the current destination. 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, and if the message is of type Tunnel and is carrying a ApplicationData DTLS message, then the same key is used to decrypt the content of the Tunnel message and the resulting RELOAD message is used as content for the new message. If not, but the top Node-ID in the decrypted destination_list and the next Onion-ID matches a 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. If the message received is a request, then the peer takes the current via_list (after inserting the Node-ID of the previous peer), encrypts it with the same session key used to encrypt or decrypt, and replaces the current via_list with a new list containing the resulting Onion-ID. The new resulting message is then signed by the peer and send as for a new message, but without end-to-end retransmission. There is a exception to the rule above in case the RELOAD message onion routed is StoreReq. Because the signer of a StoreReq is the same than the signer of the data inside it, the StoreReq message sent at the end of the decryption process is signed by the original signer using its PAC, meaning that the SecurityBlock is also sent inside the ApplicationData. This means that the receiver of a StoreReq can never be anonymous, but that should not be a concern as it is a random peer that does not implement end-to-end encryption anyway. This mechanism is inspired by the design of TOR [DINGLEDINE 04] . Petit-Huguenin Expires April 18, 2013 [Page 7] Internet-Draft RELOAD Anonymization October 2012 2.4. Sending anonymous requests A RELOAD overlay providing anonymity may 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 April 18, 2013 [Page 8] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 9] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 10] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 11] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 12] Internet-Draft RELOAD Anonymization October 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 should also implement Petit-Huguenin Expires April 18, 2013 [Page 13] Internet-Draft RELOAD Anonymization October 2012 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. Petit-Huguenin Expires April 18, 2013 [Page 14] Internet-Draft RELOAD Anonymization October 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 should 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 April 18, 2013 [Page 15] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 16] Internet-Draft RELOAD Anonymization October 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 April 18, 2013 [Page 17]