A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
<Nicolas.Williams at oracle.com> wrote:
> OCSP Responses are much like a PKI equivalent of Kerberos tickets.
> All you need to do to revoke a principal with OCSP is to remove it
> from the Responder's database or mark it revoked.

Actually, that's untrue in one very important respect.

In a Kerberos style system, you actively ask for credentials to do
things at frequent intervals, and if the KDCs refuse to talk to you,
you get no credentials.

In OCSP, we've inverted that. You have the credentials, for years in
most cases, and someone else has to actively check that they're okay
-- and in most instances, if they fail to get through to an OCSP
server, they will simply accept the credentials.

OCSP is hung on to the side of X.509 as an afterthought, so it cannot
be enforced as part of the system. In Kerberos, the online aspect is
burned into the protocol and cannot be avoided. There is no such thing
as a Kerberos installation that chooses not to use KDCs.

> > SSH does appear to have got away without revocation, though the
> > nature of the system is s.t. if I really wanted to revoke I could
> > almost always contact the users and tell them in person. This
> > doesn't scale very well to SSL-style systems.
> 
> The SSH ad-hoc pubkey model is a public key pre-sharing (for user
> keys) and pre-sharing and/or leap-of-faith (for host keys) model.
> It doesn't scale without infrastructure.  Add infrastructure and
> you're back to a PKI-like model (maybe with no hierarchy, but
> still).

There are two parts to the SSH model that should be segregated in
discussions.

One part is the "I've seen this one before" key validation model. I
think there is merit in parts of that for many sorts of systems (say,
secure email), and it is also worth discussing, but there is a second
thing here which is usually ignored that I would prefer to concentrate
on for now.

The other part, which is very important, is the "we authorize keys by
storing them in a database, we de-authorize them by removing them"
model. This is typically used by Kerberized apps as well, though
Kerberos doesn't generally impose a particular authorization model.

Now, to some people, the "the key is in the database" model might seem
trivial, or obvious, or otherwise insignificant. I think that's a
mistake -- it is a critical part of what makes SSH work so well.

The system is not relying on an old signature on a data structure
around the key to say that the key is authorized. The system relies on
something much simpler: keeping an up to date database of what keys
are allowed. We can change that database at will, in real time.

In this model, some external protocol might or might not be available
to automate maintenance of that database, and the database might or
might not be local to the host, but that part is conceptually entirely
separate.

The important part is that we are not relying on cryptography to
handle the authorization -- we are not going to let someone in because
a third party signed something last year. Cryptography handles only
proving that someone holds a particular private key -- it isn't even
handling authentication of a party per se. We decide to give
privileges to the holder of that private key because a database check
performed right now showed the particular key was in the database as
authorized.

I believe this way of doing things deserves much closer scrutiny. It
is far simpler. It is far easier to understand the security properties
of such a system. There are far fewer systems whose compromise will
compromise the authorization decision. These are under-appreciated
features.


Perry
-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com