Category Archives: Uncategorized

Avoiding XML signature attacks

The other day the security folks over at DUO security posted about a class of bugs in several popular SAML implementations:

This is an excellent piece of work that shows how hard has turned out to be for implementors to do xml digital signature and encryption correctly. Writing security sensitive code is often hard because its not enough to make stuff that “works”, your code has to be “secure” aswell.

A lot of people have asked me and my collegues in the Swedish eIDAS project about how to avoid being affected by this bug and the DUO blogpost clearly sais that the software listed in the post is not the only software affected by this bug – its just the only software the DUO team looked at that was affected by the bug.

The further you get from the R&E federation community (where my $dayjob is), the more common it is to find custom SAML implmementations and there are probably a lot of these implementations that the DUO team never looked at.

I decided to do a writeup of my understanding of how to avoid this and a class of similar bugs that arise from not doing c14n correctly.

For the rest of this post I assume that you have a c14n and xmldsig library that “does the right thing” – the question facing you as a coder is this:

How do I safely apply my libraries to validate an xml signature and do something with the result?

The key to avoiding this sort of bug lies in a proper way to do xml signature validation.

Lets start by showing (pseudocode) how NOT to do it:

    xml = parse(some xml text)
    if (is_valid(xml)) {

This is BAD and dangerous. There have been numerous wrapping attacks published in the last few years – the latest one from DUO is just the last in a long row of similar attacks. The right way to do xml signature processing goes something like this:

    xml = parse(some xml text)
    valid_xml = validate(xml)
    if (valid_xml != NULL) {

The point is that the “validate” function should return the valid references (could be > 1 !) after c14n processing. Specifically the “validate” function should do reference processing, c14n and return the resulting valid XML trees.

This approach protects against a whole class of attacks including this latest one providing c14n is done correctly.

We strongly encourage all implementors to review their code and make sure you follow the above pattern (and avoid the anti-pattern).

This advise applies to more than SAML – anytime you do xml signature validation this is how you should do it. However if you are running SAML specifically then there is an additional measure you can take to avoid several attacks: encryption.

There is currently no known practical attack that can be launched against SAML implementations that use encrypted assertions. Using encrypted assertions therefore provides an extra layer of security against attacks.

Implementers should not rely on encrypted assertions to avoid these problems but should follow the patters described above. But for those who are using 3rd party software that may still be vulnerable, encrypting the assertion (or enforcing encrypted assertions in responses) will at least avoid any currently know attack that would lead to identity spoofing using SAML.

Thx to Stefan Santesson <stefan at>

Comments Off on Avoiding XML signature attacks

Filed under Uncategorized


Next I’ll pick up the shovel and keep digging.

Comments Off on #rlbob

Filed under Identity, Internet, Uncategorized

pyFF – another metadata aggregator

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

Comments Off on pyFF – another metadata aggregator

Filed under Uncategorized

Why it is (sometimes) ok to shoot yourself in the foot

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.


Filed under Uncategorized

Not posting enough

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!

Comments Off on Not posting enough

Filed under Uncategorized

Gaps to Map

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.

Comments Off on Gaps to Map

Filed under Uncategorized

Moving my blog

Since I’ll be changing jobs soon (going to work for NORDUnet and SUNET) I thought it wise to move my blog from where I have been writing sporadically about various aspects of Internet technology. I plan to use this site ( as a place to write about things that aren’t directly related to my activities at NORDUnet.

Comments Off on Moving my blog

Filed under Uncategorized