[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 ACTION :draft-ietf-pkix-scvp- 00.txt))
Hi Eric,
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.
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.
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).
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!
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.
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!
Steve.
-----Original Message-----
From: Eric_Guerrino@LNOTES5.bankofny.com
[mailto:Eric_Guerrino@LNOTES5.bankofny.com]
Sent: Friday, July 16, 1999 6:28 PM
To: Stephen Kent
Cc: 'ietf-pkix@imc.org'
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
There are legal issues to be resolved regarding limitations of liability
and responsibilities of issuers, certificate authorities, subscribers, and
relying parties. There are legal issues to be resolved regarding digital
signatures. Last time I checked, about thirty states had enacted or were in
the process of enacting digital signature laws. The federal government has
a digital signature law pending. I was not basing my comment solely on
legal issues regarding authentication of users. What is the limitation of
liability of an issuer when a third party effects a transaction based on a
certificate the issuer has issued, after the subscriber repudiates the
transaction? What if all three parties are in three different states or,
worse, countries? Whose law applies? What happens when a CA closes shop?
Are the certificates valid or invalid? Who will relying parties consult if
they need to verify that a certificate issued by the defunct CA was valid
at a previous point in time for a disputed transaction? For how many years
must a CA keep expired certificates? What responsibility does a CA have for
providing for cessation of activities?
I initially was led to believe PKI supported non-repudiation because this
was one of the claims being made for it by its proponents. It was only
after I started examining it more closely that I realized the claims were
unsubstantiated. As long as one party can reasonably deny a fact, it is up
to the other party to prove otherwise. If I receive a transaction and act
on it, and the initiator subsequently denies the transaction, what do I
have to authenticate the user and the data? I can't claim in court that I
received and acted on a message because my server accepted it since it came
with a valid certificate, and because the signature and the message digest
were valid, based on the certificate. I need to to be able to produce the
original message, the digest, the signature, and the certificate, and be
able to show that the validity checks all passed. I also need to know what
algoritms were used. I need logs and audit records to prove the transaction
came in. And I need all this possibly months or years later. But, most of
all, I need to be able to demonstrate that I based my decision on
reasonable assurance that the originator was who they claimed to be.
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.
Granted, all this is less confusing if an originator is executing a
transaction with the issuer of the cetificate, because the issuer could
control the user authentication process. But it becomes more complex when
the certificate is used to execute a transaction with a third party. How
can a bank verify a certificate and, more importantly, vouch for a
transaction, if it can't be reasonably assured the customer is who they
claim to be? All it has is a request for validation from the third party
(merchant) and a message.
I am sure this will all be resolved over time, but at this point, I don't
feel we are close enough.
eric
Stephen Kent <kent@po1.bbn.com> on 07/16/99 03:04:48 AM
To: Eric Guerrino
cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
Date: Fri, 16 Jul 1999 03:04:48 -0400
To: Eric_Guerrino@LNOTES5
From: Stephen Kent <kent@po1.bbn.com>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Eric,
>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be
resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation
of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management
and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.
I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings. If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues? Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns. However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.
I disagree with your statement that a certificate in software binds a
system, vs. a user. Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism. Finally, why do you say that an issuer cann
associate a security policy with a certificate? We have the syntactic
means to do so as part of the standard. Do you mean that we don't have
appplications that pay attention to the policy extension?
Steve
Follow-Ups: