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

RE: New XAUTH draft

With regard to the need for a PKI, I too am grappling with this question.
My application deals with enterprise systems almost exclusively, so I
question the need to have 3rd party certificates and a full PKI.  The 3rd
party certificates are going to represent an up front as well as an ongoing
maintenance cost for each server and client within the system.  Why not do
it within our own IT department?

By the way, I am relatively new in this field.  Does anyone know of a good
summary of the IKE and other key distribution/management documents which I
can refer to?

Regards,


Michael Lee


> ----------
> From: 	Stephen Kent[SMTP:kent@bbn.com]
> Sent: 	Wednesday, June 09, 1999 4:50 PM
> To: 	Glen Zorn
> Cc: 	ipsec@lists.tislabs.com
> Subject: 	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
>