Subject: [Sip] SMIME in SIP

From: Rohan Mahy <[email-masked]>
Date: Sat, 16 Feb 2002 14:06:32 -0800 (Pacific Standard Time)

Mike,

comments inline...

--------------------------------------------------------------------------------
[email-masked].....
>Eric Rescorla writes:
> > Michael Thomas <[email-masked]> writes:
> > > You seem into falling into a false dichotomy that
> > > if SMIME doesn't go into bis, we are now and
> > > forever resigned to inadequate security for
> > > SIP.
> > I don't think it's a false dichotomy. Rather, it's a pretty
> > accurate statement of the common pattern. To whit: WG produces
> > a document with horrible security problems. Says, "we'll fix
> > security later". Document passes. WG doesn't fix security.
>
>Are you actually claiming that SIP without SMIME
>would be "a document with horrible security
>problems"? I sure hope not, because if you are I
>think you need to get a grip; the current PSTN
>does exactly this today, and the world has not
>come to an end.

That is the LAMEST argument I have ever heard regarding SIP security.

- First, The PSTN has been successfully hacked on occasions too numerous
to mention.  While the world hasn't come to an end, people have
actually DIED as a result of irresponsible parties attacking the PSTN.  I
don't know about your standards in this regard, but it is unacceptable to
me to build a new system/protocol that mirrors such a crappy security
model when that much is at stake.

- Second, I would like to be able to use SIP outside of walled garden
  networks.

- Third, hacking the PSTN in a major way usually requires more physical
access and a higher chance of getting caught than cracking in the IP
world.  It is just easier to attack a SIP network that is connected in
any way to the Internet, than it is to attack the PSTN.

 > > What is in bis now seems to have no support
 > > amongst those building UA's and since it's only a
 > > SHOULD there isn't even a penalty if you ignore
 > > it.
 > I'd be perfectly willing to have it a MUST if that would
 > make you happier.

>This is a perfect example of why most security
>protocols are complete failures. Making an
>unworkable and bloated thing a MUST or SHOULD does
>not change the dynamics of development, deployment
>or system engineering. If something is useless
>and/or harmful it will not be implemented,
>holier-than-thou attitudes not withstanding.

who are you calling holier-than-thou?

TLS is neither useless nor harmful.
SMIME is neither useless nor harmful, although I
  would prefer MAY strength for it.

>If we actually want to acheive something that has
>better security than the status quo -- and that is
>an abysmally low threshold as far as the eye can
>see -- it is generally prudent to actual consider
>what is feasible in the real world and provide a
>gradient which doesn't make it an all or nothing
>proposition where "nothing" is the invariable
>choice.  [snide comments elided]

Let's get specific.  You have made no proposals to date which both meet
your requirements above, and are useful in the deployed Internet at large.
Your IPsec proposal would not work through most NATs, and your other
proposals are all more complicated that the existing SMIME in bis.

I believe that the TLS support now described in bis is the closest we are
going to come to that kind of balance.  I can implement the minimum TLS
ciphersuite from open-source toolkits in 80k on a Palm or an IP phone, and
I can use it from practically anywhere, even behind NATs.  It is
currently implemented on the most widely used SIP user agent today.
That's worthy of a SHOULD in my book.

The SMIME stuff in bis is heavy, but not terribly complicated.  It is
clearly suitable for use on general purpose computers, ISUP gateways,
application servers, and high-end IP phones.  It uses a practical
key distribution model that most nerds are already familiar with.
I think that's worthy of a MAY.

thanks,
-rohan

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Sat, 16 Feb 2002 14:37:22 -0800 (PST)

1) I have said nothing about TLS in this thread

2) I haven't made a proposal for IPsec because Allison said
   that it won't go into bis regardless

3) Equating me asking that we postpone considering e2e
   mechanisms with people dying tops any claims of 
   LAMEST I can imagine.

4) TLS doesn't address UDP. IPsec WG is working on
   NAT traversal

5) In order for SMIME to work in a large scale,
   you need a large scale PKI. Good luck.

	    Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 15:00:43 -0800

>    you need a large scale PKI. Good luck.
This simply is not true. S/MIME has shared key modes. Any form of
key management that's practical for digest or IPsec is equally
practical for S/MIME.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sat, 16 Feb 2002 15:05:45 -0800 (PST)

> key management that's practical for digest or IPsec is equally

   Uh, I said large scale. As in, anything that
   might take the place of the current PSTN.

	      Mike

---

From: Ofir Arkin <[email-masked]>
Date: Sun, 17 Feb 2002 00:03:23 +0000

Guys,

This begins to look like a big piss competition and not like something 
worth while. And sorry that I step into this. I am thinking it is about 
time to stop the personal accusations and get into real stuff.

Just remember that this is more for the community than it is for any of 
us prestigious records...

Couple of things I feel that are good to mention:

1. The PSTN today is not a good module to look at when we are talking 
about security. There is no excuse to say that if the PSTN today is 
having a lot of problems with its security than the something that will 
replace it needs to be badly designed. I agree with Rohan on this one.

In my opinion we tend to forget too fast the other problems with a SIP 
based network (RTP Security?)

2. SIP and SIP Security need to challenge the worst conditions. Lab
conditions or sometimes "best practices" are not enough. You just need 
to imagine what are the worst circumstances security wise and 
operational wise you can have and think if things will work (and try them).

3. IF and IF VoIP based networks will replace the current PSTN than my 
friends access to the wire will be THE number one problem with those 
networks. There is still a VERY long way to go in securing the ENTIRE 
infrastructure than anyone really understands (as one that was incharge 
of a 4th generation wanna-be telecom company's security I am familiar 
with some of those).

4. There is no client security, and we NEVER need to trust the client side.

5. What ever encryption protocol that is using pre-shared keys is NOT 
GOOD. I can mention scalability, cloning and other nice things. BTW - 
have you seen a good PKI Internet wise implementation? (and please do 
not say PGP and do not tell me that in a BIG network this works).

6. We need to understand that there are a lot of other things that needs 
to be written about how SIP proxy/registar/redirect servers handle 
things. Several things are so basic that it frustrates to read the 
drafts. Encryption will not solve everything. Examples like who needs to 
filter relay like traffic? firewalls or proxies? and other gifted things.

BTW - who will pay the 5-30 seconds overhead with setting up the TLS 
session? you? me? the designers of the protocol? sure not, it will be 
the users... Do not forget that...

7. Wiretapping is another major thing that needs to be addressed and 
this is again and again thrown under the carpet.

8. Section 22 really needs help. See my other posts.

9. Encryption is not a simple thing. Proxies and especially stateful 
once, will have to deal will a lot of traffic and overheads.

10. If the UA's do not verify the certificates than what are we doing 
with TLS in the first place?

11. What encryption algorithms are we going to allow? This is too wide 
to interpretation... you really wish to use 40-bit DES?

12. AND what will you do with UDP? after everybody on the planet 
preached for its usage with VoIP now SIP cannot secure it? G.

These are some of the points. There are a lot more...

Now, are we going to start thinking on the correct direction again, or 
are we keeping smearing each other?

-- 
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email: 
[email-masked]
Tel: 
+44 (0) 207 495 7002
Fax: 
+44 (0) 207 495 7062
Mobile: +44 (0) 779 630 8632	

-----------------------------
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material.  Any review, re transmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited.  If you 
received this in error, please contact the sender and delete the 
material from any computer.

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 17:00:45 -0800

> 4. There is no client security, and we NEVER need to trust the client side.
Huh? No known cryptographic system does not require some trust on
the client side, at least to protect the symmetric encryption keys.

> the users... Do not forget that...
What overhead are you referring to with 5-30 seconds? 

> with TLS in the first place?
All of the public-key based key exchange schemes require the UAs to
verify certificates at some level. There's no real way around that.

> to interpretation... you really wish to use 40-bit DES?
This seems like rather a side issue. It's always been assumed that
once we settled on a confidentiality solution we'd profile a secure
set of algorithms.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Ofir Arkin <[email-masked]>
Date: Sun, 17 Feb 2002 01:45:05 +0000

Eric,

> the client side, at least to protect the symmetric encryption keys.

Who mentioned Crypto here?
Simply, in any given system you cannot trust the client side. If you 
present crypto you need to ensure the authenticity of the parties.

> What overhead are you referring to with 5-30 seconds? 

Setup time (on large scale systems), and reconnection if the session was 
shutdown and needs to restart...

You can take banking systems which use SSL v3.0 today and see what 
happens with setup times when a lot of concurrent connections are opened.

> verify certificates at some level. There's no real way around that.

Read bis-07 section 22.3.2.1. The client SHOULD verify the certificate. 
This should be a MUST (section 22.3.2.1).

> once we settled on a confidentiality solution we'd profile a secure

Don't forget to do it...

---

From: Eric Rescorla <[email-masked]>
Date: 16 Feb 2002 17:57:57 -0800

> Who mentioned Crypto here?
If you have some other way of establishing security between a client
and server pair, I'd love to hear it.

> present crypto you need to ensure the authenticity of the parties.
There's a distinction between not trusting the CLIENT and not trusting
the NETWORK enough to verify who a given client is. Which are you talking
about? 

> shutdown and needs to restart...
The only time you'd see such long setup times is if your system
is badly overloaded. The handshake proper only takes about .1s
of CPU time (if you don't accelerate) and maybe a second of network
RTTs.

> happens with setup times when a lot of concurrent connections are opened.
If you have a system which can't handle SSL and you want public key then
you need to invest in new computers or do without. SSL is pretty
much the lightest weight public key cryptographic system there is.

> This should be a MUST (section 22.3.2.1).
I agree.

-Ekr

---

From: Chris Martin <[email-masked]>
Date: Sat, 16 Feb 2002 20:37:11 -0600

I am only making inline comments to some of the comments included in the original
messages by both parties...not answering them....  :^)

> 4) TLS doesn't address UDP. IPsec WG is working on

Also will break firewall implementations, that have/are being developed by many well
known vendors, to address SIP....would require that they also decrypt to peform
pinhole allocation. Would most likely also affect SIP infrastructures already built
today based on UDP if we must suddenly implement TCP based SIP (Would have actually
been nice from the start).

>    you need a large scale PKI. Good luck.

Yep, and require that the public sign up to it, in order to facilitate
"psuedo-end-to-end" confidentiality for all calls. If you can only do it for the
enterprise or carrier networks but not enforce the public Internet you may as well not
do it at all.

>  > comments inline...

offering SMIME as an alternative at least looks forward to future certificate (PKI)
capability (As would TLS/SSL)...although as I state above this would cripple firewall
traversal by requiring in path firewalls the ability to decrypt and encrypt in order
to pinhole media.

>  > > > security later". Document passes. WG doesn't fix security.

Agree, life in general echoes this. Look at Nimda, after Code Red....admins still
didnt take heed to update security patches and were hit hard by Nimda soon after.

>  > model when that much is at stake.

1. SIP is not mirroring the PSTN model, it can if we arent careful, but right now it
does not.
2. Who died, just curious.
3. You are correct it is unacceptable not to address security when developing a
protocol.... lets find an acceptable solution.

>  > - Second, I would like to be able to use SIP outside of walled garden

This will still require SFP's/SFA's in the real world..even at home, due to the high
use of NAT (these vendors even appear to working on SFP's/SFA's).  If you dont want a
firewall at home you dont have to implement one (but I bet even you will have your own
little walled garden).        :^)

>  > any way to the Internet, than it is to attack the PSTN.

Yep. But with the implementation of SIP Proxies, SFP's/SFA's, possibly some
certificate exchanges in some scenarios (public) and IPSec in other scenarios
(Enterprise/Carrier), SIP can be made far more secure than the PSTN. Where can I
submit a draft that covers these items if it is out of scope in the SIP WG?  Shouldnt
there be a SIP Security WG where these items can be addressed directly...if you bring
this to IPSec the SIP will be out of scope, etc...?

>  >  > > SHOULD there isn't even a penalty if you ignore

The ones that will succeed will be the ones that implement something viable and
standards based...but I dont believe it has to be built into the protocol, rather it
should be built into a SIP infrastructural model.

>  > >protocols are complete failures. Making an

Which protocols are you referring to....?
IPSec is great at the network layer (where I believe this belongs for the
enterprise/carrier infrastructure) and TLS/SSL is great for clients (I believe this is
good for the public scenarios), depends on the network type that we are discussing..if
its an enterprise stronger mechansims can be used that dont slow the signaling/media,
if its a public Internet scenario then I think the upper layer prots will work, and
can be implemented at the SOHO level SFP/SFA's.

>  > who are you calling holier-than-thou?

Geeez

>  >   would prefer MAY strength for it.

Everything has its place, agree.

>  > proposals are all more complicated that the existing SMIME in bis.

Let me go back and do some reading....

>  > That's worthy of a SHOULD in my book.

I think I can agree that TLS would be an easier and lighter implementation...but......

Can the pinholes creation/allocation be performed by these NAT's? Firewalls? or would
the SDP be encrypted requiring the firewalls to be aware of the need to decrypt?
What Headers are/are not encrypted?
How many SIP implementations are implementing TCP?

I'd like to know more

>  > I think that's worthy of a MAY.

I dont have any beef about SMIME/TLS/SSL etc, as they all use some of the same popular
algorithms....but I think the difficulty lies in the myriad of firewalls present
globally......and the fact that they will need to address this additional level of
complexity to decrypt each packet (with embedded SDP)...

So you wouldnt want to encrypt the content header.....would you?

Need to catch up on the latest bs now to see where I may have erred in my responses
 :^)
Thats all folks,
Christopher A. Martin

---

From: Chris Martin <[email-masked]>
Date: Sat, 16 Feb 2002 21:02:00 -0600

By the way, forgot to define SFP and SFA..... many of the well known firewall vendors are
implementing sip firewall proxies (SFP) and sip firewall ALG's (SFA)... and tehy are also
working on proprietary MIDCOM-like models, and decomposed versions of SFP/SFA's.

---

From: Chris Martin <[email-masked]>
Date: Sat, 16 Feb 2002 20:48:53 -0600

Just offering support here...inline

> based network (RTP Security?)

Exactly....need to ensure confidentiality of the media....

> operational wise you can have and think if things will work (and try them).

Right, set up a high threat enironment and go to work performing the worst
case threats against the implementations.

> of a 4th generation wanna-be telecom company's security I am familiar

Ya, even when warnings and threats are evident admins still dont pony up to
fix the problem.

> 4. There is no client security, and we NEVER need to trust the client side.

Yep, worst security model ever is to trust the client to be secure.

> not say PGP and do not tell me that in a BIG network this works).

Right, latency, DNS issues that slow down cert exchanges, it'll be fixed
someday soon, but you are right...today its not.

> to interpretation... you really wish to use 40-bit DES?

May as well not    :^)

> are we keeping smearing each other?

Ditto....

---

From: Ofir Arkin <[email-masked]>
Date: Sun, 17 Feb 2002 03:07:38 +0000

Eric,

 > and server pair, I'd love to hear it.

Maybe I should try to explain this one differently:
Until you establish some kind of trust based on REAL things (like the 
usage of a good crypto scheme with good authentication of the two end 
systems - TLS? :P) you cannot trust the end-point hence the client.

> the NETWORK enough to verify who a given client is. Which are you talking

With security you do not trust nothing.

Hope this clarifies what I say here, which I believe you say as well.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 16 Feb 2002 19:52:30 -0800 (PST)

> been nice from the start).

   I can't parse what you're commenting on.

	   Mike

---

From: Chris Martin <[email-masked]>
Date: Sat, 16 Feb 2002 23:50:34 -0600

Sorry,
To clarify, what I was trying to say was that the introduction of any of the crypto
methods TLS/SSL/SMIME on any of the pertinent header fields can affect the way that
firewall solutions that are being developed today by many of the major vendors, as well as
MIDCOM-like vendors..will be broken, due to the fac that the implementation will be
required to decrypt portions of the message (assuming that the message body is to be
encrypted, which may contain SDP).   These implementations parse the headers for such
items as contact, call-id, SDP info (in order to open pinholes for media), to name a few.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Feb 2002 00:53:09 -0500

I think this problem is arguably a feature. If I am encrypting my SDP
information so that only the desired recipient will get it, then the
*point* is that intermediaries can't look at the information and modify
it. So, if I try to make a secure call and hear nothing, or get a
failure from one of the proxies, I will know that a secure call is not
possible in this configuration. I can then try again without such
security, or do something else (change providers, say...) as
appropriate.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Chris Martin <[email-masked]>
Date: Sun, 17 Feb 2002 09:32:47 -0600

> security, or do something else (change providers, say...) as

The provider has nothing to do with the choice of security solution
implemented by the customer... whether it is a SOHO, enterprise, or home user
with a PC firewall to protect their latest and greatest OS....if the firewall
cannot see the SDP the media will fail (Although in the PC scenario the
problem can be solved far more easily being on the same box as the client).
Carriers will have to be sensitive to customer requirements or they will not
have many customers (at least not in the enterprise space).

Now I must say that trying to build encryption methods into SIP is a good
thing....but it can also present larger issues that we should probably
address while doing this.

How do we facilitate media traversal through existing security mechanisms if
those security mechanism cannot determine what ports/ip addresses to use for
media traversal, since these mechanisms were set in place to address security
concerns?

It would affect developments such as MIDCOM,  firewalls, NAT, and even
intermediary proxies wouldnt it?

Christopher A. Martin

---

From: Michael Thomas <[email-masked]>
Date: Sun, 17 Feb 2002 12:54:17 -0800 (PST)

> items as contact, call-id, SDP info (in order to open pinholes for media), to name a few.

   I agree with Jonathan: this is a feature not a bug.
   Middle boxes are a cancer on the net.

		Mike

---

From: Chris Martin <[email-masked]>
Date: Sun, 17 Feb 2002 15:33:27 -0600

>    Middle boxes are a cancer on the net.

I agree with Johnathan as well, but I think that with the direction of security in the world
today they are a cancer that will prevail, and are required by policies and by necessity....

I also like your proposal to develop an individual draft  to address crypto and other related
issues. I am not against making the protocol secure but I believe that the other mechanisms that
you have described are valid and should be addressed as alternatives.  Alternatives are good,
and I dont believe that middleboxes will disappear, even when IPv6 becomes mainstream, due to
security concerns of business and private users alike.

Chris.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 17:49:32 -0600

> the client side, at least to protect the symmetric encryption keys.

This generally means that one can expect the client to run malicious code,
for example probing with dictionary attack to find other people's keys,
running known plain-text attacks, and so on. They're users, with a financial
incentive. Money and prestige are on the table. That makes them vicious and
clever.

On the other hand, you can at least HOPE that they won't give away their
secrets, because there is no direct financial incentive. On the gripping
hand, they usually have holes that enable third parties to steal their
secrets, which they wish to do because of similar financial incentives.
Witness the push for smart-card authentication techniques that combine
"something known" with "something owned".

3GPP security assumes that the client software outside of the SIM card is
fundamentally evil and that ever hacker has a spare supecomputer to play
with, but not a tunneling electroscope. That is, they trust only the
vendor-supplied SIM card, not the rest of the software in a phone.

--
Dean

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: 18 Feb 2002 15:54:06 -0800

> incentive. Money and prestige are on the table. That makes them vicious and
Yes, of course. This is part of the standard Internet threat model.
However, this assumption is not well captured by saying you cannot
trust the client.

-Ekr

---

From: Ofir Arkin <[email-masked]>
Date: Tue, 19 Feb 2002 00:12:05 +0000

You completely misunderstood what I was saying.

And I was not referring to the situation with Crypto. So next time 
before you shout and scream just read.

Imagine the following in a Carrier SIP-Based Solution:

Your SIP IP Phone/Softswitch is configured to use an outbound SIP Proxy 
through a manual configuration that a technician put in your phone. So, 
you are a lamer who does not understand too much in IP phones but you 
know how to read the manual. The carrier you are using is also a lame 
security aware one.

So, you go to your manual, look up how you would change the 
configuration (G no vendor can lock the damn configuration file - Oh G 
we need to add that), and change your outbound proxy to your friends IP 
address. G.

Another example, you are a smart guy who understand how stuff work. You 
do not wish to go through the SIP Proxy, but the Record-Route header is 
written... Just reprogram your softwitch to erase that line when you 
generate further signaling (of course if you are looking for IP based 
fraud you need to look at other things as well... as the actual data on 
the wire - if you are from the fraud side).

Now, if you use TLS and you use certificate and validate then for BOTH 
the server and the CLIENT than we are 95% on the safe side. If you use 
TLS like the bis-7 suggest and the client is not validating the 
certificate you are not doing anything...

If you need further more explanations, tutorials, understandings I will 
be more than willing to explain. All I see here is people miss 
understand what is about security and who you do not need to trust. 
Secure signaling between proxies is good idea but we need not forget the 
clients. What if I am able to mangle anything between an IP Phone to the 
  Gateway - Use your imagination brother.

If you cannot understand that if someone gets to the wire especially 
when you are not encrypting... G wiz.

I do not thing I am THAT stupid.

Enjoy your evening
Ofir

Dean Willis wrote:

>>>4. There is no client security, and we NEVER need to trust the client
>>>
> side.
>

---

From: Eric Rescorla <[email-masked]>
Date: 18 Feb 2002 16:38:32 -0800

> You completely misunderstood what I was saying.
Obviously. 

> understand what is about security and who you do not need to trust. 
What's necessary here is not that you provide a tutorial but rather
that you write clearly enough that people can understand what point
you're trying to make. In this particular case, your point was
a relatively obvious one that was phrased so confusingly that
I wasn't able to make out what you were trying to say.

-Ekr

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 18:38:11 -0600

Good examples!

That's what I mean by the client running malicious code or otherwise not
behaving as expected. Of course, I've also maintained that anyone billing on
SIP transactions in the way you propose is at best fortunate and at worst a
complete idiot. Unless they're very fortunate, somebody is going to abuse
them (as you have demonstrated approaches for doing), but a lot of eople
keep proposing it. I think you can only charge for things to which you add
value, and only in proportion to the perceived value added (and the
corrollary, the difficulty in getting comarable value without paying) . I've
got a standard presentation on this somewhere if you want a primer on my
amazing business philosophy. Amazing? Well, I'm amazed anybody listens to
it, considering my poor stock portfolio performance . . .

Sorry you're feeling touchy. Please take three deep breaths and vent at me
some more -- it'll probably help. I shout at myself all the time, and look
at how I feel. Of course, it's 01:30 AM here in France and I have an 0700
meeting with a pastry, so I'm headed to bed, but I promise to be amused
again tomorrow night. Good night.

--
Dean

----- Original Message -----
From: "Ofir Arkin" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "EKR" <[email-masked]>; "Michael Thomas" <[email-masked]>; "Rohan Mahy"
<[email-masked]>; <[email-masked]>
Sent: Monday, February 18, 2002 6:12 PM
Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP)

> we need to add that), and change your outbound proxy to your friends IP
. . .  more excellent examples elided in the interest of bandwidth
conservation.