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

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 15 May 2000 13:07:42 -0500

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Saturday, May 13, 2000 3:46 AM
> To:	Jonathan Rosenberg
> Cc:	sip
> Subject:	Re: [SIP] Minutes of SIP Security task force in Adelaide
> 
> > A number of people participated in the SIP Security Task Force meeting
> 
> Must have been a really secure meeting if the identity of the
> participants is secret :-)
> 
> > 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. 

> >   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. 

	I really sick of people using "NAT" as a logical fallacy in their
arguments. 

	Perhaps if we bury our heads in the sand long enough they will go
away. 

> >   o It assumes you know the public key of the party you are calling,
> > which is not a good
> > assumption.
> 
> It works in many cases. In other cases it can be made to work, e.g., via
> indirection.
> 
	Yep

> >   o It only really hides the body (and again that doesn't work well due
> > to the above).
> 
> See above.
> 
> > 
> > Initial discussion of these points led to the decision that it should
> > still be possible
> > to support end-to-end encryption as there may be some uses for it.
> 
> Agreed.
> 
> > 
> > A problem with the current end-to-end encryption scheme is, that it
> > relies on knowing the
> > public key of the other party. One way of solving that is to return a
> > public key in the
> > response and simply do a re-INVITE then. However, it was agreed that we
> > should not do
> > that, as we effectively end up duplicating IKE, or something similar.
> > 
> > Dave Oran suggested that end-to-end information that needs encryption
> > should simply go in
> > the body (don't encrypt headers). We could use multipart for this, or
> > simply allow for a
> > single body to be encrypted and define an error code to be returned if
> > the proxy needs to
> > see the body (e.g. if SDP is encrypted and message traverses a
> > firewall). The group
> > decided to accept this mechanism. The error code will only support
> > coarse granularity,
> > i.e., if multiple bodies are encrypted, you will not be told which one
> > is needed in
> > clear, just a general error saying "body not understood".
> 
> I had originally (many years ago) suggested a similar mechanism,
> assuming I understand your proposal correctly, namely to have a body
> type "SIP message", which is encrypted. A decision was made not to do
> this (I'm afraid I no longer remember the reason; might have been
> message size concerns or processing logic). If you only want to encrypt
> SDP, I disagree, for the reasons stated above. If you want to do both
> and use the "SIP message" body mechanism, I'm not against this, but this
> does entail a significant protocol change, without changing any of the
> other problems.
> 
> > 
> > Additional discussion on encryption of headers ensued. Contact is an
> > example of header
> > that can be usefully encrypted (end-to-end), but in general, there
> > doesn't seem to be a
> > whole lot of use for this (generally, if the information is relevant it
> > can't be
> > encrypted). Only want the registrar to see the Contact, not any of the
> > intermediate
> > proxies.
> 
> Again, I disagree, see above.
> 
	I see a plethora of valuable uses for separate encryption process
for the Contact and many other headers. Especially when there are
hierarchies or network ownership boundaries between UAs, proxies,
registrars, ALGs, etc..

> > 3. AUTHENTICATION (end-to-end)
> > ==============================
> 
> > 3.1 Hop-by-hop Authentication
> > =============================
> 
> > We want to have at least one mechanism specified in the SIP
> > specification.
> 
> Why? This gets into endless arguments as to which is better.
> 
	Industry standards consortia should pick one for the network they
are designing - not the protocol. If all of the public infrastructure
standards consortia agree to use the end to end SA model then that's great. 

	SIP is a protocol that should be flexible enough to support many
mechanisms. 

	For instance I might want to use one mechanism for an in-house
solution while the public infrastructure may warrant something else.

	Then again, a military or government organization may wish to use
something completely different.

	Then again, a service provider may way to do something extra if the
communications are on net.

> > 
> > It was decided that we should have the following hop-by-hop security
> > mechanisms:
> > - Server to server: IPSec using ESP transport,
> > - Client to server: IPSec using ESP transport (not clear ESP transport
> > was agreed to)
> 
> Disagree. For practical reasons, TLS is much easier to deploy (keying,
> available libraries, available infrastructure to obtain keys, etc.). Are
> there any technical reasons to force somebody to implement IPsec?
> 
	This is but one method. Go to a consortia group to get this
approved. If a vendor doesn't want to support it - then don't.

	I do agree that this is a good and scalable choice for a consortia
group building a public infrastructure network to make; however, I bet
you'll see the other stuff used as well if not in addition to. I guess what
I'm saying is "good start" but this choice is probably a bit too simplistic
and utopian.

	Many of these mechanisms are compatible.

	How many actual providers were at the meeting voicing their
opinions?

	Trust relationships between consumers, business, military,
intelligence and government are only compatible to a certain point. There
usually is a very good reason for some types of complexity. 

> > 
> > 4. Miscellaneous
> > ================
> > 
> > 4.1 Areas needing further work
> > ==============================
> > - Challenge-response doesn't work with forking (but addresses replay) as
> > only one 401
> > will get back to the caller.
> 
> This can be solved, at the cost of increased proxy complexity, by having
> the proxy gather all challenges from all branches and return them in the
> 401 response, similar to multi-proxy authentication.
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 May 2000 17:19:08 -0400

> Glenn Morrow wrote:

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.

>      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.

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. 

-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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 May 2000 18:03:07 -0400

> when encrypted. But, hop by hop does work, since the proxy can decrypt

The NAT issue is more general, in that we could imagine, for example, a
different payload format than SDP, say for event notification or as
SDPng. In all such cases, the ALG would have to return some status code
and refuse the call or hope that there are no IP addresses in the part
hidden (after all, if the inside-NAT-host is send-only, it wouldn't much
matter - not a course of action I'd recommend). It then becomes the
decision of the parties involved whether to complain to the NAT/ALG
builder, get the admin that got the company into NATs fired or reduce
their expectation of the level of service.