Subject: [Sip] a couple of comments on henning's security draft

From: Michael Thomas <[email-masked]>
Date: Fri, 7 Dec 2001 11:27:03 -0800 (PST)

1) Your numbers on digital signatures are off by about
   an order of magnitude. If you're looking at RSA-512,
   its been deprecated since it's been cracked.

2) Nobody wants active third parties to be involved
   in authentication, but nobody's managed to do that.
   Any large-scale PKI will result in revocation
   servers unless the certificate lifetimes are
   set sufficiently short in which case you must 
   contend with the enrollment issue (not to
   mention scaling)

3) Anybody who thinks that the current web is an
   example of a widespread PKI is deluded. Clients
   almost never have certs, and while some servers
   do, web browsers don't do anything useful with
   them; eg, there's no correlation with content.

4) With SIP, unlike the web, it is almost certain
   to be the case that client identification is
   the primary problem. See comment #2.

5) Mixing the word "minimalist" with SMIME gives
   me the hives

6) The cost of public key signatures for proxies
   on each message will probably be prohibitive;
   see (1).

7) I don't understand why we need to consider
   anything but SIP itself. This sound like a
   good way to start an ocean boiling contest.

8) I don't understand why you downplay encryption.
   We already have to contend with keys carried in
   SDP.

9) Can this contend with multiple different
   authentication realms/request? Ie, my first hop
   proxy to my SP, and them my corporate proxy so
   I can get at my voice mail?

10) I think it's a general mistake to declare that
    one kind of authentication is going to win, or
    make many assumptions about that. *None* is
    the current state of affairs including the
    web, so picking the PKI/CA model is very
    suspect, and probably won't meet the needs
    of many existing auth schemes.

11) Ephemeral keys may very well be a good
    idea. This is primarily the security that TLS 
    on the web is doing today

12) I think that any security solution for SIP
    needs to consider the any-any problem, much
    like MIP WG is right now. You brought up a basic
    return routability test last time, and I think
    that something like that should be the
    absolute minimum where we can't do better.

	     Mike

_______________________________________________
Sip mailing list  http://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: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Dec 2001 18:35:47 -0500

I'm not sure how useful this "sec

>    an order of magnitude. If you're looking at RSA-512,

The numbers were provided by somebody who did the implementation
(Angelos Keromytis). Here's the complete table:

On a lightly-loaded 800Mhz PIII:
                  sign    verify    sign/s verify/s
rsa  512 bits   0.0029s   0.0002s    339.9   4256.2
rsa 1024 bits   0.0159s   0.0008s     62.9   1299.2
rsa 2048 bits   0.0974s   0.0026s     10.3    389.5

dsa  512 bits   0.0027s   0.0032s    370.6    308.6
dsa 1024 bits   0.0082s   0.0101s    122.7     98.8
dsa 2048 bits   0.0259s   0.0326s     38.6     30.7

http://www-3.ibm.com/security/cryptocards/html/perfcpq.shtml mentions
several hundred operations per second for a crypto PCI card.

>    its been deprecated since it's been cracked.

Even 16 ms (for 1024 bits) on a year-old PC doesn't seem that bad. 

>    contend with the enrollment issue (not to

I added the caveat about needed CR servers.

However, we have those revocation servers already (e.g.,
crl.verisign.com). There's no need for a *new* infrastructure.

>    them; eg, there's no correlation with content.

I mentioned that clients don't generally have certs, so I don't think
we're disagreeing. However, the lack of class-1 client certs (the ones
certifying that the email address is valid, effectively) aren't
technically hard; I have gotten a few for testing along the way and it
seemed to take about 10 minutes of web site work. However, I've always
let mine expire after the free trial period. Right now, people just
don't seem to see the need to pay a CA $14.95/year for secure email,
given that few people seem to feel the urge to encrypt or sign email.

If a carrier wanted to issue personal certs based on their subscriber
database, I don't think this would be technically hard, although this is
clearly on-going work in SACRED.

I don't understand this comment. As far as I can tell, current web
browsers make sure that if I connect to www.mybank.com, that the
certificate is indeed for www.mybank.com and not www.mafia.biz. The web
host name is contained in the CN of the certificate. 

>    the primary problem. See comment #2.

Depends on what you're talking about. For REGISTER and outbound proxies,
I probably care more about server certs. Client authentication using
shared secrets, over a secure transport, works well for REGISTER. For
e2e INVITE, certs of any sort are probably of dubious value. Knowing
that [email-masked] called, even if I can verify it, isn't too
helpful.

> 5) Mixing the word "minimalist" with SMIME gives

Sorry to inflict a skin ailment on you, but at least S/MIME is available
as a library, right now. As long as you choose one option of the many
available for each type of protection, it didn't seem that bad to me.

>    on each message will probably be prohibitive;

We can argue about whether 16 ms for signing (and less for verification)
is "prohibitive".

>    good way to start an ocean boiling contest.

I agree we should consider the cost of creating general solutions so
that we can estimate the size of the ocean. However, the cost of
deployment is going to be much less if it is shared among many protocols
and applications. Besides, this also increases the chance that more eyes
are going to look at the solution. Experiences with narrow-focus
solutions have been mixed, I'd say (see WEP and GSM).

>    We already have to contend with keys carried in

I'm not sure what text you interpret in this way. Just like I don't
really want to get into the debate of public vs. private key security, I
don't see that we're going to make a lot of progress on trying to weigh
the merits of authentication vs. encryption. I think everyone agrees
that we need both sooner rather than later. We just seem to be closer to
some parts than others.

Regarding SDP: If necessary, two parties can use IPsec+IKE to carry
their media traffic, using manyfolks negotiation. Thus, SIP-level
encryption isn't strictly necessary. Btw, I do explicitly mention the
SRTP use, so again I'm somewhat confused by where you see the
disagreement.

Without REGISTER authentication, we have a security disaster waiting to
happen. Without encryption, we get the security that we have for email
or IM today. Not what we want, but just a notch lower in my sense of
urgency. This shouldn't keep anybody from pushing to make this happen.
S/MIME is one such mechanism that is known to work and requires minimal
additional work from SIP implementors. Unfortunately, you don't like it.

>    I can get at my voice mail?

What's "this"?

>     web, so picking the PKI/CA model is very

See above. I think this is plain wrong.

>     of many existing auth schemes.

I don't think I'm declaring anything a winner, although you seem to want
to declare plenty of losers.... I'm trying to avoid re-inventing
SIP-specific wheels where we can. Our wheel factory isn't turning out
wheels all that fast.

>     on the web is doing today

Plus server identity.

>     absolute minimum where we can't do better.

Agreed. That's something I want to discuss at the meeting. I had
proposed a NULL auth scheme, but I think a Digest variation that I'm
about to write up (qop=echo) may offer a better low-cost solution.