IdPv3 default config for the SSO profile to sign only the response but not the assertion is in contradiction with SAML2int 0.2.1

[Thomas Lenggenhager]

Thank you Scott for your detailed explanations. That is helpful to know 
how it all happened.

Since eduGAIN in its WebSSO profile [1] requires SAML2int, eduGAIN needs 
to take it up and push for a fix for SAML2int. I will submit that 
request to eduGAIN.

Thomas

[1] 
https://technical.edugain.org/doc/eduGAIN%20SAML%202.0%20WebSSO%20Profile.pdf

On 16.08.16 16:45, Cantor, Scott wrote:
>> The Shibboleth IdPv3 default config for SSO and ECP signs only the
>> response, but not the assertion within the response as documented in [1]
>> in chapter 'System Profile Defaults'.
>
> Yes, that's been best practice for a number of years now to mitigate the XML Encryption oracle attacks on CBC mode. Unfortunately the mitigation only really works if you convince SPs to require it (and why would they, the encryption doesn't matter to them), but that's why the defaults are to do that.
>
>> Unfortunately, the SAML2int web site does not provide any information on
>> why and when this requirement was introduced. It was not in version 0.1.
>> Anyhow, the SAML2int governance is completely unspecified.
>
> Well, the governance is Kantara, which is not a decision I would have made, but it got made, so that's where we are. saml2int badly needs a do-over at this point, and InCommon wants to see that happen, as do I, and it will have to happen there.
>
> The reason for the requirement in there is timing (really bad timing). Originally, BP in SAML was to sign the assertion, to facilitate a magical utopia in which SAML assertions might get used for delegation, so if you're going to sign once, you sign the most useful part.
>
> Shibboleth started by signing the response because that matched SAML 1. We changed in a minor update to sign the assertion instead. Literally a week (I'm not exaggerating, I think it was that soon) later, the attacks became privately known. We were stuck, and we decided not to change the defaults again but to document BP as signing the response.
>
> When we did V3, we decided to go ahead and make the defaults match the original V2 defaults and the current BP and sign the response. saml2int didn't factor into that decision, and if it had, the conclusion would have been that saml2int was out of date on this question.
>
>> Is this a known fact or does it require to adapt the default config in a
>> next release?
>
> saml2int is what will have to be adapted, because it is bad security practice in its current form (but saml2int also didn't value XML Encryption all that much or mandate its use IIRC). There are a lot of things that just haven't been revisited there.
>
>> BTW: The more recent draft spec 'SAML V2.0 Implementation Profile for
>> Federation Interoperability' [3], developed by InCommon and now at
>> Kantara, contains this common requirement for IdPs and SPs, that is
>> compatible with the IdPv3 default config:
>
> It's an implementation profile that is demanding you allow for either or both, to avoid boxing anybody in.
>
> Now that you mention it, I need to double-check that we required SPs support requiring signed responses. I meant to do that, I may have forgotten to.
>
> The Shibboleth SP does, but for legacy reasons I couldn't turn that on.
>
> It's a mess all the way up and down the stack.
>
> -- Scott

-- 
SWITCH
------
Thomas Lenggenhager, Central Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 1505  direct +41 44 268 1541
https://www.switch.ch