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

Re: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS)

It is a longstanding tradition in crypto protocol discussions to assume
that pre-shared secrets, public/private keys, or compared hashes
of these objects are all of high cryptographic strength and quality.

Unfortunately, this sometimes means turning a blind eye to the fact
that the people using these systems desperately want to input, output,
and compare relatively small values.  Some might even dare say
it encourages deployment of systems that don't adequately handle
human participants, whether by allowing people to choose
insufficiently-random keys, or by relying on passive authentication
steps (e.g. comparing hash values) that people conveniently ignore.

In any case, don't be surprised if someone tells you that such
problems are "out of scope" of this discussion.


At 08:25 AM 11/28/01 -0700, Joel Snyder wrote:
>[...] 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.  

There are other protocols that can either amplify a short, simple PSS into
a large PSS suitable for IKE, or that can use a short, simple PSS to 
securely retrieve public & private credentials.  For examples, see
the discussions in the SACRED working group.

But I would think that "ease of use and deployment" should
be the stated goal, rather than "ease of prototyping".

>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. 

-- dpj
References: