Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip] RE: Identity after reinvite)

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Dec 2004 22:54:11 -0500

inline.

Paul Kyzivat wrote:

> Jonathan - inline.
> 
>     Paul
> 
> Jonathan Rosenberg wrote:
> 
>>
>>> RFC3323 is about due for an update, I think, because the major functions
>>> that it provides can be performed without a B2BUA, thanks to new SIP
>>> mechanisms like GRUUs and session-policy. So while I agree that an
>>> anonymization service is the right approach to this problem, these 
>>> days I
>>> think you can probably build an anonymization service without building a
>>> B2BUA.
>>
>>
>> I believe this is probably true. Here's how I think it'd work:
>>
>> A client that wants to make an anonymous call contacts a TURN server 
>> providing anonymization services. That server provides the client with 
>> IP addresses and ports that it can use in its Via, contact, and SDP. 
>> The From field is anonymized. A privacy header is inserted. The 
>> request is sent via the TURN server to the user's outbound proxy. That 
>> proxy can still authenticate the client, and even insert an identity 
>> header that at least vouches that the client is a legit client that is 
>> just anonymous.
> 
> 
> While I buy the approach, I don't think what you are describing is a 
> TURN server. It is a combination of a TURN server and a SIP 
> anonymization server. And I don't even see how this can be viewed as one 
> thing. The client has to contact a TURN server from the address/port it 
> intends to use for media. 

Nothing about TURN is media specific. It gives you an IP/port on which 
you can get packets. Why not use it to get an IP/port for receiving SIP 
packets, and populate that into my via/Contact?

> For multiple media streams it needs to do this 
> multiple times from different source ports. It also has to contact the 
> sip anonymization server to set up the sip anonymization. Then it can 
> proceed as you describe.

I'm suggesting that the TURN server could provide the sip client with 
the IP/port it needs to do its own sip anonymization.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 03 Dec 2004 18:46:12 -0800

I agree with the direction this is going but I think the anonymization
services needs to be a bit more complex than a simple TURN server. A simple
TURN server would make it too easy to do statistical timing analysis of the
incoming and outgoing traffic and form the connections about who is taking
to who. Of course this is always an issue of all anonymization servers - a
service with only one user that is known is not all that anonymous. Anyways,
I think we could easily work up to something based along the lines of the
approach described below that is not  too complex to describe and is
significantly stronger than a simple relay.

On 11/24/04 12:24 AM, "Jonathan Rosenberg" <[email-masked]> wrote:

> 
> 
> Peterson, Jon wrote:
> 
>> A few notes on the "Monica property": as RFC3323 suggests, I think that some
>> sort of anonymization service, which could be instantiated by a B2BUA, is an
>> appropriate way to conceal the identity of a called or calling party. What
>> scares me a little is the way people suggest that retargeting, as opposed to
>> redirection, can inherently be expected to provide privacy. When I register
>> a contact, I can't always guarantee that the location service in question
>> will be used exclusively for retargeting rather than redirection; moreover,
>> the revelation of the target Request-URI to the caller is not the only way
>> that the caller can learn who the connected-party is: contact headers of new
>> requests in the backwards direction of the dialog, SDP in a 200 OK, and so
>> on, are information leaks that are not addressed at all by retargeting, but
>> would be addressed by an anonymization service.
>> 
>> anonymization service is the right approach to this problem, these days I
> IP addresses and ports that it can use in its Via, contact, and SDP. The
>  From field is anonymized. A privacy header is inserted. The request is
> sent via the TURN server to the user's outbound proxy. That proxy can
> still authenticate the client, and even insert an identity header that
> at least vouches that the client is a legit client that is just anonymous.
> 
> The provider of the anonymization server (turn in this case) can be
> completely decoupled from the sip provider. That provides an excellent
> level of anonymity compared to even a b2bua. The b2bua approach would
> still allow the recipient to trace the IP address in the SDP and Contact
> to the particular provider; this might not be sufficient (I don't recall
> off hand if rfc3323 discusses this problme).
> 
> It also means that there is no need to signal things like header or
> media level privacy. The client simply chooses to obfuscate (using the
> learned turn addresses) whatever fields it wishes to anonymize. This has
> the impact of simplifying the privacy spec significantly. Indeed, it
> would seem that it is hardly needed at all...
> 
> -Jonathan R.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Dec 2004 08:30:42 -0500

Jonathan Rosenberg wrote:
 >> anonymization server. And I don't even see how this can be viewed as
 >> one thing. The client has to contact a TURN server from the
 >> address/port it intends to use for media.
 >
 > you can get packets. Why not use it to get an IP/port for receiving
 > SIP packets, and populate that into my via/Contact?
 >
 >> For multiple media streams it needs to do this multiple times from
 >> different source ports. It also has to contact the sip anonymization
 >> server to set up the sip anonymization. Then it can proceed as you
 >> describe.
 >

OK. I think I entirely misinterpretted what you were saying:

>>> providing anonymization services. That server provides the client 
>>> with IP addresses and ports that it can use in its Via, contact, and 
>>> SDP.

With the understanding that it will take multiple requests to the TURN 
server to accumulate all of these addresses.

 >>> The From field is anonymized. A privacy header is inserted.

By the client.  (I had assumed you meant by the server.)

 >>> The
>>> request is sent via the TURN server to the user's outbound proxy. 
>>> That proxy can still authenticate the client, and even insert an 
>>> identity header that at least vouches that the client is a legit 
>>> client that is just anonymous.

OK. This now sounds plausible to me.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 00:37:11 -0500

Cullen Jennings wrote:

> to who.

I'm not sure I follow how this attack works; can you elaborate?

Of course this is always an issue of all anonymization servers - a
> service with only one user that is known is not all that anonymous.

How is the user known evne in this case? Recognizing the voice or 
something you mean?

  Anyways,
> significantly stronger than a simple relay.

Another related approach would be to have the client use the transcoding 
framework 
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-02.txt), 
though I think the turn approach might have better security properties - 
need to think about it though.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 07 Dec 2004 11:25:16 -0800

> I'm not sure I follow how this attack works; can you elaborate?

Alice sends a packet to the the anonymizer, and the next packet out of the
anonymizer goes to Bob. If you can watch the traffic in and out of the
anonymizer, it becomes clear that Alice is talking to Bob. One solution is
to have enough traffic that you can delay packets slightly and send packets
to many places within the time delay.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Dec 2004 12:11:09 -0800

> to many places within the time delay.

This strikes me as a losing proposition: if I can do
traffic analysis at the anonymizer, you are probably not
likely to remain very anonymous, or at least anonymous
enough for government work. In order for this to really
work, you'd need a routing equivalent of P-boxes (and 
S-boxes?) for a suitably large value of P. Or something.

		Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 7 Dec 2004 16:07:59 -0600

> to many places within the time delay.

Methinks a B2BUA would be subject to the same sort of analysis attack.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 17:43:25 -0500

I agree with Dean here.

I think that the attack the anonymizer is trying to prevent is one where 
the "attacker" is just a participant in the call; that is, we are not 
worried about cases where they are eavesdropping on other calls or 
attacking the anonymizers, etc.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 07 Dec 2004 16:48:54 -0800

Fair enough - there are many levels one can go to to try and be anonymous -
depends on what your attack model is.