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

Re: Weak authentication in Xauth and IKE



Hello Tamir,

I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for
legacy authentication within IPSEC that can reasonably be said to provide
strong authentication.  By that standard, it is therefore the only one
which is ISAKMP compliant.  All others fall to variants of the attacks I
have posted.

Tamir Zegman wrote:
> You wrote:
> "Our suggested solution is similar to the hybrid authentication
> described in [Hyb], but that document doesn't clearly indicate
> the need for confidentiality in the Xauth exchanges."
>
> I'm a bit puzzled by this remark ...

Please forgive the poor wording of this footnote at the end of my analysis
of Xauth/IKE.  What I probably should have said was:

   [Hyb] does not motivate the need for confidentiality in Xauth
   as clearly (to me) by providing attack details.

This is *not* a criticism of [Hyb] because it is not the place of a WG
draft to detail attack scenarios.  To feel comfortable that [Hyb] resists
these kinds of attacks one must read ISAKMP, IKE, ISACFG, XAUTH, and
finally [Hyb].  One must also understand how the various cookies, IV's and
key material are generated, protected and passed between the phases and
transactions.  In recent threads you have suggested "just use Xauth/Hybrib"
and Bellovin has suggested "just use EKE".  Both are reasonable approaches
IMHO.  I thought that these threads demonstrated a disconnect between those
who consider weak secrets (even hardware tokens) adequate without some
public key techniques and those who consider them inadequate.

My suggestion was only meant to weigh into this debate with actual attack
scenarios and a simple amendment to Xauth to fix the problem. (To feel
comfortable that my suggestion resists these attacks, one need only assume
that the client detects active rogue server attacks).  My suggestion is
certainly no better than Xauth/Hybrid or EKE, and it was included merely to
point out that a better way exists *within* Xauth proper (by authenticating
the phase 1 HASH_I).

> Furthermore, your proposal does not clearly state what happens
> if XAUTH needs more than one exchange to complete. I think you
> should encrypt all responses since the first challenge could
> be a simple "User Name" challenge which a man in the middle
> attacker can easily reply to.

Agreed.  In fact I would require that all response be encrypted in the
exact same way:

   R -> I: challenge1,
   I -> R: ({K}_p, {digi, response1}_K),
   R -> I: challenge2,
   I -> R: {digi, response1}_K,
   ...

since this key K is only used for authentication of the SA and must
therefore tie all responses to HASH_I.

Respectfully,

John




Follow-Ups: References: