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

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

Stephen,

>Some very useful comments here, thanks.  From an IPSEC VPN point of view (my
>current concern), I would say that it looks like password/pin-protected
>certificates AND some secondary user-based authentication need to be
>implemented.
>
>Since it is easy to imagine a password-protected device/certificate being
>cracked off-line (i.e. in a dark room somewhere) before an attack is mounted
>on the VPN server, then secondary authentication becomes
>necessary/essential?
>
>Some examples:
>
>1) My PC has a certificate loaded that is not password protected. The PC, if
>stolen, could be used to authenticate itself against a VPN server.  This is
>clearly a problem that must be fixed without relying on notification of the
>theft to fix it.

Presumably you mean the private key is not password protected, not that the
certificate is not.  This would be a poor design, so I'm not sure it's
relevant to the discussion.

>2) My PC has a password-protected certificate. Each time I attempt to
>connect to the VPN server, the VPN application prompts the user for the
>password to unlock the certificate. My concern here is that, if the PC is
>stolen, then the password could be cracked by trial-and-error without any
>actual connection attempts (warnings) reaching the VPN server.

True, unless one uses the Arcot approach to protecting private keys.  (See
their paper in the 1999 IEEE Security and Privacy Symposium proceedings. I
don't necessarily endorse the technique by mentioning it here, but point it
out for completeness.)

>3) My PC uses a Smartcard with a pin-protected private-key/certificate.
>Again, if the Smartcard is stolen, how long would it take to crack the pin
>number off-line and use the authentication information on a different PC
>with a VPN client kit installed. This would require the attacker to know the
>address and security requirements of the VPN servers willing to accept the
>certificate.  If the PC and Smartcard are stolen together, it is probably
>worse than case 2).

I think that one should assume that whoever steals the smart card has
collateral intelligence about where to use it, unless it just happens to be
in your wallet and the goal of the theft is the credit cards and cash.  In
that latter case, the theft of the smart card is probably not a security
problem so much as it is an inconvenience for the user.

>4) As for 3), but the Smartcard uses biometrics - thumb-print, signature,
>eye-scan. I guess this is much safer - provided you don't get gory!

As noted in another message, if one admits the ability to open up the card,
then the biometric protection is probably not very interesting.  Note that
the average college physical lab has all one needs to successfully open up
almost all of these cards and extract private keys, these days, and the
info on how to do this is being published, removing that barries as well.

>5) My PC uses one of the approaches above, but once authentication via the
>certificate is complete, enforces a secondary authentication. This
>authentication is under the control of the server, and so can't be cracked
>off-line. If an attack is mounted, the VPN server will receive 'warnings' in
>the form of authentication failures (I hope).  The authentication
>information provided in this secondary phase MUST NOT be part of the VPN
>client's automatic function.

What exaclty is an example fo the second phase authentication here?  If one
assumes use of a SecurID card, for example, why not postulate that it was
tolen at the same time as the smart card?  If a password is used, then we
have all the usual password-related problems that make guessing possible.

>The advantages of 5) seem to be:
>1) two-way authentication between the devices based on certificates.
>2) secondary, independent authentication that can't be cracked 'off-line'.
>3) an 'way out' for the non-repudiation legality.
>4) continued use of existing remote access authentication methods.
>
>I have not covered the case where a stolen PC/certificate is used to spoof a
>VPN server. Mainly because I can't think of a solution!

I don't think that #3 is a real issue here, but the rest of the points are
well taken.  However, one is making the user do through more hoops, and the
result also may still vulnerable to Trojan Horse attacks.  What you didn't
mention explicity here is that your analysis focuses on the threat posed by
physical theft of the PC and/or authentication token.  That's not a bad
model, but it's not the only one to consider, and today many folks would
rate it much lower than software-based attacks against the server or the
client.

Steve
Follow-Ups: References: