[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New XAUTH draft
I'm still unsure why you equate XAUTH with a "common group shared secret".
XAUTH is just a mechanism to extend IKE to provide other authentication
methods. How you secure it is up to you. You can choose to use the
standard IKE mechanisms (cert. or shared secret) or Tamir's Hybrid proposal.
>From: Dan Harkins <dharkins@network-alchemy.com>
>To: Paul Koning <pkoning@xedia.com>
>CC: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com
>Subject: Re: New XAUTH draft
>Date: Thu, 30 Sep 1999 12:02:04 -0700
>
>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.
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com