[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comment on xauth and hybrid
-----Original Message-----
From: Tamir Zegman [mailto:zegman@checkpoint.com]
Sent: Thursday, July 22, 1999 8:00 AM
To: Greg Carter
Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org
Subject: Re: Comment on xauth and hybrid
Hi Greg,
In Hybrid you first authenticate the Gateway using signatures. Only then you
authenticate the client using "legacy" authentication schemes.
Authentication is mutual but different methods are employed to authenticate
the client and the Gateway, hence the term Hybrid.
[Greg Carter] Dan has already stated that these methods do not allow for
proper authentication of the IKE SA keying material. Also it introduces
another DOS attack, where the gateway is forced to do many phase 1
negotiations without ever authenticating the client.
[Greg Carter] Given that the client has the code to read and verify
certificates why can't it manage its own (or its own shared keys)? If an
organization can run an ACE server and manage 10's thousands of hardware
cards, why can they run a directory and issue certificates?
I argue that in some cases hardware based legacy authentication schemes
(e.g. SecurID cards) have advantages over PKI software tokens.
One can copy your software token without you even noticing it and then mount
on it an offline dictionary attack.
[Greg Carter] I meant 'soft' challenge/response tokens:
http://www.securitydynamics.com/products/datasheets/securidst-ds.html
<http://www.securitydynamics.com/products/datasheets/securidst-ds.html>
http://www.axent.com/product/dsbu/def2.htm#secure
<http://www.axent.com/product/dsbu/def2.htm#secure>
, which you as a SGW have no way of knowing the user is using. So you can
not guarantee that the user is using a 'hard' token, so the arguments that
challenge/response tokens are more "secure" than public key are not valid.
Bye.
Follow-Ups: