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

Re: New XAUTH draft



Dan,

I know you don't like XAUTH and are doing everything you can to
torpedo it.  That's well and good, but it seems to me that the points
you're raising don't hold together.

If you authenticate with a shared secret, what you know is that the
other party knows the shared secret.

What does that tell you?  In the general case, nothing.

In the specific case where each of the holders of the shared secret
takes effective action to ensure it is not disclosed to third parties, 
shared secret authentication tells you that the other party is a
member of the set who's supposed to know the shared secret.

Whether that set has two members or more makes no difference.  The
mechanism tells you that the other party is a member of the set.

Yes, from the point of view of risk management it is better for the
size of that set to be small.  But it is incorrect to claim that the
only valid set size is 2.  For some applications 2 is too large, for
others it is too small.

Also, you say that XAUTH gives you unauthenticated IPSec SAs.  That
doesn't make any sense.  First of all, clearly those SAs are
authenticated to whatever granularity the initial main mode exchange
gives you.  For preshared key, that means it's authenticated to within 
the set that knows that shared secret.  How can you refer to this as
"unauthenticated"?  (Reference to April 1 RFCs isn't a useful way of
arguing these points.)

Second, I don't understand why you claim XAUTH offers no additional
security.  Or is that not what you claim?  You did use the
qualification "to the IKE secret state".  I guess in the sense that
the IKE SA related secret state is established by the main mode
exchange, that may be true in some abstract sense; the other endpoint
that holds the main mode state is authenticated by the main mode
mechanism only.  But in what way is that relevant?  That system is
acting on behalf of one or more parties, and those parties (for whom
the IPSec SAs are being set up) are authenticated by XAUTH.  You do
not get the IPSec SA unless you pass that second step.

To put it differently, can you describe an attack that demonstrates
your assertion?  Say that you and I are both using XAUTH to
authenticate with a central site, using a preshared key common to the
three of us.  Can you demonstrate an attack that allows you to
impersonate me, resulting in IPSec SAs to your box that appear to be
bound to my identity?  If so, then I would agree to your assertion.
But if not, it seems to me your assertion is either invalid or not
useful, and XAUTH is then shown to provide an additional service.

	paul


Follow-Ups: References: