Re: SecureID vs Certificates

[George Capehart <capegeo () opengroup org>]

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