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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 15 May 2000 14:51:11 -0400

The problem with having 25 mechanisms for security is that the probability
of
being able to build a secure system goes down because different vendors make
different choices and thus we get non-interoperability and even the
probability of having any
solution implemented in a given instance goes down.
 
I would prefer to see one less than perfect solution that works most of the
time
then 25 solutions, each perfect for one kind of system.   The existing
mechanisms
aren't close to good enough for such a status.  There are already too many
options.
 
I don't really care what mechanism we choose as as long as we pick one,
and then really work towards getting everyone to implement it.  The present
situation,
which AFAIK there a precious few implementations, and does not provide an
adequate
level of security, is not satisfactory.  Augmenting it with lots more
alternatives is not 
satisfactory.
 
Brian

-----Original Message-----
From: Glenn Morrow [mailto:[email-masked]]
Sent: Monday, May 15, 2000 2:08 PM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: sip
Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide

	-----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
<http://lists.bell-labs.com/mailman/listinfo/sip>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 May 2000 18:30:23 -0400

> The problem with having 25 mechanisms for security is that the probability of
> being able to build a secure system goes down because different vendors make different choices and thus we get
> non-interoperability and even the probability of having any
> I would prefer to see one less than perfect solution that works most of the time
> then 25 solutions, each perfect for one kind of system.   The existing mechanisms
> aren't close to good enough for such a status.  There are already too many options.
>  
> and then really work towards getting everyone to implement it.  The present situation,
> which AFAIK there a precious few implementations, and does not provide an adequate
> level of security, is not satisfactory.  Augmenting it with lots more alternatives is not 
> satisfactory.

I have no problems with alternatives if there is some kind of baseline
that everyone does. The situation is similar with codecs; there are lots
of choices, and sometimes people specify a baseline. Interestingly,
SIP/SDP has never specified a baseline codec, nor can we, I don't think.
Every seems to do G.711, so things work. We all know the fun involved in
standardizing baseline low rate codecs...

So, the question to me is this: should we, or need we, specify baseline
(i.e., mandatory if you do security at all) mechanisms for e2e and hop
by hop, or do we let the industry effectively pick a defacto? Brian has
argued that letting the industry pick one will lead to interop problems,
since it effectively might not pick one. Others will argue that we will
never be able to pick one, since there is no clear winner.

I don't have an easy answer for this, since its more
business/political/procedural than it is technical. I would actually
look to the ADs for input; is it necessary for an application layer
protocol to pick baseline mandatory-to-implement security mechanisms?

-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