Re: SOI: preshared

[Michael Thomas <[e-mail]>]

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
 >                                                        [e-mail]
 >