[mdx] Joe on 3.1.1

[Ian Young]

On 26 Sep 2013, at 15:29, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> I actually had to retract that somewhat. We do have a use case where the
> actual entityID being returned to us is not known ahead of time, but only
> after the query. That's the SAML artifact case.

[…]

> It's actually because SAML artifacts that we need SHA-1. So if we're
> looking for a single one, that would have to be it.
> 
> This not baked into SAML per se, but into the SAML 2.0 artifact format
> everybody uses.

OK, that's something I hadn't considered.  Can I lay out the flow for a sanity check?

Instead of sending an authentication response directly, an IdP can send an artifact representing that response to an SP's AssertionConsumerService with the Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact". The artifact contains the SHA-1 hash of the entityID rather than the entityID itself in order to limit the size of an artifact.

In the normal case, this artifact response will have been the result of an authentication request by the SP (and thus the SP will already have the IdP's metadata, and in principle be aware of the entityID to SHA-1 mapping) but that isn't necessarily the case.  The first the SP might know about it is an unsolicited response from an IdP that is being used in an IdP-first flow, and the SP would have no way in general to get from the SHA-1 hash in the artifact to the corresponding entityID. Without a way to query on the basis of the hashed entityID as an alternative to querying on the basis of the entityID itself, md-query couldn't be used in all circumstances by SAML SPs.

Is that about right?

The current document does mention this in passing in 3.1.1, but doesn't mention SAML by name as being the source of either the general requirement or the specific requirement to support SHA-1.

I think at the very least I'd like to add the following paragraph after the current first paragraph of section 3.1.1:

"In order to support clients which may be in possession only of such a transformed representation of an entity identifier without any way to establish the original entity identifier, the metadata query protocol allows a transformed identifier to be used as a synonym for the original identifier."

Comments?

Do we know of any specific use case for MD5?

Do we know of any specific use case in protocols other than SAML?

I think this is also a part of the spec that could benefit from having an explicit grammar included.

> It's still a stretch to envision an attach on the hash that would result
> in a problem since you'd have to, I guess, have a collision that resulted
> in a different entityID's metadata coming back, but the artifact
> resolution would just fail at that point. I don't know, it seems a
> stretch, but hash analysis is not my area.

Nor mine.  However:

If an attacker can inject entity metadata for arbitrary entity IDs and can also discover an entity ID which hashes to the same value as a legitimate one, it might be possible to trick the responder into returning their metadata instead of the legitimate data. Whether this is possible or not depends on the hash's second pre-image resistance:

http://en.wikipedia.org/wiki/Preimage_attack

Assuming that was possible, the SP would be able to resolve the artifact and get back metadata that corresponded to the wrong entityID.  Obviously that might result in a denial of service, but assuming that an SP applies policy to the entityID returned in the resolved assertion I can't immediately see a route to anything stronger.

If we assume that a responder has all the entity metadata involved available to it (i.e., that there is no server-side referral going on) then one might regard the presence of two distinct entity IDs which hash to the same values as a pretty good signal that such an attack is being mounted, as it's so unlikely to happen by chance. Is this worth mentioning in the security considerations?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20130927/d4d3edf7/attachment.bin>