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

RE: New XAUTH draft

> > "Waters, Stephen" wrote:
> > > 
> > > Yes, I have a comment [on ISAKMP XAUTH].  A number of the 
> authentication
> > > methods expressed here require the edge device to understand which
> > > authentication method is needed in advance of receiving 
> the 'user name' from
> > > the remote peer.
> > 
> > I would add that *all* of the authentication methods 
> require the edge
> > device to understand their respective protocols. 
> Translation? Oodles of
> > added complexity to our (secure?) key exchange protocol. 
> Godzillakmp.
> 
> An observation that many others have made, as well.  IKE is 
> just not the
> place to do user authentication.

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


> 
> > 
> > > This seems limiting to me.  Since it is likely that a 
> these 'legacy'
> > > authentication methods are being used with RADIUS, 
> wouldn't it be simple to
> > > re-use EAP and EAP extensions to RADIUS?
> > > 
> > > This would allow the 'edge device' to be ignorant of the 
> authentication
> > > required, or the process needed to enact it. This saves 
> complication in the
> > > 'edge' device, allows central control of authentication 
> policy and higher
> > > granularity on user/authentication mapping.
> > > 
> > 
> > <trimmed...>
> > 
> > Perhaps this gets to the heart of it. What is the 
> compelling argument
> > for adding such complexity to the security device in order 
> to support
> > these legacy authentication methods? 
> > Shouldn't we instead be trying to
> > move people toward PKI and other such mechanisms, rather than
> > encouraging the continued use of text passwords/phrases? 
> > 
> > Scott
> > 
>
Follow-Ups: