[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xauth requirements: vulnerabilities
In message <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange>, Stephane Beaulieu
writes:
>
> One of the problems lies in the fact that IPSec doesn't prohibit the use of
> "weak" shared secrets. Certainly a less security-concious person may be
> more inclined to use a "weak" shared secret when using XAUTH (despite my
> bold and triple underlined warning), but nothing prevents a less
> security-concious person from doing the exact same thing when XAUTH isn't
> there. There are methods that one could use to ensure that the shared
> secret be unique and strong, but IPSec doesn't mandate them.
Or, as David Jablon has pointed out, there are strong protocols that permit
downloading of strong shared secrets or private keys without exposure to
offline attacks based on weak shared secrets. Yes, there are patent issues
with some of them. There are also at least three different schemes proposed,
which gives the IETF a fair amount of leverage. (Disclaimer: I'm the
inventor of one of the encumbered schemes. But in the aftermath of the
break-up of AT&T, the EKE patents went to Lucent, so I no longer have
any connection with those patents. In particular, I don't benefit if
they're used; on the other hand, I no longer have any influence on the
licensing policies.)
The Perlman and Kaufman paper in NDSS '99 shows several different ways
to do what's needed here -- bootstrap from a password to a strong private
key. And they use show how both EKE and SPEKE can be used.