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

Re: New XAUTH draft



Glen,

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

I felt the need to shout because the mention of a ubiquitous PKI is very
much a red herring.

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

If I had my druthers, I would not encourage use of legacy systems by making
accommodations for them in IPsec.  But, the folks selling the technology
argue that it is necessary to accomnmodate these systems to facilitate
deployment of IPsec.  Given the choice between user auth via some legacy
means outside of IPsec, and the addition of support for such technoogy in
IKE, I vote for the latter, because of the better tie-in to access control,
etc.

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

Filtering at the source is not security-equivalent to filtering at the
destination. The reason for filtering at the destination is to ensure that
the range of traffic being sent matches what was negotiated when the SA was
established.  This is a critical security issue, and one of the reasons
that we debated how to phrase the differences between direct use of IPsec
and use if IPsec under PPTP for a while.  Also, your use of terminology
here is a bit odd, i.e., "configure IKE."  IKE is not where packet
filtering occurs; filtering is an integral part of IPsec, while IKE is
optional.

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

See my comments above re the need to tie user auth to access controls in IPsec.

Steve


References: