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

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

The XAUTH threads have raised some good questions,
but so far, not quite as many good answers, about the role
of "legacy" authentication systems based on passwords, tokens,
etc.

I present some reasons to refocus the discussion on the issue of
local vs. remote storage of credentials below.

At 03:12 PM 7/22/99 -0700, Scott G. Kelly wrote:
>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.
><trimmed...>
>> 
>> 2) Thief borrows the device in order to steal the primary authentication
>> secret, then returns the device.

We can also add:
   3) Thief steals a backup media, which is never noticed as missing.

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

Good questions.  There is a need to better deal with
credentials that can be kept in the user's head, and not on
the local disk, without requiring cards and tokens.
To fully deal with the low-entropy problem requires both
extensions to IKE auth mechanisms *and* providing as much
protection as possible for the use of the credentials
in the local and remote systems.

My main point is that there is no one perfect approach to
this for all situations, and secure remote password verifiers are
at least as important as local ones.

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

Your analysis is too simple.  Local integrity and local privacy
are distinct issues.  The vulnerability of password-derived or
password-encrypted local credentials is a separate serious issue.

For example, one might be reasonably sure that a system doesn't
have a keyboard sniffer installed right now, while at the same time
be suspicious that a backup copy of the local disk has fallen into
the wrong hands.

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

I'm not convinced.  Perhaps the need for XAUTH is dubious, but to
leap to the conclusion that local physical security is the sole
answer is wrong.  In many cases it makes more sense to keep
sensitive user credentials in a secure remote location, and use
strong remote password-based authentication (in-part) to securely
retrieve this data.  Entrust's SPEKE-enabled roaming feature is
yet another approach to a so-called "virtual smart card" system,
providing optimal use and protection for the low-entropy key,
without limiting the scope of use of the user's private key.

While XAUTH doesn't meet these goals, the need for strong mutual
authentication that can safely use low-entropy secrets
is real, and having a variety of solutions is valuable.

I strongly disagree with some opinions expressed in earlier
posts that supporting password methods will somehow slow
deployment of PKI.  Strong password methods do not pose
a threat to those seriously committed to the evolution of
robust PKI-based systems.

-- dpj

---------------------------------------------------
David P. Jablon           dpj@IntegritySciences.com
President                 +1 508 898 9024
Integrity Sciences, Inc.  www.IntegritySciences.com
Follow-Ups: References: