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

RE: New XAUTH draft

Hi Scott,

comments below...

> 
> Hi Tim,
> 
> Tim Jenkins wrote:
> 
> <trimmed...>
> 
> > Are you perhaps mixing up XAUTH with the hybrid draft?
> > 
> > The only way XAUTH reduces the existing authentication of IKE is if
> > the sysadmin use pre-shared key authentication and share it 
> everywhere
> > or set it to null (if that's even possible).
> > 
> > Hybrid, on the other hand, does allow one end to drop the 
> existing forms
> > of authentication. But even then, the problem it's trying 
> to solve does
> > have a place with customers.
> 
> Actually, I wasn't referring only to the strength of the 
> authentication,
> although I think it's a valid thing to discuss. Presumably, secondary
> authentication is considered valuable because the primary mechanism is
> somehow at risk, e.g. the client's cert is in software, someone might
> walk off with the smart card, etc. In these cases, assume the 
> worst has
> happened, and now I'm trying to access your network. If all I 
> have to do
> is guess a passphrase, attacking your network seems something more
> doable, when compared to, say, breaking a private/public 
> keypair. On the
> other hand, I know there are bolstering mechanisms (e.g. repeated
> challenge + rsp, secureid-type token generators, etc) which 
> may mitigate
> this risk.

The purpose of using secondary authentication is mostly for a migration
path.  ISPs for example have databases with hundreds of thousands of users.
If they want to introduce IPSec, they are not going to simply tell everyone
to switch to digital certificates overnight.  It might take years to do so.
We hope that those network admins don't get complacent and take IKE
authentication too loosely when they do deploy just because they are still
using their legacy systems.

That being said XAUTH does provide a form of secondary authentication.
Granted that it's no where near as secure as IPSec, it does *add* some
security.  Hopefully your RADIUS (or whatever other) server would be set up
to deny a user who has submitted X number of consecutive bad passwords.

> 
> Perhaps more importantly, I was also referring to the stability,
> analyzability, and other security-related properties of IKE. I think
> adding proxy servers for even 1 (let alone 16) secondary 
> authentication
> protocols substantially impacts upon the security 
> characteristics of the
> implementation.

As does setting up X SAs for each remote user.

Regards,
Stephane.
Follow-Ups: