Subject: Re: [pkix] NSTIC - National Strategy for Trusted Identities inCyberspace

From: [email-masked]
Date: Wed, 8 Sep 2010 16:06:06 -0700 (PST)

On Wed, Sep 1, 2010 at 10:09 AM, Kemp, David P. <[email-masked]> wrote:
> I don't know what you mean by Federation.  To me it means a consortium
> of user domains, each of which provides authentication credentials to
> its users, and each of which agree to accept credentials from other
> domains.  That is what the Certipath bridge is today, that is what a
> dynamically-managed flat list of directly trusted CAs might be, and that
> is what dynamically-issued-per-transaction authentication assertions
> are.
>
> So saying "federation is faster" means nothing to me -- faster than
> what?

Faster than trying to implement the entire RFC 5280/X.509 bridge-CA path-validation algorithm.

I can understand the technical and business reasons for existence of the bridge CA.  It is designed to become a Trent which attests to the adequacy of all CAs that it cross-signs, thus migrating the management of the federation out of all of the individual federation sites and into a manageable chunk, which can specialize in managing the risks involved.  That's what the aeronautical bridge CA is for.

However, it still sucks.  Federating is cheaper, because you don't have to meet bridge CA impositions required for insurance and bonding, such as annual or more-often audits to some arbitrary specification; the liability is between each individual security domain to each other domain that directly trusts it and has cross-certified it.  (I'm having flashbacks to Lotus Domino and its ability to federate and know *exactly* what the certification path, as seen by your individual domain, looks like.)

> I don't agree that a model that requires interaction with an "identity
> provider" for every transaction is the wave of the future - for one
> thing, it would have to be as massively robust as the DNS root servers,
> and for another I might not want my identity provider to know which porn
> sites I'm looking at :-).

I agree with your assessment -- interaction with an identity provider by the RP is an information-leakage vulnerability.

However, I think you're looking at it the wrong way: instead of the RP interacting directly with your IdP, why not have you get fresh OCSP-like responses, and provide them stapled in some manner with your Certificate?  That way, you're the only one who directly interacts with your IdP, but RPs can get the benefit of a response as to how recently the IdP has provided evidence that the key/cert were good.  (TLS's "stapled OCSP" is a good idea, but it's in the wrong working group.)

This is, by the by, one reason why I am *VERY* irritated with the idea of OCSP "good" not verifying that the CA ever even signed the certificate in question.  Stapled OCSP responses are nigh-useless without it.

> We used KDCs to distribute keys for every secure telephone call 25 years
> ago - that model disappeared when we got public key certificates, and
> it's not coming back for applications where the interests of the
> transport providers may differ from those of the communicating parties.

The problem is that the PKI is a very complicated set of cogs, and in the name of "reducing complexity" (where 'complexity' is defined as 'the number of pieces that can be directly compromised by a problem in a particular subsystem') X.509 was made into a monster -- and application programmers, which are stuck implementing it, haven't had any useful means or idea of how to reduce the complexity of the user interface while still providing useful diagnostics.

-Kyle H

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 8 Sep 2010 19:53:32 -0400

Hi Kyle:

> However, it still sucks.  Federating is cheaper, because you don't have to meet bridge CA impositions required for insurance and bonding, such as annual or more-often audits to some arbitrary speci…
I would strongly recommend that you take a look at the requirements laid out by NIST and others before they will accept assertions for anything more trivial than attesting to the fact that you know your grandmother's cookie recipe. The requirements at those levels on the IDP are as tough or tougher than those on a CA infrastructure, and are QUITE tricky to implement. Saying it is "cheaper" is misleading at best.

> The problem is that the PKI is a very complicated set of cogs, and in the name of "reducing complexity" (where 'complexity' is defined as 'the number of pieces that can be directly compromised by a…

If you have taken a look at SAML + WS-*, I don't know how you can say that Federation is "easier".

I&AM is a hard problem at high levels of assurance - regardless of using PKI or Federation, there are just some parts of things that require setting up quite large infrastructures, complex trust relationships, and which require fairly specialize knowledge to get right.

Saying one is easier than the other is like comparing deep sea submarines to spaceships. Both can fail fairly spectacularly, and both are quite hard to get right. They may have similar problems, but fairly divergent solutions.

Have fun.
 
---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559