Peter's ruminations

From Status to Validity

In an earlier post, I wrote about some of the material we didn’t include in our book on the basics of PKI. It was not included because the notion of the “Validation Authority” had yet to evolve out of one of the technologies we did discuss: OCSP. As conceived by VeriSign and Microsoft initially, OCSP was involved with the revocation of certificates and otherwise delivering “status” information.  The key word here was “status”. It can mean almost anything and can specifically mean "validity' – a subjective evaluation at best. And it is in validity that we find a story to tell; one far more interesting than the issues of revocation and compromise of certified public keys! Validity lies at the heart of a mindshare war going on between the Shibboleth and OpenID communities - 2 approaches addressing single signon.

I doubt that book talked much about it (tho I cannot really remember which control topics I wrote about, any more), Validation Authorities aimed to authorize a farm of servers listening on anycast addresses across the internet to make "status" statements on behalf of a leaf CA. The signatures could be across simple small messages (IETF), or Merkle hash trees (patented). Whereas a Validation Authority validation network might use IETF's signed OCSP messages to dynamically issue (a) signed statement(s) about a static cert to which various attributes about the subject (managed by third parties) may be attached, a SAML IDP issues signed XML "assertions"...to which various attributes about the subject (managed by third parties) may be attached (strangely enough). By fiat, attributes can be entitlements, and attribute contracts would (I grudgingly suppose) implement what a CISSP would probably call a network-/federation- wide non-discretionary security policy by controlling their release (IDP side) and acceptance (SP side).

From what I can tell, the thought-leaders of the SAML world are in a battle to the death with the thought-leaders of the OpenID2 protocol world. Both communities focus on single signon for the web, but their models of administration and management of communities could not be further apart. Grass roots OpenID wants you to be in charge of your own critical infrastructure. The Shibboleth group within the SAML world believe in the Trusted Third Party model, where you are merely a subject about which statements are made by others. You never speak for yourself. What matters is those who will act for you, in your security interests.

The Controlling Nature of Metadata

The issue at stake for the warring parties concerns the role of metadata – and its role in enforcing security policies.

Though SAML2 standards have long had an excellent metadata model to ease the setup of websso links, it is optional. It is poorly supported by commercial vendors, and except in the Shibboleth sub-community it is not viewed as security critical. For Shibboleth folk, metadata is the whole world : the means of orchestrating the security of a web-centric  distributed system, controlling the runtimes of many remote computers acting in loosly or tightly coupled meshes, including those formal high-performance computing clusters known as grids. To use terms from networking, its the "control plane" which manages the "data plane". In the core of the Internet, the Shibboleth conception of metadata is the analog of the routing algorithm that controls the convergence of the routing tables in all the reachable cooperating routers – deciding how and if packets are forwarded in a packet switched network. Just as routing protocols communicate metadata about subnets rather than hosts (normally), Shibboleth metadata describes the trustees of security policy: the IDPs and SPs of the SAML2 world (rather than the subject users).

OpenID2 is heavily invested in metadata. Its mandatory and security critical. Without going into much detail, the authority that will speak for you in any given use of the web is nominated by you, and you maintain one or more metadata files containing your "XRDS" instructions reflecting your choice of alternative providers. By your act of pointing to a particular file stored at a URL (or by using XRI name resolution to generate the "XRDS stream" on the fly), the OpenID protocols wrap themselves around your wishes and the wishes of your communicants to create a semi-secure cryptographic channel over which SSO assertions are exchanged. In a Web2.0 world, this is particularly useful as you wander through yet another enrollment for a service, which demands registration details. As you act to bind your openid to this new service provider, you also get to form fill the usual answers to the usual member registration form. Kept at one of your authorities, these attributes flow over the semi secure channel. Now, being only semi-secure and given the access to metadata is so security critical, OpenID standards recommend the use of https channels – thereby availing OpenId of the assurances that https can bring: its SSL handshake, its reliance on PKI ciphersuites, and the warranties and other financial assurances that the better CA deliver to the parties subscribing to their dispute resolution services. This "built-in" governance model for OpenID2 is delivered via the parties subscription to the relying party services of the medium assurance level,  commercial CAs – TTPs that leverage the trust model known as the “freedom to contract” – a leverage that is expected to serve OpenID as well as it evidently served e-commerce in the 1990s.

What Happens to the Metadata known as PKI?

Now, OpenID is indirectly promoting PKI-based trust networks – as an adjunct to its own metadata -- where the PKI built into https brings assurance and governance by the SSL CAs. And that is a problem for those elements of the SAML community that essentially deny PKI has any role to play in those areas. In fact, that which high-end PKI does in this area of assuring and governing asserters and consumers is that which SAML2 metadata management is viewed as more properly doing. And, there is only room for one sheriff in town.

The Shibboleth communities learn-ed view on “go” (signed) metadata and “down with”  PKI can be read at http://xml.coverpages.org/Cantor-SAML-v20-MetadataInteroperabilityProfile-WD01.pdf. For me, what is interesting is not the attack on PKI (which I find timely), but the rationale concerning why Shibboleth metadata can play PKI’s erstwhile role as a framework for trust networking. And there, finally, we get back to validity.

Assertions vs Certifications vs Validity

Any computer scientist learning formal logic learns to distinguish truthful assertions from questions about the validity of theorems linking several true statements into an argument about topic X. Students learn that two models can both be valid at the same time, given some contextual assumptions. Even in core science, high school students learn that what is true at the macro scale and expressible with Newton’s differential formulas from the 17th century is not true at the micro scale, where an entirely different branch of mathematics not only expresses the peculiar laws concerning the world of micro forces … but proves that Newton’s laws do not hold. The Newtonian calculation, even one formally certified as correct by a national observatory,  simply produces the wrong answer given actual obsevations. That is, the notion of limits in conventional calculus does not necessarily extend from the world of macro forces to the world of micro forces, given actual observations by physicists! Yet, both sets of laws are "valid" – in their respective context.

In the world of SSO, validity is more mundane than in physics – but no less interesting. For the very cryptographic keys that secure and assure the actors doing their SSO thing have a lifecycle. They must be generated (ideally in a secure manner, to create a secure initial condition), they must be used, and given their nature they must be revoked - when no longer bound to some person - or they must be quickly flashed to the world as compromised (because someone published the keying secret, or the consequences of the loss of secrecy goes beyond some tolerance for risk taking). But beyond lifecycle, certified public keys also bear value judgments. In particular, the critical element of any PKI – the signed public key – bears the judgment of its issuer, but contemplates that others will also pass meta-judgment during an act of “reliance” on the issuer. That meta-judgment is nothing more that a use of validity, acting as a metric for the user's acceptance of the issuer's original judgment.

When I wrote my PhD dissertation on validation, I tried to argue that third parties should exist to support relying parties accepting certificates issued by CAs. Known as Validation Authorities, they would apply some or other validation model to a certificate, and let the relying party know their opinion. For example, I the Validation Authority consider a public key certificate within 6 months of its expiry date as too risky for your use. I hereby give it a status of “invalid” and recommend you treat it as unreliable (for your purposes). Oh, and Ill use the IETF-standardized OCSP response data structure to communicate this status value to you, signing it even – to express my ”authority”. Since OCSP also involves you sending a request message, I'll even let you specify which validity model you want applied: mine, yours, or that community of interest over there! The more validity models the merrier!

Now, Validity as Control

The problem with the validity thesis concerns its applicability to the control sphere. Once the relying party is applying a validity model other than that of the issuer, the issuer “loses control” -- particularly if another third party is advising the end user. And, that means loss of economic value of the management service being provided by the issuer - to that other third party closer to the user. One quickly arrives at the ludicrous American situation that one can be authoritatively certified as married… but the certificate may be designated invalid depending on who applies which model of validity. You can be both married and not married, at the same time. In one state you need to rent two hotels rooms; in another, only one.

In the Shibboleth community leadership's proposal, there is a triple denial ongoing – which is radical. Not only is the certificate issuer's validity model to be ignored, not only is the third party's validity model to be ignored even if delivered by OCSP and CRLs/CKLs (or ARLs/AKLs), even the relying party's own validity model MUST be ignored. The only model that matters is that of the maintainer of the Shib metadata, as expressed in signed XML. (Note: A private memo I received states that the control characterization of the Shibboleth leadership's proposal - the final MUST clause, in particular - is far too strong.)

From Full Control to Full Distribution

The nice thing for the OpenID world is that this control paradigm is not a threat to its model of metadata, if one thinks liberally. Its an endorsement of OpenID, in fact. Nothing stops anyone assuming the role of being a "maintainer" of SAML2 (signed) metadata - which contrasts with a worldview in which only “the” maintainer (whoever that one entity may be) gets to speak authoritatively on questions of validity. In fact, that is really only what OpenID already does, in allowing me and you to publish any one of n metadata files about ourselves, and direct the SSO protocol to use a particular one.

We can now conclude. OpenID relies on metadata, and Shibboileth leadership folk are proposing the SAML world moves metadata into the same seat of power. The Shibboleth notion of shifting responsibility for expressing the validity model into a metadata "maintainer" is identical with the older Validation Authority model. My own thesis in my abortive PhD dissertation (which I did actually get formally examined by UK academics ...whereupon it recveived a "total utter fail" grade, note very well) recommended that a properly conceived infrastructure for validation would operate at the level of the individual - which aligns nicely with what the OpenID movement finds itself doing in practice and what the Shibboleth team's technical proposal can actually support. Finally, the Shibboleth leadership team's proposal recognizes that the distribution of signed metadata itself depends ultimately on PKI to verify metadata own signature, - which must be then validated using PKI-centric validity constructs. Considering earlier efforts in the same topic area, just as the IETF specified that a CA might sign a cert "authorizing" a Validation Authority to make validity statements using an OCSP responder, so a CA might issue a certificate that authorizes a Shib-styled metadata maintainer to use its certified signing key to digitally sign “SAML2 metadata”.  

* * * *

Postscript. The nice thing about all this world of validity… is that its carefully and properly patented in embodiment-free language, awaiting the market to develop to the point where it calls for the work that Validation Authorities do! As for my PhD dissertation? Oh well, it got a fail! I’m sure it was a well deserved fail, given academic standards for doctoral degrees. If I consider its thesis though (validity, and who can be an authority performing validation) perhaps I should just publish it myself!

I'm getting now into WG comments, rather than last call issues. So feel free to scorn me.

2.1 makes it clear that metadata SHALL be used to select OP based on their support for the RP's authentication "policies". Given the YADIS model (n different copies of the user's metadata exist as resources located at different URLs, only some of which may be under the formal security policy control of an OP), a user with n metadata files each with 1 authentication policy can be signaling his/her requirements/limits on a given RP.

2.1 implies that an RP may refuse, by local means, to proceed with OpenID Auth if the metadata contains authentication policies that do not intersect with the RP's requirements.

2.5 is not clear whether the process of verifying additional confirmations (to use the precise SAML term, precisely) is an OpenID Auth process (possibly in a per-vendor extension), or a local process.

2.1-2.5 imply that an OP may ignore the RP-requested authentication policy.

3. the term policies should be replaced by Authentication Policies, if that is what is intended. This whole section is far too vague, as written. Suddenly a new URI is introduced for use in the XRDS metadata, which may or may not refer to instances under the per-message namespace URI. It seems to tie back to the URI use in the definition of Authentication Policy, however.

The definition of Authentication Policy is vague. I cannot tell if a prior agreement (a) is required between any 1 OP any 1 RP in existence (b) is required between the specific OP and RP engaged in an OpenID Auth run (c) refers to the URI choice or the policy denoted by the URI.

Harking back to 2.5, the final use of policy, omitting the qualifier authentication (and thus not using a defined term) makes me wonder if the control is specifically being scoped to signal the need to address other policy issues. (i.e. how pedantic a reading do I need to make?)

4. the first use of should ought to be may, given the semantics defined earlier concerning the Rp's requested authentication policy signal

5.1 the MUST phrasing makes it sound like the PAPE extension is now mandatory for any use of OpenID Auth. This may not be what is intended.

Concerning openid.pape.max_auth_age, change to "the OP SHOULD actively authenticate the End User for this request." noting insertion of actively. "The OP should realize that not adhering" is not good writing. The definition of SHOULD addresses these issues, without muddying the semantics of SHOULD. In any case, the sudden introduction of the notion of re-authentication (note re) should be avoided. Stick with active authentication throughout, which may or may not imply re-authenticaiton. (does re-authentication mean previousSession... referring to the traditional SAML bugbear).

Concerning openid.pape.preferred_auth_policies, the semantics suddenly change from may to SHOULD (note capitals): as in "Zero or more authentication policy URIs that the OP SHOULD". Earlier text defines a MAY condition ("When multiple policies are listed in the Relying Party's request, it is up to the OpenID Provider to satisfy as many of the policies as it can"). Secondly, formally one cannot conform to a "URI", but to the policy denoted by the URI. But, Im getting picky. Use of the verb conform itself is also not really warranted. Reserve conform/conforming for use in promoting interoperability, testing etc. Don’t overload it when discussing policy enforcement.

Concerning openid.pape.auth_level.ns.<cust>, I recommend adding examples: "The name space for the custom Assurance Level defined by various parties, such as a country, industry specific standards body, vendors or users." This makes it clear that its entirely legitimate for vendors and users to define authentication policy namespaces (and authentication policies). Or remove the examples. Technical standards really ought to stay out of asserting from legitimacy judgments for [authentication] policy authorities.

Concerning openid.pape.auth_level.ns... I now note we are suddenly back to talking about levels, not policies. So, Im confused. Is authentication level a [historical accident] synonym for authentication policy, or something actually different, now? Dont get all academically pedantic on us or get all defensive, here. Clarity is essential.

Concerning openid.pape.preferred_auth_level_types,and noting earlier Concerning openid.pape.preferred_auth_policies, its suddenly very clear that levels and policy are supposed to co-exist,and that a level is a critical control notion. Ive just no idea what is going on. But, then I really am dumb. I thought I knew from the document what were the core semantics and handling requirement concerning Authentication Policy signals. But, at this point I've really no idea about the semantics of authentication levels, and have no context on their handling requirements. I recommend the abstract introduces this distinction, very clearly. The current abstract only discusses authentication policy [claims].

Ok. Given all that , I cannot bring myself to comment in a detailed and careful manner on the rest. It was doing fine in general, until the last issue.

Peter.

-----Original Message-----

From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of Peter Williams

Sent: Thursday, October 09, 2008 2:58 AM

To: david@sixapart.com; Dick Hardt

Cc: OpenID List

Subject: Re: [OpenID] Building on the OpenID PAPE specification

I read it as saying

NIST ns is mandatory for 1.1, optional for 2.0.

There is inconsistency in the use of terms. At some points the text is specifying controls about authentication "policies", authentication "levels" (section 1.2) in others.

Or, it's actually correct. In that case, I don't understand some obviously very, very important subtlety. Given I'm pretty typically very dumb about web2.0 security models (which as a journalist once lectured me is all about "identity" not security) this would not be particularly surprising. Perhaps we are seeing a good example of how specifically identity2.0 semantics are being crafted - in a way that is subtly different to SAML's authnReq equivalents.

-----Original Message-----

From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of David Recordon

Sent: Thursday, October 09, 2008 1:13 AM

To: Dick Hardt

Cc: OpenID List

Subject: Re: [OpenID] Building on the OpenID PAPE specification

Hey Dick,

The current draft of the PAPE spec is at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html

and as you said allows anyone to define policy URLs.

--David

On Oct 8, 2008, at 7:23 PM, Dick Hardt wrote:

> 

> On 8-Oct-08, at 11:12 AM, Brian Kelly wrote:

> 

>> Dick,

>> 

>> I think it would be helpful to define the specific authentication

>> methods used as policies within PAPE. We could reduce the number of

>> authentication details in the current version of PAPE-AM and come up

>> with a list to be included as "authentication method URIs" in PAPE.

>> e.g.

>> 

>> PKI algo: http://schemas.openid.net/pape/pki/rsa/1024

>> Private key storage:

>> http://schemas.openid.net/pape/pki/hardware-key-nonexportable

>> OTP: http://schemas.openid.net/pape/otp/hotp

>> Channel Security: http://schemas.openid.net/pape/channel/ssl_ev

> 

> I have not seen the latest PAPE spec, but my understanding was that

> anyone could create a namespace that defines a policy. Nothing stops

> you from creating a namespace you think is important and promoting

> people to adopt it.

> 

> Ideally PAPE would not define any of the policies, but the reality of

> adoption is you need to stick a stake in the ground to get it started.

> The mechanism allows OPs and RPs to use whatever makes sense.

> 

>> 

>> 

>> To your second point, I would argue that not all OPs are created

>> equal. I see the OpenID landscape evolving into a variety of

>> "security levels" of OPs and RPs. Do I need an OP that requires a

>> hardware key to make a comment on a blog? No. But I do see the value

>> in having a "high security" OP to login to my bank account and

>> transfer money.

> 

> I agree with you here wrt. different RPs will require OPs with

> different "security levels" -- the objective is to standardize those

> levels.

> 

>> 

>> 

>> The need for more-secure OPs is evident by the lack of RP adoption on

>> commerce websites. These websites have more risk when it comes to

>> compromised accounts. RPs have the right to discriminate which OPs

>> they accept. And giving the RPs a framework with which to judge the

>> security of OPs should help _increase_ adoption of OpenID.

> 

> 

> Personally, I think more secure OPs is NOT the major barrier to RP

> adoption on commerce websites. Usability and protocol security are

> more significant in my opinion.

> 

> -- Dick

> 

> _______________________________________________

> general mailing list

> general@openid.net

> http://openid.net/mailman/listinfo/general

_______________________________________________

general mailing list

general@openid.net

http://openid.net/mailman/listinfo/general

_______________________________________________

general mailing list

general@openid.net

http://openid.net/mailman/listinfo/general