Leifs BCP

In the world of large scale identity federations the problem-du-jour is how federation operators can connect their federations and share services.

The eduGAIN program led by my good friends Valter Nordh and Brook Schofield, in being a concrete instantiation of interfederation, is starting to reveal operational issues in a number of national R&E federation specifically wrt to how SAML metadata is managed and made available to connected relying parties and identity providers.

A couple of years ago Ian Young wrote a a blog post on an operational model for metadata and Andreas Solberg started work on a basic metadata aggregation profile in part based on those ideas. At the recent tf-emc2 OpenSpace in Zurich Brook ran a session on this topic. These efforts will need to converge in the near future to produce a Standard Model for Interfederation.

In order to support such a model the world needs working code.

Ian and the Shibboleth team has been working on MA1 for a while. I’ve had code in this space too – for instance my saml-md-aggregator.

Recently (last Monday) me and the SWAMID operations team realized we needed to modernize the way we manage and publish our metadata so I took the opportunity to roll up my sleeves and write some code.

The result is pyFF – Federation Feeder.

pyFF is based on a simple execution model – metadata goes in one end and out the other and in between processing happens in a pipeline of basic operations described by a simple DSL (domain specific language) using YAML syntax. Right now the code is in rapid development and I expect it to be in production for SWAMID very soon.

Check it out and send me comments: leifj at sunet.se

I got this link on a list earlier today: Facebook (2 step authentication) fail !

I totally disagree with almost all the assumptions and conclusions of that post. The only bit I can sort-of agree with is that maybe, just maybe it is not a good idea to allow you to opt out of security without proving your identity with a higher level of assurance but I can also totally grok why FB is doing it this way. The reason is spelled “support costs”.

The fundamental mistake of the post is this: The author assumes that strong(er) authentication (eg 2-factor) should be at the discretion of the site owner.

As content owner (my facebook page, my crap) in this case, I carry most of the risk associated with protecting my data. It is therefore totally fine to let me bypass security if I want to – up to a point.

At some point FB assumes some basic level of risk and responsibility which is why they won’t let me create an account without a password.

If this were a bank the border between personal risk and site-owner risk would shift – in part because the law mandates a higher level of responsibility on the part of the bank than in the case of FB.

Higher level-of-assurance/protection is successfully introduced for one of two reasons:

• the user values his/her data (cf blizzard tokens)
• “the man” (eg the government) tells you how it must be

Luckily FB isn’t “the man” – at least not yet – and isn’t in a position to force users into valuing their data above a level that is minimally accepted by most users.

This is the reason strong authentication almost always fails when faced with reality: most of us security nerds don’t share the same gut-reaction with respect to data value than most “normal” users and therefore we are willing to accept a higher degree of hassle when it comes to protecting that data.

This brings me back to the fundamental point: the cost of introducing strong authentication is not in tokens, provisioning or identity proofing. Most of the cost is in support. The simple truth is that most ways we have devised to improve security of the authentication step in any protocol suck from a UI perspective. Fundamentally all such measures (be it SMS codes, OTP tokens or so called “smart” cards) all introduce extra steps in the login process. This means that they are seen by the user as an obstacle that he/she must overcome before they can get at whatever content they were going for.

Incidentally this is related to click-through terms-of-use dialogs but that is another story and another blogpost.

It is worth noting (as I usually try to do when this topic comes up in conversation) that some of the most successful deployments of 2-factor tokens are in the gaming industry and I firmly believe that in these cases the user values their data sufficiently much to accept the additional obstacles imposed by stronger authentication.

I also firmly believe that anyone who can design a truly user-friendly strong authentication mechanism would get rich pretty fast and would do a great service to the Internet.

Clearly the blog has been, if not dead then asleep for quite some time. I have no idea if people are even reading this but I’ll start posting again presently. My lack of updates has not been due to lack of activity!

Right before the IETF in Anaheim I’m off to the ISOC Identity event: Mapping the Gaps in DC. This post is a set of possible discussion points for that event. The event will focus on the gaps between the technological and policy/legal view of the identity metasystem.

Standardized Federation Policy and Practice Statements

Building identity federation involves establishing policy documents and practice statements analogous to the CP and CPS of a PKI. In the world of public key infrastructure there are templates to start from – RFC 3647, ETSI TS 102 042, ANSI X9.79, etc. In the world of federations there is no such help. We need those and we need them to be simpler (if possible) than their PKI cousins.

Simplified/Standardized Federation Contracts

Joining a federation (as an SP or IdP) often involves signing some form of contract. For an SP joining multiple federations the fact that no two contracts look alike soon becomes a problem. There are at least two ways around this:

• Make the contracts easily comparable – i.e standardize!
• Do away with the contracts all together.

In may situations having a contract will probably be inevitable but in certain cases it might be perfectly reasonable not to have a contractual relationship between (say) an SP and a federation. I’ve blogged about this and there has been some work in this area.

Separate technical trust from federation metadata

Technical trust for identity federation is often (at least in many R&E federations) represented as signatures on SAML metadata documents which contain keys for the member entities. This works (often better than using a traditional PKI) but it does tie technical trust management in with a particular identity technology. We need a way to represent technical trust which is easier to setup and maintain than PKI and which can be applied to all identity technologies in use today.