[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New XAUTH draft
>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.
But it can. Phase1 auth tells you the client know an IKE pre-shared secret,
Phase1.5 (xauth) tells you that client's ID based on legacy, per user
authentication. Success at Phase 1.5 is a pre-requisite of phase2, and it is
an implementation issue on how the IPSEC-SA is associated with the Xauth
client id, QOS parameters, and any additional client-specific policy and
filtering.
>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.
It does and can. You either have fixed Intranet address in the clients, or
you assign them via IKE-CFG. The phase2 then quotes the Intranet address
back to the server in the Phase2 payload negotiation and the generated
IPSEC-SA are specific to the allocated address.
>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.
I look forward to reading it.
Steve.