[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New XAUTH draft
Hi Stephane,
Stephane Beaulieu wrote:
>
> We understand that we would all eventually like to do away with some of
> these legacy systems, however, for the time being, our customers demand that
> we support them. XAUTH allows for us to do this by using IKE to secure it.
Yes, our customers are placing similar pressures on us, and we also use
a mechanism similar to xauth to enable radius authentication for the
time being.
> This provides a nice, easy migration path to those who would like to
> eventually fully deploy IPSec with a PKI, but for now are limited to using
> their existing infrastructures. XAUTH also ensures that these legacy system
> transactions enjoy the full security that IPSec provides.
I don't quite agree with this. I do agree that integrating radius (and
perhaps other "legacy" mechanisms) smoothes the transition to IPSec, but
I have the feeling that making it too easy will breed complacency. Also,
I think the statement about enjoying the "full security that IPSec
provides" is questionable. These mechanisms add much in the way of
complexity to IKE, and they basically reduce the authentication
mechanism to a plain-language passphrase which probably isn't too hard
to guess - meaning they *reduce* the security IPSec provides.
I agree with Steve Kent's comments regarding IKE's need for some
mechanism by which to verify user identity, but think we must make the
distinction between which IKE implementation we're referring to, and
what exactly we mean. To elaborate, in the scenarios in which xauth is
currently being employed, i.e. remote access, it is only the remote
client's IKE which has a real need to interact with the user with
respect to identity verification. To explain, let me present an example.
Imagine a policy which permits any client to access a radius server
behind the sgw, but limits all other access. When a client wishes to
access the protected net, it forms a radius-only SA, and through this
authenticates with the radius server. The radius server then interacts
with a local CA (perhaps co-located) to generate a short-lived identity
cert, and this is returned to the client as an extended radius
attribute, or something. The client then uses this cert, for which the
sgw has corresponding policy, to access the network.
What are the problems with this approach? Well, for one, the radius
server needs to know how to interact with a CA, but that's a
straightforward problem. For another, the radius server may now be
attackable through the SA. I've heard people argue that there is yet
another drawback, that being the added overhead associated with the
radius-only SA, but I think that security is not free, and you get what
you pay for.
Back to my original point, though, note an interesting characteristic of
this approach: the sgw need know nothing about radius, or any other
secondary authentication protocol - this effectively moves the
complexity outward, away from the security device, which I think is
probably a good thing. I'd be interested to hear other's thoughts on
this, and I have a feeling I will :-)
Scott
References: