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

Re: xauth requirements: vulnerabilities

  Stephane,

On Wed, 28 Jul 1999 16:51:22 EDT you wrote
> Hi Dan,
> 
> >   You can say in the largest font possible and underlined as 
> > much as you
> > want, "Be extremely careful not to bypass IKE's security by choosing a
> > weak shared secret" but the very use of this pre-shared key will make
> > it weak! There is a fundamental limit in IKE that to use pre-shared
> > keys (with Main Mode) means that the pre-shared key is bound to an IP
> > address. Since you cannot know the IP address of these remote clients
> > a priori you MUST use a shared group secret. That is by 
> > definition weak.
> 
> The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base
> Mode.  It could be a known unique value for each remote user.

Pre-shared keys don't scale. But I'll concede this point. You could somehow
manage a large radius database _and_ some monster database of unique, 
per-user pre-shared keys. Fine, but then this gets back to my original 
point some months back. It's either insecure or superfluous. If the 
pre-shared key is unique for each remote user then what's the point of 
doing XAUTH? It doesn't buy you anything except to give you a warm fuzzy 
by "using" a card to "authenticate." Proof of knowledge of the unique, 
per-person, pre-shared key would unambiguously authenticate the user. You 
can spit accounting records out the back end when the user authenticates 
if this is the real goal. Two factors? Possession of the laptop and 
knowledge of the passphrase to unlock the pre-shared key.

Authenticating with a unique pre-shared key also requires another dialog box 
(for the passphrase to unlock the pre-shared key) and runs counter to the 
other customer demand of single sign-on. Since "using" the card is paramount, 
that's the dialog box that's given. The pre-shared key is left unlocked and 
since pre-shared keys scale poorly that pre-shared key is just a shared
group key. 

Yes, it's possible to use XAUTH securely but to do so is ridiculous. Why would
someone go to double the trouble to authenticate? You're not going to sell
alot of boxes by saying that customers have to manage two secret databases
and have to go through two dialog boxes just to log in. Since the push behind 
XAUTH is supposed to be customer requirements which customer has this as a 
requirement? "I demand twice the trouble! I won't buy anything that let's
me off with just a single sign-on!"

> >   The real problem I see with XAUTH is that it promotes and encourages
> > and legitimizes an insecure use of IKE and IPSec.
> 
> 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.

This is a red herring. The issue isn't whether the pre-shared key is "weak"
or "strong". It's that XAUTH is either insecure or superfluous. Since it's
doubtful that people will want to go through the trouble of superfluous
"authentication" (with double the work) I believe that it's the former.

  Dan.
References: