[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New XAUTH draft
On Thu, 30 Sep 1999 15:26:51 EDT you wrote
> Man in the middle attack?
>
> The man in the middle has to be a member of the set authenticated by
> the preshared key, right? Otherwise you can't mount that attack
> because main mode doesn't let joe random user do a man in the middle
> attack against it.
Well your question to me was:
"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."
So yea, the man-in-the-middle has to be a member of the set because
that was what your question was. Do you agree with my assertion or not?
> So now the question becomes: for applications where XAUTH would be
> considered, can you partition the set of clients into subsets such
> that the members of a particular subset are trusted not to be
> interested in mounting man in the middle attacks for impersonating
> other members of that same subset?
>
> If yes, then each subset can share a preshared key. (If no, then and
> only then is your argument against group shared keys valid for that
> particular application.)
Stop moving that bar!
The client is presumed to be coming from an unknown IP address so it's
difficult to have multiple pre-shared keys on the gateway because he
won't know which one to use. But even if you do find some way (aggressive
mode using ID_KEYID with some blob there which says "use pre-shared key
foo" for instance) you still have the burden of maintainance of the
multiple pre-shared key sets and managing who goes into what set. That
becomes very Rube Goldbergian and still does not overcome the fact that
any member in a set can snoop traffic or inpersonate any other member of
the set.
Dan.
Follow-Ups:
References: