[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft Charter
At 8:10 PM -0700 8/21/07, Frank Siebenlist wrote:
Stephen Kent wrote:
At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote:
In our deployments, we see more and more that PKI is not the primary
authentication mechanism and that online-CAs are used to obtain
pk-credentials, which means that this pki-trust is derived from other
already pre-configured primary authentication mechanisms, like shared
secrets, username/password, kerberos, OTP, etc.
I believe your experience is an accurate characterization for the grid
computing community, but not most other communities who make use of PKI.
Well...I wouldn't dismiss our experience too fast.
The grid community has a lot of experience with the old fashion, heavy
weight PKI infrastructure with "real" CAs issuing long-lived certs to
users - probably more than most other commercial applications as the
last time I checked real PKI never lived up to its promise (who are all
those other communities that you are referring to ?).
The U.S. DoD, in issuing CACs as well as certs for use with software
is an obvious example of a large scale CA issuing long-lived certs. A
number of large enterprises have issued certs to employees. Tens of
millions of smart card users in Europe and Asia are holders of long
lived certs too, although most don't know it.
The reasons why there is a push towards online CAs is because the heavy
administrative burden associated with running a double authN
infrastructure, and because of security concerns.
I'm not sure I know what you mean by "running a double authN
infrastructure." Is this an allusion to folks who run Kerberos or
RADIUS server, and who then decide to add a PKI because these don't
support some apps that make use of PKI?
Our experience is that most organizations already have (at least...) one
identity management systems in place, which is "never" based on PKI and
they will not and cannot abandon that for a PKI.
First, the term "identity management system" is a neologism created
by marketing folks :-). But yes, there is always resistance to
change, and not everyone will benefit enough from a PKI to warrant
the change.
Being able to leverage
an existing identity management system is very compelling.
Leveragng can take the form of using an extant system to issue certs,
and then moving on. But, if "leveraging" means never changing out the
old system, then of course there is a price to pay.
Lastly,
issuing short-lived certs also removes the revocation issues; dealing
with those was never a strong point of PKI (it actually leaves the
revocation issue with the other Id management system).
yes, short-lived certs avoid revocation worries, as well as
precluding use of certs for apps like secure e-mail.
I disagree with your assertion that dealing with revocation is an
inherent weak point of PKI architecture. The CRL model is reasonable
if people think through validity intervals, and if they don't have
sever bandwidth constraints for delivering CRLs. Yes, if one makes
bad choices, then CRLs can grow to be enormous (the CAC is a poster
boy for a bad design in this regard). OCSP is a reasonable
alternative, although too often folks think it provide fresher info,
which is often not the case. In general I believe there has been too
much emphasis on the speed with which revocation data must be made
available to RPs. In reality, revocation is usually a process that
requires human intervention and that will be the gating aspect of the
process.
The security issue with long lived certs has to do with the fact that we
cannot trust the desktops anymore because of all the compromises through
worms, viruses, bots, etc. Storing private keys on desktops protected by
pass-phrases is a loosing proposition and compromised keys are expensive
from a revocation, recovery, and management point of view. So unless you
can rely on smartcards for your private key store and signing, your
deployment is saver and recovery is easier when you rely on
passwords/OTP with onlineCAs+sortlived-certs.
First, if one is serious about user authentication, some form of
hardware assist is needed, period. This could be a TPM, a smart card,
a USB token, or even a SecurID fob. When one constrains the solution
space to make use only of software, then you're already in trouble.
Your argument about the advantages of short-lived certs (and private
keys) vs. long-lived certs has merit, but lacks important details.
For example, if issuance of a short-lived cert relies on purely
password-based authentication, you're still in trouble. if you use an
OTP token, then you are better off because of the use of that
hardware. However, persistent, malicious software will be able to
grab the resulting private key every time it is created, and send it
to a bad guy. Worese yet, if you rely on PRNG software on the
desktop, a smart adversary might replace it with something that makes
it easy to predict the private keys you will generate. So, the bottom
line security differences between long and short-lived certs and keys
is less dramatic than you suggest.
Steve