The SAML AssertionHandle
I was reading some of the SAML specification the other day (yes, I read those) and I found something particularly interesting in the Technical Overview.
In the HTTP message, the artifact carried (either as a query variable or as a control in a POST body). The artifact is a base-64 encoded string. It consists of a unique identity of the Identity Provider and a unique reference to the assertion (called the AssertionHandle). The artifact therefore enables the Service Provider to reference an assertion on the Identity Provider.
I am always the skeptic, especially when it comes to using words like unique. Is there really enough entropy in this AssertionHandle to guarantee its uniqueness? I decided to dig a bit deeper. Oh, just in case you can’t read my mind, this is important because a predictable AssertionHandle allows you impersonate an authenticated user on any system that uses the broken identity provider. Nice, isn’t it?
In section 3.6.4 contains the information I was looking for, I think.
With respect to this binding, an artifact is a short, opaque string. Different types can be defined and used without affecting the binding. The important characteristics are the ability of an artifact receiver to identify the issuer of the artifact, resistance to tampering and forgery, uniqueness, and compactness.
I mentioned AssertionHandle and the above citation uses artifact. An artifact is the collection of three pieces of information [Section 3.6.4.2]: TypeCode (determines the type of artifact), SourceID and MessageHandle. An AssertionHandle is a type of MessageHandle. The generalized requirements are decent, but please tell me there is a bit more direction.
The notation B64(TypeCode EndpointIndex RemainingArtifact) stands for the application of the base64 [RFC2045] transformation to the catenation of the TypeCode, EndpointIndex, and RemainingArtifact.
The following practices are RECOMMENDED for the creation of SAML artifacts:
-
Each issuer is assigned an identifying URI, also known as the issuer’s entity (or provider) ID. See section 8.3.6 of [SAMLCore] for a discussion of this kind of identifier.
-
The issuer constructs the SourceID component of the artifact by taking the SHA-1 hash of the identification URL. The hash value is NOT encoded into hexadecimal.
-
The MessageHandle value is constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of values of at least 16 bytes in size. These values should be padded as needed to a total length of 20 bytes .
The MessageHandle/AssertionHandle is important. The minimum length of this sequence is required to be 16 bytes, which contains roughly 128 bits of entropy. This is similar to the output produced by MD5. The artifact structure requires the MessageHandle to be 20 bytes in length so padding is used if the 16 byte minimum is used. Why the specification does not require 160 bits of entropy (20 bytes) instead is a mystery.
We get the requirement that the MessageHandle needs to be random. We even get the reference to RFC 1750. So far, so good. Then I remember the ‘RECOMMENDED’ at the beginning of the section. RFC 2119 says that when something is a recommendation that it can be ignored. Of course, it says it much nicer and with a few qualifications attached, but it can still be ignored. This, I’m sure, isn’t something to lose too much sleep over.
So, if the developer decides to implement the recommendations, utilize the advice in RFC 1750, uses a reliable PRNG source, reads the Security and Privacy Considerations, uses defensive programming techniques and does not produce any implementation bugs in the code that implements the artifact generation and validation then I think we’re okay.
I don’t mean to sound alarmist, because I’m sure there are some implementations that get it right (intentionally or unintentionally). I’d even say that if one used MD5, in all its broken glory, to generate the requisite random bits that it wouldn’t be the end of the world. This is especially so if artifact timing is used according to the recommendations in the Security and Privacy Considerations. What is worrisome is the distributed nature of SAMLs use. If a collection of systems use a Identity Provider that does not provide a unique MessageHandle then all systems are at risk. The increase of federation and identity services increases the impact of such an event. As a general principle this type of concentration should be given an extra measure of scrutiny. I will be snooping around the various implementations in the coming weeks and will hopefully document my findings.