Vulnerability fixes

[Cantor, Scott]

On 12/23/14, 8:58 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 12/23/14, 8:52 PM, "Sathish Anickode" 
><SAnickode at skytouchtechnology.com> wrote:
>
>>One of the alternate W3C recommendation is to include a HMAC of the 
>>encrypted message if AES-GCM is not available. I am not sure if SP will 
>>be able to handle such modifications.  Does Shibboleth support this 
>>mechanism?
>
>No, because XML Encryption does not support that. I don't know what 
>recommendation you're looking at, but it didn't come from the W3C working 
>group I was in (or if it did, please point it out, so I can go complain 
>to 
>somebody).

Here's the relevant text from XML Encryption 1.1, 6.1.1:

"It would seem that these attacks can be countered by by disrupting any of 
the conditions, however in practice only preventing condition 3 (sending 
arbitrary ciphertext) is fully effective. To counter condition 3, it is 
necessary for the decrypting system to require authenticated integrity 
protection over the ciphertext. However, unless the mechanism used is 
bound to the encryption key, there will no way to be sure that the signer 
is not attempting to recover the plaintext. The simplest and most 
efficient way to do this is to use an authenticating block mode, such as 
GCM. An alternative would be an HMAC based on the encryption key over the 
ciphertext, but it is less efficient and provides no advantages."

That last sentence is the kicker: it's patently false. It is less 
efficient, but it has one tiny advantage over GCM: it had a prayer of 
being usable on more than a tiny percentage of systems at the time. 
Deployability kind of matters.

If you want safe encryption, you'll have to use IdP 3.0, Java 8, and 
you'll have to use AES-GCM. I'd be fascinated to see what kind of results 
you get. It should work with Shibboleth SPs on a subset of platforms, but 
we have done no interop testing with it. I would be shocked if you get any 
non-Shibboleth SP to accept it.

-- Scott