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

Re: Comment on xauth and hybrid





Greg Carter wrote:

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

I think that Dan was talking about the use of a global pre-shared key in Phase1.
This is not Hybrid.
Could you refer me to that above mentioned thread?

With regard to DoS attacks this weakness is inherent to IKE as it is today:
I assume you are not talking about Aggressive mode which opens you to very
vicious DoS attacks no matter what authentication you are using but on MainMode.

There are three cases we need to consider:
1. The client is spoofing its address - in which case the cookie mechanism
protects the server and no DoS is possible (unless the client is in between the
server and the spoofed address, see 2.).
2. The client is using his own address but does not do any DH exponentiations -
In which case the server will be forced to do 2 DH exponentiations no matter
what authentication method is used.
3. The client is using his own address and is doing the DH computations (well
actually it can use 2^1 as a public key and thus save on the DH computations):
In Hybrid authentication the server will need to do 2 DH computations + 1
DSA/RSA signature operation while the client will need to do 2 DH computations.
In Signature authentication the server will need to do 2 DH computations + 1
DSA/RSA verification operation while the client will need to do 2 DH
computations.
I don't see much difference since DH has a bigger computational overhead.
Oh, one more thing, if you use DSA, then verification is actually more expensive
than signature. So Hybrid is even better in that respect.


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

Well they can but they already have the ACE server infrastructure and are
hesitant on having a fast transition to PKI.


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

I think we agree. I was talking about hardware legacy tokens while you are
discussing software.
I was not trying to say that Hybrid is better than signatures but that in some
situations it is not much worse.

Tamir & Moshe.




References: