[mdx] Joe on 3.1.1

[Ian Young]

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

>> 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'll ping him and report back, as I know he is not subscribed here any more.

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

Assuming that MD5 was just thrown in to be there, not because there was a reason, I'd be inclined to suggest that we drop it from the spec as unnecessary for now.  If we come across an actual use case later, we can always put it back in. We may feel the risks of leaving it in for now are low, but if there's no need then I'd rather be safe.

Arguments against?

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

Anyone with a deeper knowledge of OpenID able to contribute?  John Bradley?

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

Yes, and presumably it might reply with an assertion.

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

If the fake IdP resolves the original artifact into an assertion (which is going to be signed by the entity in the metadata the SP has just got) then I was thinking there might be a possible route to an attack based on the contents of that metadata. For example, the SP would believe a Scope element if it appeared there. However, the assumption would be that the rogue entity had its metadata introduced by some registrar somewhere, so that shouldn't be a real problem.

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

Just for interest, was that ever explicitly discussed in the SAML TC when the SAML 2.0 artifact format was invented?

	-- 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/e73a4146/attachment.bin>