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

Requirements driving xauth [was Re: Secret public keys, Re: comment on xauth and hybrid]

The various xauth threads have been most interesting, but I think Vipul
and Dan asked a question which has never been explicitly answered: why
do we need this? Stephen assessed the various threats pretty well: 

"Waters, Stephen" wrote:
> Cases:
> 1) Thief does a runner with a device with no intention of returning it.
> 2) Thief borrows the device in order to steal the primary authentication
> secret, then returns the device.

That is, there seems to be an argument for use of xauth as the second
factor in a two-factor authentication scheme, where the threat
motivating the use of this mechanism pertains to an attacker's ability
to impersonate the user by simply swiping their laptop (or hardware
token, or both), either temporarily or permanently, or otherwise gain
access to their private key, preshared key, or whatever they are using.
Note that the term "two-factor authentication", as used here, assumes
that the endpoints of the IKE SA have been mutually authenticated in a
reliable way prior to the xauth exchange.

The xauth/hybrid scheme seems to indicate that there is a need for xauth
as a primary single factor authentication mechanism (with respect to the
user). This approach would seem to obviate the need for a second factor,
since the first factor ostensibly may not be spoofed or otherwise

Now, the point has been raised that xauth would not be necessary at all
if we had a PKI in place, but that customers are not willing to make
this leap at this time. However, it appears that even if the PKI were in
place, we would still be faced with the threats Stephen mentioned. This
leads me to think that the questions are these:

1) If we rely only upon the current built-in authentication methods for
IKE, do we perceive a need for a two-factor mechanism like xauth, or for
a single-factor hybrid mechanism using passphrases?

If the answer to (1) is no, we are finished. On the other hand, if the
answer to (1) is yes (or maybe), we must ask the following:

2) Why do we perceive this need? That is, could we remove the threat by
somehow modifying the authentication mechanisms in IKE, or by better
protecting the material IKE uses for authentication?

3) In the end, if we cannot insure the integrity of our stored
authentication material, can we be sure of the integrity of the system
into which we are typing our passphrase? That is, can we be sure we're
running a "secure" ipsec implementation that's not diverting or
otherwise storing our passphrase for later use, if we cannot be sure
someone hasn't tampered with our system? 

What a can of worms... but what I think I may have convinced myself of
is this: the need for xauth is dubious if you have PKI plus some measure
of physical security for the private keys in the client. These may be
locally protected on the client's system in a number of ways, ranging
from hardware tokens to software obfuscation a la arcotsign. The point
is, if you want to use a passphrase, biometric, or other such
authentication mechanism, then it seems to make more sense from a
security perspective to use it to unlock the private key on the client's
system, and then use *that* to authenticate within IKE using the
existing public key mechanisms.