[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SOI: preshared
The consequence of using naked public keys in lieu
of symmetric keys is that you incur the cost of
both a DH and a RSA operation. You could
conceivably get rid of the DH if you don't care
about identity, but for preshared keys it seems
questionable why you'd want to do _either_.
Mike
Henry Spencer writes:
> On Mon, 19 Nov 2001, Michael Thomas wrote:
> > 1) Should we deem peer-peer preshared keying bogus?
>
> I think the crucial requirement here is for some *simple* method of
> authentication, which can work effectively without outside assistance or
> elaborate supporting infrastructure, as a fallback measure for use in
> simple or constrained situations and in troubleshooting. As a historical
> analogy, consider hosts.txt (aka /etc/hosts) vs. DNS.
>
> The simple mechanism doesn't have to scale, and it doesn't have to be
> particularly convenient to administer, but it should be there.
>
> There is no strong reason why the simple mechanism can't be public-key
> signatures rather than shared secrets. Public keys are immensely superior
> to shared secrets in most ways, and as we've demonstrated with FreeS/WAN,
> they don't have to be much more complicated to use. (There's a widespread
> myth that you can't do public keys without certificates; not so.)
>
> Anything involving a PKI definitely does not qualify.
>
> > 2) If not, should SOI inherently be a dual (triple...)
> > authentication mechanism protocol?
> > 3) If so, how do we bound the authentication
> > mechanisms to keep IKE manageable?
>
> There needs to be an easy-to-administer highly-scalable mechanism for
> large-scale use, and a dead-simple zero-infrastructure mechanism for
> experimenting, constrained situations, and troubleshooting. If those
> mechanisms can't be the same at the keying-protocol level -- we think they
> can, by the way -- then that's two. There is no requirement for more.
>
> Henry Spencer
> henry@spsystems.net
>
Follow-Ups:
References: