[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New XAUTH draft
Hi Scott,
comments below...
> > 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 hope Tim's comment cleared this up.
>
> 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
>
I'm all for having to implement less functionality in our SG. I could sure
use the rest :) However our first consideration has to be what's the most
secure, most usable solution for our customers.
I've expressed my concerns about setting up "special SAs" for authentication
/ managment servers in my response to Ran's email. I'd like to know what
others think.
Regards,
Stephane.
Follow-Ups: