[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New XAUTH draft
On Thu, 30 Sep 1999 14:03:27 EDT you wrote
> 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.
Right, that's all you know. This person is "in the set". And that's all
you know about the IPSec SAs. The user is "in the set". But XAUTH is
supposed to provide user-level authentication. But it can't. All you
can possibly know about the IPSec SAs are that the user is "in the set"
not which specific member of the set this person is. And practically
how big are these sets? 5? 10? 1000? More? I'd say it's in the 1000 or
more range. And in that case you are effectively unauthenticated.
> 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.)
IKE is supposed to provide SAs for IPSec that only the two peers are
able to use. With a group key doing the "authentication" you lose that.
Any member of the set can snoop traffic for any other member of the set
by doing a man-in-the-middle with the unauthenticated IKE exchange
and then just forwarding the XAUTH stuff on to the gateway and back to
the client. Nothing in the XAUTH exchange binds the specific user to the
resulting IPSec SAs.
> 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.
I do a man-in-the-middle against your phase 1 exchange. Then I forward
your XAUTH messages onto the gateway. I accept the final "SET(status=OK)"
message from the gateway but send you a "SET(status=not ok)". Now I get
IPSec SAs and the gateway thinks it's you. I can even send you an IKE
delete message so you'll blow your IKE SA away. You'll think, "oh crap.
I must've entered this stuff wrong. I'll try again." Then you try again
and presumably succeed. In the mean time I have SAs that the gateway
erroneously thinks are yours.
Granted it's about as practical as other man-in-the-middle attacks but
it is possible.
All it seems XAUTH provides is something to give to those customers
that just want to continue to use their token cards (at least that's seems
to be the motivation and defense of XAUTH). But just because you want to
use a token card shouldn't mean that you have to do it insecurely. There
is a way to do it right and a draft describing it will be released shortly.
In a nutshell, the client generates a public/private key pair and uses
the token card to cause the gateway to trust the public key (in effect
he goes through a scaled down on-line certificate enrollement scheme but
does not get a certificate, it just causes the gateway to trust the key).
The IKE exchange is then authenticated with digital signatures binding
each side to the SKEYID state as well as proving identity to the other
party. As I said, it'll be out RSN.
Dan.
Follow-Ups:
References: