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

RE: Please save the pre-shared key mode



On Fri, 7 Dec 2001, Michael Choung Shieh wrote:
> We have the point here.  2nd approach is definitely better.  It's
> preferrable for us but it's not preferrable for the sys admin.  If I am the
> sys admin to setup hundreds of devices for employee's at-home gateway, using
> PK in 2nd approach will kill me.

As always, different people have different tradeoffs, and thus will need
to use different solutions. 

> 1st approach is easier for the admin.  However, why use PK if we need to
> expose private-key.

Because it avoids PSK-specific complications in the *protocol*.  The 1st
approach is administratively no better than PSK, but it's also no worse,
so PSK can be eliminated without causing any major problems. 

> IKEv1 has option of PSK and PK but most users choose PSK.  Before we kill
> it, let's think about the reason of PSK popularity.

Probably it's mostly because existing implementations tend to give you
only two choices:  PSK, and PKI/certificate/X.509 madness.  FreeS/WAN
offers a non-PKI public-key option and it is quite widely used.  It would
see still more use if there were a standard non-PKI/certificate/X.509 way
to move RSA keys around; as it is, interoperability approaches nil because
nobody *else* is willing to accept simple, unadorned RSA keys as a basis
for signature authentication mode.

> Why do we want to kill
> a feature which most users use?  Is it insecure, or just because we (IPsec
> community) think PK is better?

Because it is one more feature in a protocol which definitely has too many
already, and badly needs cutting back.  This one appears to be redundant
and unnecessary, given the possibility of equally-simple-to-administer
schemes using self-signed certs or bare public keys.  Those schemes are
not widely used at present because they are seldom provided as options,
not because there is anything wrong with them.

                                                          Henry Spencer
                                                       henry@spsystems.net



References: