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

RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else)


Dan,

This is a bag of 'if buts and maybes', but XAUTH may have some value if...

I agree that using XAUTH should be avoided if possible, and if I could
eliminate all possible uses, I'd be very happy not to add more state to our
already-busy IKE state machine.  At the moment, I think I'm interested in
using XAUTH as a way of forcing contact with the VPN server.

If may laptop is stolen with a individual pre-shared secret or certificate
loaded, there is a good chance that the security protecting that secret can
be cracked 'off-line' with no 'warning' given to the VPN server that that is
taking place. I would be relying on timely notification of the theft to plug
this hole.

Cases:
1) Thief does a runner with a device with no intention of returning it.

If I force VPN client to engage in a secondary authentication phase, then
that can not be cracked off-line: the hacker needs to attempt to break-in
with exchanges to the VPN server.  The VPN server can then log repeated
failures, and take action.

2) Thief borrows the device in order to steal the primary authentication
secret, then returns the device.

In the case, where the primary authentication method is a pre-shared secret,
and the stolen/borrowed device is returned without being missed/suspected,
then the attacker can then listen-in. They can also see the XAUTH phase, and
if it is weak, they can then impersonate the client. If the XAUTH phase is
secure (challenge-based), then it should be possible to prevent the
impersonation, but the listening-in....

I'm assuming listening-in is infeasible in the case of certificates, unless
I crack their server as well.


As you say, if the Phase1 authentication is based on a poorly kept shared
(group) key, anything can happen without the need to acquire a device. I
don't see that a well chosen, unique, well secured pre-shared secret is much
worse than a certificate though.

So, it seems that XAUTH may offer some protection from impersonation if the
secondary authentication method reasonably robust. 

If pre-shared secrets are used, make sure they are treated as unique secrets
per individual, and protect them with a password-derived key, and definitely
use a robust XAUTH mechanism. 

Smartcards seem to offer some hope, but there seems to be room for debate on
just secure they are.  They are probably more secure than most software key
stores, but until we get cards that can guarantee tamper resistance, there
would seem to be a job for XAUTH.

Steve. 


-----Original Message-----
From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
Sent: Tuesday, July 20, 1999 9:58 PM
To: Vipul Gupta
Cc: kent@bbn.com; Stephen.Waters@cabletron.com; ietf-pkix@imc.org;
ipsec@lists.tislabs.com
Subject: Re: KISS for PKIX. (Was: RE:Asymmetric authentication (was
ASN.1 vs XML which in turn was something else) 


On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote
> 
>   I don't quite see the motivation behind XAUTH if it is used in
>   conjunction with regular Main/Aggressive mode since each of those
>   modes provides mutual authentication. If the client has already
>   been authenticated in Main/Aggressive mode, what is the additional
>   functionality provided by XAUTH? Or is it that the pre-shared key
>   used in Main/Aggressive mode common to *all* clients (e.g. all 
>   corporate employees) and XAUTH is used to identify a particular
>   client?

  Exactly! I brought this point up back in May. If the IKE SA has been
authenticated properly then XAUTH doesn't buy you anything. You have
the double burden of supporting a PKI and some legacy database and
the user gets yet another dialog box asking for yet another passphrase.
I find it very hard to believe that this is what people are doing when
I hear that "customers want XAUTH".

  For XAUTH to provide anything the IKE SA is authenticated with some
shared key and then the "client" authenticates himself to the "server"
with the legacy method. The problem with this is that the IKE SA and
all the SKEYID state is not authenticated. Therefore all the keys in
the IPSec SAs are not authenticated. Depending on the legacy method
this can be open to a man-in-the-middle attack too.

  draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but
the security considerations is right on in this respect.

  Dan.