Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D A CTION :draft-ietf-pkix-scvp- 00.txt))

From: "Waters, Stephen" <[email-masked]>
Date: Mon, 19 Jul 1999 14:27:12 +0100

Stephen,

I think there is some exposure expressed here.  Apart from biometric
Smartcards, most certificate safes on laptops could be cracked 'off-line',
and then used to 'connect'.

With 'legacy authentication' such as password, SecureID, CHAP, etc.; there
is no way to crack the password off-line since the laptop does not know if
you got the answer right; only the server knows that.

As an example, I am using a certificate Smartcard with a pin-number
protected private key for VPN access to my head office.  If the laptop and
smartcard are stolen, the thief can play with them until he has cracked the
pin number. The thief can do this off-line with no contact with the VPN
server. Once cracked, they can connect to the Internet, and contact the VPN
server.

To help this situation, if the smartcard authentication was backed with a
password/SecurID challenge via IKE XAUTH, the server can at least log the
failure attempts, and could even cancel the related certificate if
sufficient failures are counted. 

To me, secondary password based authentication COULD be better than
biometric smartcards. Assuming the hackers goal was to give no 'warnings' to
the server in the form of access failures:

1) Biometric thumb-print smartcard break-in:  Hold a gun to the owner of the
thumb, or chop their thumb off and use it latter (yuk!)

2) Well-chosen password break-in:  Hold a gun to the owner until he tells
you the password/pin number.

Hell, I prefer 2) !  O.K, joshing aside, it seems that until we have
biometric smartcards, secondary 'legacy' authentication seems useful in
preventing off-line hacking.

Steve.

[email-masked]
<snip>

>Which brings me to userids and passwords, and why I must use an application
>password even if I have issued a certificate.  Passwords provide reasonable
>assurance to me that the originator is who they say they are; as long as
>the password is kept securely. Dynamic passwords (two-factor
>authentication) provide even stronger assurance that this is so. What do I,
>as a verifier, have when a certificate is used? I have no reasonable
>assurance about the originator because I have not done anything to
>authenticate them. I don't know how secure the originator's PC is. I don't
>know if they have told the browser to cache the private key password, nor
>the strength of it. I don't know if their PC will lock itself after a
>certain amount of inactivity. I don't know who has access to the PC. It is
>not difficult to copy certificate files from one system to another. If the
>password is not strong enough, it probably would not be too difficult to
>crack it. The certificate would be more reliable, for user authentication
>purposes, if I, as an issuer, could control usage of the private key and
>user authentication, or, minimally, if It is stored on some external
>device. At least this provides two-factor authentication. I can't control
>how software vendors utilize certificates in their browser products, but I
>am at their mercy if I allow my application to run from their browser. If
>risk assessment requires me to use password security anyway, I need to be
>able to show significant incremental value added by certificates, given
>that the certifcate process places a large administrative burden around all
>this.

Passwords do not address the problem you claim, above, even though one may
argue that use of a password plus a certt adds some security to the user
authentication process.   But passwords are often guessable, and can be
compromised by the same sorts of attacks that can compromise private keys
stored on PCs, protected by a password.  So, the extent to which use of a
password increase the quality of authentication depends on a number of
factors, including the perceived threat. Yes, the preferable implementation
approach is use of a personal crypto engine token, e.g., a smart card or PC
card, which counters software-based attacks designed to extract private
keys.

I am not familiar with the phrase "dynamic passwords," in a technical
context.  Are you referring to use of hardware tokens like SecurID, used in
challange-response user authentication?  If so, then I agree that such
technology is a vast improvement over static passwords, but it is not
better than the use of certs protected by similar hardware technology,
e.g., smart cards or PC cards.  Depending on the threat model, and on the
rest of the security context on which they are employed, the relative
merits of user authentication tokens vs. certs based in software are
debatable.

Your criticism of certificates ("I have no reasonable assurance about the
originator because I have not done anything to authenticate them") seems to
assume a TTP model of issunace.  If an organization does its ownh
certificate issuance, this statement simply is not true.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jul 1999 17:08:27 -0400

Stephen,

>and then used to 'connect'.

Yes.

>you got the answer right; only the server knows that.

Maybe if theft is the only concern, but if implamtation of TH software is a
concern, that we have other issues to address. Even for theft of the
laptop, if the software that takes a password for CHAP, S/KEY, etc., does
not explicitly erase it, I might be able to glean the necsaary data from a
stolen PC.

>sufficient failures are counted.

Yes, but is the added inconvenience to the user's, and the added cost of
both a PKI and the "rented" SecurID card worth the likelihood of the sort
of attack being discussed?  Still, your point is a valid one, i.e., there
are attack scenarios where the combination of user auth mechanisms is
better than use of any of the individual mechanisms alone.

>preventing off-line hacking.

As noted in another response from me, biometric smart cards don't offer
significant protection against someone with reasonable technical capability.

Steve