Re: SecureID vs Certificates

["Crist Clark" <crist.clark () globalstar com>]

George Capehart wrote:
> 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.

OK, I guess I am still missing something. No, we do not "trust the Web,"
if what you are saying is that we do not trust all of the routers,
sniffers, and anything else that lies between my authentication server
and the client. "The Web" == the Internet, right? You do not need to 
trust the medium to use digital certificates, that's the whole idea.

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

This analogy is not making a lot of sense to me, but I think you are 
trying to get to the concept of client side security (which we all know 
is an oxymoron)? Trouble is, we need to put _some_ trust on the other
end whenever we do remote access.

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

Both methods boil down to the same thing, the client is proving to the 
server that it knows something. In SecurID case, the client proves that
it knows a SecurID token seed (and the algorithm and the time, but those
are no longer and never were secrets, respectively) and a PIN. In the 
cert case, the client proves that it knows a cert's private key.

I think one has to be careful how much stock is put in the idea of "one 
factor" and "two factor" authentication. That arises only when talking 
about the human interaction with an authentication mechanism. 
Unfortunately, humans are not very good at remembering good secrets. 
Putting the secrets in some kind device to remember them is not great 
since the device can be stolen (a token) or perhaps copied (software).
So, we combine the two, the person has a short secret he can remember
and also has a device to store a bigger secret. Now, in the SecurID case,
we have a lil' token that carries a secret and a PIN in our person's
head. In the encrypted cert case, we have a notebook PC (or even 
a floppy disk, etc.) carrying the protected cert and our passphrase
in our human's head. BUT in both cases, the authentication servers
get ONE thing. They both get a stream of data coming over a wire.
In both cases the human at the other end had to use two things
to get that data to the server. In both cases, the server just
sees some numbers. It has no way to know if there were really 
these two factors used at the other end.

As an example of what I mean, once a user picks up a Sharpie indelible
marker and writes his PIN on the back of his token... Boom! It's now
a "one factor" device. You have that token, you have access. Where 
did the other factor go? The ideas of "factors" only exists at the 
human interface, not at the authentication server. Client side 
security... Life sucks, no?

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

Heh, if it's access to our systems, I'm making my own certs. I 
trust me. A trusted, third party CA is only needed when two parties need
to be introduced. I know everyone who I am letting in. Just as I would
be handing out SecurIDs, I hand out certs.

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

Sure you can, but like you say, this is the whole idea of public
key crypto. I can present anyone's public key, but when they challenge
me to decrypt something they encrypt with the key... I cannot do it.
I would fail to prove I have the private key and therefore fail
to authenticate. I cannot impersonate someone by just having the 
public keys.
-- 
Crist J. Clark                                Network Security Engineer
crist.clark () globalstar com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.  If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited.  If you have received this
e-mail in error, please contact postmaster () globalstar com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards