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

Hi David,

David Jablon wrote:
<trimmed...>
> >
> >"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.

I think that the implications of (3) are covered by (2).

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

I don't understand what you mean by "the low-entropy problem", and don't
understand why you think IKE auth mechanisms need extending for this.
>From your previous posts, I assume you mean that IKE should support
passphrases, but it already does support preshared keys, which are
passphrases, so I'm confused.

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

I agree with the first part of this point, but would qualify that by
saying that we are not trying to cover all situations. The focus here is
on remote access to a company network. 

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

It was not meant to be an analysis; rather, it is a rhetorical question,
meant to illustrate some of the intracacies of this debate. Sorry I
didn't make that more clear. I had hoped that my subsequent comment
("What a can of worms...") would have made it clear that I recognize the
complexity here.

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

I think I understand your point, but maybe not. The term "physical
security" does not quite do justice to what I was trying to communicate,
and I could have added some more text, but then that probably wouldn't
have done it either. This is very complex stuff, and there are no simple
answers. This is why I think we need to focus on the requirements before
we run off and try to design one-size-fits-all solutions. 

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

I'm one who has expressed such opinions, so let me try to clarify my
reasoning. I think the concern has to do largely with complacency. It's
not so much the thought that supporting *password* methods will slow PKI
deployment, it's more that supporting arbitrary *legacy* mechanisms will
slow deployment.  Security is hard to understand, and also hard to
deploy. Administrators will tend to take the path of least resistance,
which in many cases may be attempting to continue using deployed
technology. For remote access, this technology usually consists of
radius, but there are others.

The people who worked on radius will tell you unequivocally that is has
major flaws with respect to security. As a security working group, the
best thing we could possibly do is steer people clear of this. Granted,
it may have been the only game in town 18 months ago, and this would
give some justification for an interim hack. Even my company's products
support radius at present, albeit not with xauth. However, doing it in
practice as an interim hack is *way* different from standardizing it,
and that is what we are discussing here.

Scott
Follow-Ups: References: