[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Please kill preshared key.

Sara, Bill and All:

I second the opinion to keep preshared symmetric key in IKEv2.

 * Shared secret authentication is simpler and works fine in a 
   small domain. 

 * As Sara pointed out, the performance is better. 

 * Sure, it adds more complexity, but the same argument can be made
   for public key also. The key is to weigh the added complexity against
   the benefit it derives. IMHO, the benefit outweighs the complexity. 

 * To rescind a working feature that is widely deployed is always
problematic.

If we further consider how authentication is being done in other
applications, 
we see symmetric algorithms still being widely applied, they have not being
replaced by asymmetric algorithms. 

--- Ruixi

-----Original Message-----
From: Sara Bitan [mailto:sarab@cs.Technion.AC.IL]
Sent: Friday, December 07, 2001 1:14 AM
To: sommerfeld@east.sun.com; ipsec@lists.tislabs.com
Subject: Re: Please kill preshared key.


Hi Bill!

Let's try to look at the details:
----- Original Message -----
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: <ipsec@lists.tislabs.com>
Sent: Thursday, December 06, 2001 8:47 PM
Subject: Please kill preshared key.


> Since there are people arguing to save preshared key, I just wanted to
> reemphasize that:
>
>  0) it adds cryptographic complexity -- you essentially need a
> different cryptographic protocol for PSK vs. signature keys.  Let's
> spend the cycles of our cryptographers on more important stuff than
> this.
IKE-SIGAM (and I think IKEv2 also, if PKS authentication is added) with
pre-shared key authentication differ from signatures authentication is
*exactly two points*
1) The calculation of SKEYID in IKE-SIGMA and of SKEYSEED in IKEv2.
2) If you are using signatures authentication you add a signature and
signture verification on top of the hash calculation.
>
>  1) it adds YET ONE MORE OPTION you need to test, one more knob you
> can misconfigure.. more time for customers spent fumbling around
> trying to figure out how to configure systems.
One option out of how many options?  Is this really the one that will turn a
product from an easy to configure one to a non-configurable?
>
>  2) equivalent functionality can be found in preconfigured public keys
> and/or self-signed certificates.
Is performance a non-issue? How many CPU cycles are consumed by HMAC-SHA1?
How many are consumed by RSA/DSA signature?


What about extra hardware I might need to add if public cryptography based
authentication is a must? What if I am a cellular vendor? PDA?
>
> There's no need for it, it adds complexity.  Kill it.
>
> - Bill
There is a need. Yes, it adds one more option, but the (small amount of)
complexity added here is justified, and we must support it,

 Sara