Firewall Wizards mailing list archives
Re: SecureID vs Certificates
From: George Capehart <capegeo () opengroup org>
Date: Wed, 14 Feb 2001 14:51:17 -0500
Crist Clark wrote:
George Capehart wrote:Tony Miedaner wrote: Hi Folks, Kind of a high level questions on trade offs between SecureID or Certificates. It would seem pretty obvious that SecureID is a better system BUT for many situations it would seem to me that certificates would be a reasonable form of two factor authentication. Can anyone provide a good reason why not to use certificates over SecureID?The degree to which you can trust the cert is dependent upon several factors . . .[snip]you've got to trust the Web..."Trust the Web?" What does that mean and why must one trust it?
<CAVEAT> References to digital certificates in the rest of this message refer specifically to X.509(v3) certs. PGP is a different matter entirely. SPKI/SDSI certs are a different universe. </CAVEAT> Sorry, that was a little glib. I was trying to point to a myriad of issues using as few words as possible. I sacrificed clarity for brevity. In the sentence from which you excerpted the quote, I was trying to give an idea of how many entities and how many dimensions authentication and authorization subsystems must trust to get everything right and not get corrupted /should_one_choose_to_accept_digital_certificates_as_authentication_tokens/. If you "trust the Web" (or *any* transport medium) and accept any kind of authentication token that does not preserve perfect forward security, you can trust it (the transport environment) to deliver trusted digital certificates. In this case, trusted means that the certificate that is presented to the authentication subsystem is the one that was sent by the entity requesting the service /and that that entity is the one that has the private key that's the partner of the public key in the cert and that the private key has not been compromised and is still in the possession of the entity who presented the public key to the CA/. SSL, SSH, IPSec, DNSSec and all the other *Secs exist because we *don't* "trust the Web" or any other transport medium. There are 'way too many ways traffic through the system can be attacked, redirected, subverted, captured and replayed, etc.
[snip]Is it even reasonable to classify certificates as two factor?No. Two factor is usually defined as something you have and something you know. *Even if* the user protects the cert with a passcode, that's doing is the equivalent of keeping your ATM card in your wallet and your wallet in your pocket. ATMs require two-factor authentication. That's why you have to present your card and then key in the PIN. That's also why SecureID users have to append the PIN they chose to the numbers generated by the SecureID device. Two factor authentication with a cert would require the presentation of the cert along with a PIN or something else. A cert by itself would be no better than an ATM card by itself . . .Not clear here. At the top it sounds like you are going to say a cert is not two factor and then go on to say that it is?
Brevity again. No, I did not mean to say that it is two-factor. It's important to make a distinction between protecting a token and accepting it. Passcode protecting a cert is somewhat (ludicrously) analogous to keeping one's ATM card in a wall safe. If I want to use it, I have to go to the safe and give it the passcode (combination). I now have the card available for use. However, when I present the card at the ATM machine, it requires that I provide a PIN along with the card before it will cough up money. Passcode protecting a cert does not make it a two-factor authentication mechanism. All that does is provide some measure of "safe" (pardon the pun :-> ) storage for the cert. To use a cert in a two-factor scheme, I'd still have to provide some kind of PIN or something that the *authenticating* process knows.
One thing to note here any way is that a password protected cert is obviously as strong, if not a little bit stronger, than a SecurID soft-token (I forget if there is a special name for those).
Hmmm. Seems to me that there are two issues here. One is how well protected the token is in its "home." In this case, I think one could argue that a cert that is protected by a good passcode probably is better protected (from snatchers) than is a relatively unprotected SecurID soft token (I don't know whether there is a special name either). On the other hand, there is the issue of "strength and trustedness" of the token as an authenticator. Here, I've got to put my money on the SecurID token (if it's used the way I'm used to see them used . . . that is, *with* the PIN). Firstly, a cert alone is only single-factor. Secondly, unless the message that presents the token is signed, there is no way to verify that the entity that is presenting the cert really is the "owner" . . . has the private key associated with the public key. AFAIAC, the only thing a cert *really* does is verify that a given public key was presented by the entity that also had the private key that completed the pair. ( Users of a public key shall be confident that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. ) RFC 2459, page 8 After that, it's a matter of how much trust to put into the CA's registration process. It's important to note, though, that as far as an authentication process is concerned, even a signed message does not guarantee anything more than that it's a legitimate cert /as far as the CA is concerned/. An authentication process *still* needs to have a way of being convinced that the John Q. Public named in the cert is one of the John Q. Publics that has an account at the bank and that, in fact, is the one who owns the account from which is being requested the transfer of $1,000,000. Authentication and authorization are "local" processes and, as such, need some "local" way of determining authenticity and authorization. This is why, unless the authenticating/authorizing entity is also the CA that issued the cert, the SecurID token can be more trusted. Firstly, the PIN that is used with the token is issued by the entity that will later be asked to authenticate the user. Secondly, replay attacks are much harder to perpetrate when authentication is based on the SecurID.
It is understood that if someone can take control your computer they may be able to use the cert.Yep. Especially if it's not passcode protected. But it's not necessary to take control of the computer to use the cert. All that's required is to be able to snarf it anytime between the time it leaves the computer and the time it gets to its destination.This is flat out wrong. Any non-broken implementation of certs is not trivially exploitable by snooping or man-in-the-middle attacks.
I think a) there's a little more to this than meets the eye, b) I've made a wrong assumption or c) we're not talking about the same thing. I think it depends upon what you mean by the phrase "implementation of certs." The situation I had envisioned was one in which one would use a digital certificate as an authentication mechanism. Certs are *everywhere*. That's the whole idea behind a PKI. That there be a way to figure out if the public key one has "really does" belong to the entity named in the DN. I've got bazillions (well not bazillions, but many) digital certificates in my cert database. I send mine out to folks with whom I want to communicate in a secure manner. There is *nothing* about the mere presentation of cert that a priori authenticates the presenter. I can present anyone's cert. Things get a little better maybe if I use my private key and sign the message in which I present the cert, but if I've stolen the laptop or key databases, it doesn't help much. Certs are good mechanisms for key distribution . . . they're not very good authentication tokens. A Google search for SPKI, SDSI, Ellison, Lampson and Rivest will yield many hours of wonderful reading on the topic. Also see Schneier's comments on the PKI universe (search on pki at www.counterpane.com). <SHORT RANT> (The most) trusted authentication tokens can only be created by the entity that will use the token in the authentication process. The main reason is that the authentication process exists so that a later authorization process can make a decision about whether or not the authenticatee is to be allowed access to some functionality (and some of the conditions associated with that access). So, even if a bank were willing to accept a third-party cert during the authentication process, it would still have previously had to go through some kind of process to capture that cert and then map it to authentication rights. In that case, it might as well become its own CA and issue its own certs, otherwise it has to trust the due diligence done by the issuing CA and its willingness, abilility, etc. to maintain its CRLs and keep its authentication database in sync with the CRL. Then, there's the hassle of having to go "outside" during the verification process. On top of that, with a cert, there's still the need to require an additional bit of authentication information. Otherwise, accepting an unsupported cert would be equivalent to accepting an ATM card without requiring a PIN. As an authentication token, third-party certs can never be as trusted as internally-generated certs, there is almost as much administrative overhead involved in accepting third-party certs as internally generated ones and there's a lot more liability involved in accepting third-party certs. Enter SDSI/SPKI for those who must use certs. </SHORT RANT>
Both methods have huge margins for abuse by the end luser. An unprotected cert on notebook PC is bad. A SecurID card with the PIN written on it or stuck to it on a Post-It(tm) node is bad. Two things to consider, IMHO, (1) which, when properly deployed, is stronger, and (2) which is more practical to properly deploy. Unlike many others here, I think a _properly deployed_ certs would be the more secure solution. However, properly deploying certs is harder from both the administrators' perspective and from a user compliance standpoint (IMHO again). Difficult enough that SecurID (hard-token only, BTW) may be the better choice. But YMMV. If you are one of the three IS sec people on the planet with technically proficient, security concious users (lucky bastard), you might be able to pull off certs beautifully.
Agreed, mostly . . . however, see above.
Of course, if we expand "certs" to mean things like smart cards then we have a much more secure solution which is more (but not completely) idiot proof, but is a lot more expensive to deploy.
Yep, and you still need PINS when they're used remotely . . . :-> -- George W. Capehart Phone: +1 704.277.4561 Fax: +1 704.853.2624 "I'd rather have a bottle in front of me than a frontal lobotomy" Anonymous _______________________________________________ firewall-wizards mailing list firewall-wizards () nfr com http://www.nfr.com/mailman/listinfo/firewall-wizards
Current thread:
- SecureID vs Certificates Tony Miedaner (Feb 12)
- Re: SecureID vs Certificates George Capehart (Feb 13)
- Re: SecureID vs Certificates Crist Clark (Feb 14)
- Re: SecureID vs Certificates Darren Reed (Feb 15)
- Re: SecureID vs Certificates George Capehart (Feb 15)
- Re: SecureID vs Certificates Marcus J. Ranum (Feb 15)
- Re: SecureID vs Certificates Darren Reed (Feb 16)
- Re: SecureID vs Certificates beldridg (Feb 16)
- Re: SecureID vs Certificates Peter Lukas (Feb 16)
- Re: SecureID vs Certificates Crist Clark (Feb 14)
- Re: SecureID vs Certificates George Capehart (Feb 15)
- Re: SecureID vs Certificates Crist Clark (Feb 15)
- Re: SecureID vs Certificates George Capehart (Feb 13)
- RE: SecureID vs Certificates Bill Jaeger (Feb 15)
- Re: SecureID vs Certificates Volker Tanger (Feb 15)
- Re: SecureID vs Certificates Peter Lukas (Feb 15)
- <Possible follow-ups>
- Re: SecureID vs Certificates Jeffery . Gieser (Feb 13)
- Re: SecureID vs Certificates Gregory Hicks (Feb 13)