EncryptionMethod in Metadata

[Ian Young]

On 3 Jul 2013, at 21:34, Eric Goodman <Eric.Goodman at ucop.edu> wrote:

> This is not a Shibboleth question but a more general SAML/metadata one. I’m working with a (non-Shib) IdP integrated with a (non-Shib) SP and was getting errors encrypting assertions.

As Scott mentioned in his reply, I don't think we were aware of other implementations which were making any kind of attempt to use this metadata.  So if you were prepared to let us know which non-Shib IdP and SP you were talking about in each case, that would probably be good information to have for the future.

> In the IdP Metadata (the local metadata read by the IdP), the encryption key section contains:
>  
> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
>                 <xenc:KeySize xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">128</xenc:KeySize>
> </md:EncryptionMethod>
>  
> In the SP-provided metadata (again, also loaded on the IdP side), it contains:
> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
>  
>  
> When trying to send an assertion between these two, I get “Data encryption algorithm and strength mismatch” errors. I was able to fix the error two different ways: (a) adding the 128 KeySize child element to the SP’s EncyptionMethod tag, or (b) removing the EncryptionMethod element altogether. Note that I did not change the SP’s actual configuration in any way, just edited my IdP’s local copy of the SP’s metadata.
>  
> My questions for the collective:
>  
> 1) Is this (declaring the encryption methods to be incompatible) correct or buggy behavior on the part of my IdP? (I can believe either answer)

Notwithstanding Scott's observation that all this is less well defined than one might hope, I'd say this was clearly a bug on the IdP's part.

The SAML metadata spec punts to the XML Encryption spec for this, in which:

http://www.w3.org/TR/xmlenc-core/#sec-EncryptionMethod

"The presence of any child element under EncryptionMethod which is not permitted by the algorithm or the presence of a KeySize child inconsistent with the algorithm MUST be treated as an error. (All algorithm URIs specified in this document imply a key size but this is not true in general. Most popular stream cipher algorithms take variable size keys.)"

Later, it defines the aes128-cbc algorithm ID described above.  The example given omits the KeySize child element.

It seems to me fairly clear from this that the intention of the XML Encryption spec is that for an algorithm whose key size is fixed, such as this one, that an explicit key size  child element MAY appear as long as it has the correct value, but that it is optional and if omitted the key size is to be implied from the algorithm.

In other words, the XML Encryption specification thinks those two algorithm specifiers mean the same thing, and the IdP is incorrect in requiring an explicit KeySize when the algorithm identifier implies a fixed key size.  "Encrypt using 128-bit AES in Cipher Block Chaining mode" implies a 128-bit key.

> 2) Given that I don’t see any entries in the InCommon Metadata that contain an EncryptionMethod element, I’d guess that best practice is to just omit these entries from metadata. Are there any reasons to include this information?

In the long term, we need EncryptionMethod in SP metadata so that IdPs can be more agile in the algorithms they use.  They allow an SP to signal support for encryption methods with more security (Galois/Counter Mode in particular) or explicitly signal *lack* of support for weak methods.

One reason most federations don't publish EncryptionMethod today is that we weren't aware of implementations using it.  Another is that some very old software (which no-one should be running any more) falls over when it's present.  The UK federation, for example, collects this information when it's provided during registrations but at the moment filters it out before publication.

	-- Ian




	-- Ian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130704/0e358c4a/attachment-0001.html