[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New XAUTH draft
On Mon, 24 May 1999, Stephen Kent wrote:
Sorry for the delayed response -- I've been traveling and otherwise
occupied.
> Glen,
>
> >> If I use a certificate in IKE that attests to my user name, not the name or
> >> address of my computer, then I am doing user authentication.
> >
> >Sorry, apparently I did not make myself clear. I was using the term "user
> >authentication" in the common sense -- that is to say, the sense that is
> >understood in the 95+% of installations where PKI is not existent, let
> >alone ubiquitous. In the day ("just around the corner" for the last 10
> >years or so) when PKI _is_ ubiquitous, you are absolutely correct. I am
> >obviously somewhat skeptical that that day will come very soon, but I have
> >been wrong before, so suppose I am wrong this time. In that case, the
> >inclusion of XAUTH in IKE does nothing but add useless baggage to an
> >already complex protocol. Conversely, suppose that I am right, and
> >PKI is not ubiquitous for some lengthy period. In this case, the
> >inclusion of XAUTH in IKE will likely slow PKI deployment and reduce the
> >overall security of the system (through the use of comparatively weak
> >user authentication methods). Either way, this is a bad idea.
>
> This has NOTHING to do with whether we have univerals PKIs or not. The
> context we are discussing is a closed community of users who are authorized
> to access resources. This set of users is well known, bounded, etc.,
> because the legacy systems you are so fond of can deal only with such
> communities. Thus there is NO need for ubiquitous PKIs to support these
> needs.
No need to shout, Steve.
> Organizations need only migrate their Radius databases to local PKI
> databases. In fact, it is especially easy to support online issuance of
> certs to users when you already have a legacy user authentication system.
>
Great! Sounds like we're in violent agreement that XAUTH is unnecessary,
since the required infrastructure should be easy to install.
> >>
> >> You may have a point that IKE, given its existing complexity, is an
> >> unfortunate place to add other forms of user auth, but please don't say
> >> that it does not provide user auth under the right (existing)
> >> circumstances.
> >>
> >
> >The fact that these circumstances do _not_ exist in any widespread sense
> >is the only possible rationale for the development of XAUTH, no?
>
> "Widespread sense?" I think there's confusion about the context of this
> sentence.
Fine.
>
> >> Also, because IPsec involves access control as a basic security service, if
> >> the SPD entries take the form of user names, then it is preferable that IKE
> >> be able to verify user identity, in order to support the access control
> >> features of IPsec.
> >
> >Access control means many things to many people. In the scenario under
> >discussion (remote access to some "home" network) it's hard to imagine
> >administrators managing user-level access control via IPsec filters,
> >especially if the home network is at all dynamic.
>
> Access control can be applied at various levels of granularity, true. I
> know your preference here, since we've just concluded an extended debate on
> this in the context of L2TP. You clearly didn't feel that IPsec access
> control was useful,
On the contrary, IPsec filtering is certainly useful, and not a bad hack
(though rather difficult to configure).
> and thus argued against pointing out the access control
> differences between L2TP's use of IPsec vs. native IPsec use. Part of your
> argument was that PPP implementations provide appropriate access controls,
> even though such controls are not part of the standards.
>
Actually, my main point was that IPsec filtering is less a security
feature than an efficiency hack. It should be obvious that equivalent
packet filters applied _at either end_ of a tunnel will have the same
effect on security; it _is_ more efficient (in terms of bandwidth) to
apply the filters before the traffic enters the tunnel, however. Also,
there are standards and standards; even though packet filtering in cisco
routers is not "standard" I'll wager that there are far more people who
can successfully configure a cisco filter than can configure IKE...
> >> If another protocol is employed to veriy user identity,
> >> then one creates a more complex interdependence between IPsec and the other
> >> protocol, right?
> >
> >Not sure I understand. Is the "other protocol" RADIUS? If so, there is a
> >much bigger problem then interdependence complexity, due to the severe and
> >well-known security problems with the RADIUS protocol (especially in a
> >proxied environment.
>
> I was not focusing on any specific authentication protocol, just making a
> general observation.
>
Oh, OK. I'm still not sure that I see a great deal of complexity. It
seems that the hardest thing would be to make sure that the SA goes away
when the user logs off or if user auth fails. Is that required, though?
> Steve
>
> P.S. Is there some reason you're using an ACM mbx vs. your Microsoft mbx?
>
Several, mostly having to do with personal convenience.
Follow-Ups: