[mdx] Joe on 3.1.1

[Cantor, Scott]

On 9/27/13 7:26 AM, "Ian Young" <ian at iay.org.uk> wrote:
>
>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.

More because it makes the artifact size fixed instead of variable.

>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?

Yeah, in fact I had forgotten that the actual use case is that obscure,
you're right that in most cases you'd have already gotten the metadata and
been able to cache the mapping.

>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.

That case is so obscure, and given the presence of MD5, one might ask Chad
if he only supported this by accident, but my recollection was that was
the reason.

>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?

+1

>Do we know of any specific use case for MD5?

Not me.

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

I know there's some kind of artifact clone in OpenID, but I don't know how
it works. But I wouldn't expect it would have been built to assume such
machinations, no.

>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.

The only threat is that you'd be exposing the artifact to the second IdP.
If the IdP was compromised (which would stand to reason, otherwise why do
it?) then it could either steal the artifact itself (but a good SP would
check replay on that and prevent that) or more likely just issue a
response telling the SP what you want to tell it about the client (who's
presumably the attacker).

It's something like a Kerberos KDC spoofing attack, where the client
collaborates with somebody who's running a fake KDC.

>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?

I think so. Practically speaking, the chances of finding two "real"
entityIDs that collide with a hash function that hasn't completely
collapsed is pretty low.

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