Considering blacklist of PKCS 1.5 in SP 2.5

[Russell Beall]

My opinion is that this is definitely a good idea.

Is there a configuration element I can add to the blacklist configuration that will allow me to try it out ahead of time and see if there are any impacts to the SPs I currently support?

Thanks,
Russ.

On Jul 27, 2012, at 10:48 AM, Cantor, Scott wrote:

> We've had some discussion of this privately on the committers list, and
> with the consensus leaning towards doing this, I'm bringing the discussion
> to the dev list.
> 
> The normal encryption technique in SAML is that you generate a data
> encryption key to use for a message, and then you encrypt the key with the
> public key of the peer, normally the SP. That step gets done with one of
> two RSA key transport algorithms, PKCS 1.5 or PKCS 2.0 (also called
> RSA-OAEP).
> 
> A couple of years ago, a paper was published demonstrating practical
> attacks on PKCS 1.5 that have some mitigations, which we implemented. Now
> another paper[1] has been published that manages to attack OAEP by using a
> downgrade attack that substitutes PKCS 1.5 in the message.
> 
> The only mitigations to this are things that are going to take a lot of
> time to pull off, either getting every IdP to start signing its Response
> messages *and* every SP to require it, or deploying a new symmetric
> encryption mode that is very rarely supported on most platforms.
> 
> OTOH, turning off PKCS 1.5 can be done very easily using a blacklist, and
> easily undone if its necessary for some site. It should also be relatively
> easy to see in a log file as an error.
> 
> The implications of this for interoperability are impossible to say for
> certain, but we believe that *most* implementations out there use PKCS 1.5
> only when using 3DES keys, which are not a common default. Most AES keys
> are wrapped using the OAEP method. Shibboleth IdPs have never used
> anything but AES and OAEP by default and don't currently even support
> algorithm manipulation using configuration.
> 
> There is one apparent exception: simpleSAML.php uses PKCS 1.5 with AES
> keys. It's apparently a simple change to make it use OAEP, but it's not
> doing that at the moment. Our feeling is that this latest attack
> demonstrates a need for them to make that change, and that we need to do
> the responsible thing and turn this off by default going forward.
> 
> There would be additional communication highlighting this change if we do
> it, obviously.
> 
> -- Scott
> 
> [1] 
> http://www.nds.rub.de/research/publications/breaking-xml-encryption-pkcs15/
> 
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net