Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 16 May 2000 11:01:09 -0500

Below 

> > Glenn Morrow wrote:
> > 
> >      > Jonathan Rosenberg opened the discussion by suggesting that:
> >      > - SIP encryption (not authentication) should be deprecated,
> >      because:
> > 
> >      I strongly disagree with this. SIP encryption serves a number of
> >      useful
> >      purposes. It hides information, for example, about Contact,
> >      Subject,
> >      Organization, Retry-After, media types, media IP addresses and
> >      meeting
> >      times (in SDP), SDP k= keys, etc. All of these are irrelevant for
> >      proxy
> >      routing behavior, but highly sensitive.
> > 
> >      I agree with the disagreement.
> 
> There isn't really any disagreement. I made this obviously bold
> statement as an expression of my concerns with relying on end to end as
> the sole mechanism for privacy. In the end, we did agree that it should
> stay.
>  
	Wunderbar! Thanks for the clarification.

> > 
> >      >   o It doesn't work with NAT and firewalls
> > 
> >      That's a risk you take. I refuse to dumb down protocols for
> >      everybody
> >      just because some people are behind firewalls and NATs. There are
> >      lots
> >      of protocols or features that you can't use behind a firewall or
> >      NAT.
> > 
> >      One could consider a SIP proxy as an ALG and a firewall element,
> >      could one not? If you agree with this then it does work for NAT
> >      and firewalls.
> 
> No, this does *not* work. The body of the SIP message is encrypted with
> the public key of the target in the To field. This is therefore not
> readable by anyone except the recipient, which means that NAT,
> co-located with a proxy or otherwise, can't see it. Normal proxies don't
> need to see it, but an ALG does. Thats why SIP doesn't work through NATs
> when encrypted. But, hop by hop does work, since the proxy can decrypt
> the message.
> 
	I definitely agree if we are talking about a NAT-PT/ALG that is
trying to be a SIP firewall/proxy as well.

	Do you agree that a NAT that is not concerned with the port i.e. a
simple NAT/firewall for security, denial of service, etc.. would have a
problem with this method if indeed there was a protected SIP proxy behind
the NAT/firewall?

	Sorry again - there are so many forms of NAT/proxy/firewall and
different uses for each. 

> Anyway, I believe there are uses for e2e encryption. Like everything
> else in engineering, its a tradeoff. Go for top notch security, and you
> get no services. 
> 
	While I might be mis-interpreting something, it appears to me that
you can have just as many services with e2e encryption; however, these
services must be provided by the hosts and network entitities that are
supposed to provide and protect the services. Services are worth money and
providers distinguish themselves with services. 

	SIP e2e encryption allows services to be protected at the
application level while allowing certain proxy functions that are necessary
for hop by hop routing through say a public infrastructure.

	You can't do that with other standardized session signaling
protocols that I'm aware of.

	Anyone, I'm pretty much done with this thread. Don't want to waste
people's time including my own. I hope we can agree on the value of the
functionality.

	Thanks for the clarifications, etc.. 

	Glenn

> -Jonathan R.
> 
> 
> 
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 17 May 2000 14:04:08 +0200

Bellow.

> 
>      I definitely agree if we are talking about a NAT-PT/ALG that is trying to be a SIP firewall/proxy as well.
> 
>      Do you agree that a NAT that is not concerned with the port i.e. a simple NAT/firewall for security, denial of service, etc.. would have a problem with this method if indeed there was a protected SIP proxy behind the NAT/firewall?
> 
>      Sorry again - there are so many forms of NAT/proxy/firewall and different uses for each.
> 

There are two problems: 

1) SIP does not work with firewalls at all unless they are SIP-aware
   (probably the problem you are asking about, right?)

   Solution is straightforward: teach firewalls to speak SIP
   (reworded more generally: include ALGs); SIP-awareness can
   be either embedded in the firewalls or SIP-proxies can
   be reused for this purpose if an interface between them
   and firewalls is provided. IMHO, the latter alternative
   is preferable.

2) The second separate issue is that even if the firewalls
   are SIP-aware it doesn't help if the SIP messages are
   e2e encrypted.

   This is not a technical problem. This is network security configuration
   problem. Either your network administrator wants to eliminate traffic
   considered dangerous (e.g., SIP INVITEs with ILOVEYOU, unsolicited media) 
   centrally with firewalls  and thus has to inspect signaling (yes, this
   implies the SIP proxy administrator will know you received video from
   Mary at port X), or he has no firewalls and lets you do what you want 
   to (including privacy by encryption and receiving ILOVEYOU).

   The only technical issue here is (we seem to have consensus on it)
   a) usage of a SIP reply which says "my firewall cannot decrypt your message"
   b) go for hop-by-hop encryption (the administrator still knows about you and Mary
      but eavedroppers do not)

To answer your question: I do not see the problem with SIP-aware NATs/FWs
and HbH encryption other than your administrator seeing your signaling. If you
want to have e2e encryption of your session with Mary use your ISP w/o FWs
instead of your corporate network with them.

Jiri