Subject: RE: [Sip] Re: What consensus?

From: [email-masked]
Date: Tue, 31 Oct 2006 12:39:12 -0600

> 
> LONG TERM:
> 
> - We need to look at end-to-end security. I completely agree that it
> probably 
>   makes sense to start fresh on this (i.e., to NOT base it on SIPS).
> 
> - I believe it is very likely that at some point, this will make sips
> obsolete or
>   or at least quaint and primitive.  That's OK too. 
> 

I think this is really the heart of this dicey issue.  SIPS doesn't give end-to-end security but I would argue that end-to-end security may not be possible at all because of the basic architecture of SIP, i.e. signaling is routed through proxies.  I wonder whether you need to force signaling to not traverse proxies somehow to really guarantee end-to-end security.  If some proxy has the potential to see and modify the message, you just cannot give guarantees end-to-end.

If this conjecture is true, then we may as well just do SIPS cuz its the best we can do.

FM

_______________________________________________
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: David Benoit <[email-masked]>
Date: Tue, 31 Oct 2006 15:12:35 -0400

On Tue, Oct 31, 2006 at 12:39:12PM -0600, [email-masked] wrote:
> I think this is really the heart of this dicey issue.  SIPS doesn't
> give end-to-end security but I would argue that end-to-end security
> may not be possible at all because of the basic architecture of SIP,
> i.e. signaling is routed through proxies.  I wonder whether you need
> to force signaling to not traverse proxies somehow to really guarantee
> end-to-end security.  If some proxy has the potential to see and
> modify the message, you just cannot give guarantees end-to-end. 
> 

I've been reading this thread for a while now, and I think I should
chime in.

In any example of a commercial service using SIP, and almost all other
services I can think of, there are "things in the middle".  The world
of true "peer-to-peer" communications using SIP just doesn't exist
(especially in light of the problems addressed in the outbound draft).
Providers place proxies/B2BUAs/etc. in the middle to do a number of
things for:

 1) control: knowing that an endpoint has to communicate through a
    specific gateway/proxy/whatever you want to call it provides a
    large amount of value
 2) monetization: service providers like to charge for access, so we
    put proxies in the middle to control access to those services.
 3) privacy: how else could you effectively enforce privacy of
    information other than having a proxy/gateway strip out the
    affected information; you certainly can't trust the UAC to do it.
 4) protection: having only one (redundant) entry point into your
    network allows you to build a walled garden and build different
    levels of protection from DoS attacks, etc.
 5) simplicity: routing messages becomes MUCH easier in this type of
    setup.
 6) monitoring: SPs like to monitor the "health" of a service.  Doing
    so without clearly defined interface and anchoring points is much
    harder.
 7) peering: when one SP talks to another SP, they usually do so over
    controlled endpoints that are most certainly going to be B2BUAs.
 etc.

I think it is VERY unlikely that any SP is going to give up all of
these things, so they will continue to use stateful proxies and
B2BUAs.  This means that your conjecture is true.  SPs are not going
to want to "force signaling to not traverse proxies" because that will
directly impact those points above.  In the world of SIP, I don't
think you can actually achieve end-to-end encryption of the signaling.

I really think when you consider the problem as a whole, you will
realize that the only thing you could possibly guarantee is that the
signaling will be "private" from the UAC to the first proxy (the one
that implements all the recommendations in sip-outbound).  Even then,
if you don't provide any kind of encryption on the media, what's the
point?  Add to that the world of PSTN internetworking, CALEA, etc.,
and you can't really guarantee that anything is really "private".

David

ASIDE: is it really even useful to dictate that "SIPS" can't be over
DTLS instead of TLS?  That is only a limitation of the technology
available at the time of writing 3261, is it not?  Why not have the
"transport" parameter indicate which to use, just like we do with
"SIP"?
-- 
[email-masked] | phone: 902-832-2649  fax: 902-832-1015
 "Complex problems have simple, neat and wrong solutions" - H. L. Menken

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 14:32:56 -0600

On Oct 31, 2006, at 12:39 PM, [email-masked] wrote:

> may not be possible at all because of the basic architecture of  
> SIP, i.e. signaling is routed through proxies.  I wonder whether  
> you need to force signaling to not traverse proxies somehow to  
> really guarantee end-to-end security.  If some proxy has the  
> potential to see and modify the message, you just cannot give  
> guarantees end-to-end.

Nah, HTTPS goes through proxies without compromising the security. So  
we have a proof it can be done.

See the sipsec draft from Vijay for more discussion.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 14:42:41 -0600

>     controlled endpoints that are most certainly going to be B2BUAs.

I'd like to point out that all of the above (outside of things that  
require "looking at the sdp", which includes some privacy functions)  
can be implemented using the sipsec: approach, without any of the  
inherent weaknesses of the sip: approach. Privacy functions can be  
done by having the privacy-requesting UA make pre-arranagements with  
an anonymizer, then use info from the anonymizer to fill out its SDP  
-- more work, but without the security weakness.

--
Dean