[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New XAUTH draft



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.  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.

>>
>> 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.

>> 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, 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.

>> 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.

Steve

P.S.  Is there some reason you're using an ACM mbx vs. your Microsoft mbx?


References: