[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS)
----- Original Message -----
Sent: Wednesday, November 28, 2001 10:25
AM
Subject: Gee, shared secrets suck (was: Re: SOI:
identity protection and DOS)
> > in addition to that: if you backup
the configuration of your IPsec enabled
> > device and you are
using shared secrets you must ensure that nowbody has a
> >
chance to read the backup. if you are using public keys that are
>
> authenticated using preshared information you must only make sure
that the
> > backup is tamperproof or perhaps even tamper
evidence is sufficient.
>
> Why is that? Is it because you
have somehow forgotten to also backup
> the private key part of the
public/private key pair? Sure, as long as
> you don't store
the private key anywhere in your backups, then you don't
> have to worry
about it being stolen/lost/compromised---whether it's what
I suppose most of people do not lost
their wallet or forget their password, or
...my dog chew the 'smart'
card.
Hence, no need to add/change the
public/private keys.
Or, it just the wary around in the
real life?
> we think of as a 'pre-shared secret' or
'uncertified private/public key pair.'
>
>
> But none of
this matters. No one is arguing why authentication methods
> using
public keys or digital certificates are better for authentication
> and
security than pre-shared secrets.
>
> The fact is, however, that
end users of these products have
> overwhelmingly voted with their
implementations to use pre-shared
> secrets for site-to-site
authentication (and, if you consider SecurID as
> a 'preshared secret,'
also for remote access). Creators of these
> products have done an
abyssmal job of enabling either interoperability,
> security, and
manageability using anything longer than an easily
> rattled-off
string.
>
> If you want to be sure that no one uses IKEv2 in real
networks, then
> force them to transfer a 1024-bit (or longer) value, or
even the 128-bit
> hash of that value.
>
> Everyone agrees
that PSS have defects compared to other authentication
> methods.
You protocol geeks have to pull your heads out of the packets
> and look
at how people have actually implemented the protocol management
> system
and how end users have actually implemented VPNs. You must have
>
something akin to the simplicity and shortness of PSS to ensure that
>
people will be able to at least prototype these systems in their
>
networks.
>
> When they go the long haul and build huge VPNs---if
they ever choose to
> do that---then other authentication methods, such as
digital
> certificates, will be welcome additions to the protocol.
But every
> large VPN installation starts out as a small VPN installation,
and 99%
> of small VPN installations start with pre-shared
secrets.
>
> jms
>
> --
> Joel M Snyder, 1404
East Lind Road, Tucson, AZ, 85719
> +1 520 324 0494 x101
(voice) +1 520 324 0495 (FAX)
> jms@Opus1.COM
http://www.opus1.com/jms Opus One
> Electronic mail is always the best
way to contact me.
>
>
References: