Re: ConcatKDF in xmlenc-core1: ambiguous concatenation

James,

The concatenation, as it is currently in the xml encryption spec, 
neither prepends/appends a  length field nor makes it a fixed length.   
Which means that once concatenated, the components cannot be split 
apart, because there is no demarcation between the components. There is 
really no need to split it up once concatenated, because concatenation 
only needs to happen just before key derivation. The XML markup does not 
have them as concatenated.

Also the spec mentions that  "Note  While any bit string can be used 
with ConcatKDF, it is /RECOMMENDED/ to keep byte aligned for greatest 
interoperability."  - All the interop examples are byte aligned.

For example 
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/microsoft/dkey-example-ConcatKDF-crypto.xml 
has
<xenc11:ConcatKDFParams PartyVInfo="00424F424259343536" 
PartyUInfo="00414C494345313233" AlgorithmID="00123456789ABCDEF0">

In this example PartyVInfo, PartyUInfo and AlgorithmID are all byte 
aligned - notice how all of them start with "00".

So we just need to remove the 00 and concatenate these three parts. 
123456789ABCDEF0414C494345313233424F424259343536.

It is also possible for PartUInfo and PartyVInfo to be empty in which 
case they are not included in the concatenation at all.



You are right about the padding issue.  I think the plain text is 
actually 312 bytes, and 8 padding bytes are added to it. Magnus can you 
confirm?

I think for DRV3, the shared secret key is really 272 bytes / 2176 bits, 
but Bruce should be able to confirm this.

Pratik


On 7/5/2013 9:10 AM, Frederick.Hirsch@nokia.com wrote:
> James
>
> Thanks for sharing these concerns on the list ;
>
> re:  ConcatKDF section of spec: 
> http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#sec-ConcatKDF
>
>  I have some comments inline.
>
> re: issues with interop test cases
>
> Pratik, Magnus - do you have any comment on interop questions at the end?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Jun 19, 2013, at 4:03 AM, ext Manger, James H wrote:
>
>> Hello W3 security group,
>> The ConcatKDF key derivation function as specified in XML Encryption 
>> Syntax and Processing Version 1.1 doesn’t look quite right.
>> http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF
>> The derivation involves the hash calculation:
>>   H(counter || secret || AlgorithmID || PartyUInfo || PartyVInfo || 
>> SuppPubInfo || SuppPrivInfo)
>> The problem is that concatenating the last 5 components is ambiguous. 
>> The boundaries between these components are not preserved.
>> Perhaps there is an unstated assumption that (for any given secret) 
>> each component is unambiguous by having a fixed length or starting 
>> with its own internal length field. To be secure, the unstated 
>> requirement is that the recipient confirms the lengths of each 
>> component before performing the key derivation. It seems very 
>> unlikely that implementations will ever be that careful — and 
>> certainly not without a prominent warning to do so.
>
>
> I think the spec is pretty clear that each component has its own 
> length indication:
>
> "In [SP800-56A 
> <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#bib-SP800-56A>], 
> |AlgorithmID|, |PartyUInfo|, |PartyVInfo|, |SuppPubInfo| and 
> |SuppPrivInfo| attributes are all defined as arbitrary-length 
> bitstrings, thus they may need to be padded in order to be encoded 
> into hexBinary for XML Encryption. "
>
> Regarding integrity, a DerivedKey may be conveyed in a variety of 
> ways, each of which could be protected:
>
> "The |DerivedKey| element is used to transport information about a 
> derived key from the originator to recipient(s). It may be used as a 
> stand-alone XML document, be placed within an application document, or 
> appear inside an |EncryptedData| or |Signature| element as a child of 
> a |ds:KeyInfo| element. "
>
> Thus I believe you are suggesting that the specification should have a 
> security consideration that key derivation information may need 
> integrity protection.
>
>> The last 5 components are specified in XML attribute values of type 
>> hexBinary, with a leading byte indicating the number of unused bits 
>> in the last byte (so each component can have an arbitrary bit length).
>> Example 25 includes:
>> <xenc11:ConcatKDFParamsAlgorithmID="0000"PartyUInfo="03D8"PartyVInfo="03D0">
>> So AlgorithmID is 8 bits (00000000), PartyUInfo is 5 bits (11011), 
>> PartyVInfo is 5 bits (11010). Presumably SuppPubInfo and SuppPrivInfo 
>> are empty. Concatenating gives 18 bits: 00000000 11011 11010. You get 
>> the same 18 bits, and hence the same derived key by splitting these 
>> 18 bits differently. Eg 0000000011 0111 1010. In XML this would be:
>> <xenc11:ConcatKDFParamsAlgorithmID="060000"PartyUInfo="0470"PartyVInfo="04A0">
>> Another problem is Example 36 (and Example 34 and Example 42), which 
>> includes:
>> <xenc11:ConcatKDFParams  AlgorithmID="00"  PartyUInfo=""  PartyVInfo="">
>> In this case AlgorithmID is presumably the empty bit string, but 
>> PartyUInfo and PartyVInfo look invalid.
>> On a related note, I think there is a mistake in the interop test 
>> DRV.1 for ConcatKDF 
>> athttp://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/Overview.html. 
>> The plaintext is not padded before it is encrypted (or the plaintext 
>> is 312 bytes, not the stated 320 bytes).
>> 320 bytes of plaintext -> 1 block for IV + 20 blocks of plaintext + 1 
>> block padding -> 352 bytes of ciphertext -> 470 base64 chars
>> However the <xenc:CipherValue> element has only 448 base64 chars.
>> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/microsoft/dkey-example-ConcatKDF-crypto.xml
>> I cannot get the interop test DRV.3 to work either. Is the shared 
>> secret key really supposed to be 2176 bits long?
>> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/ibm/secret.concat.kdf
>
> The interop participants should be able to help with this - Pratik, 
> Magnus, do you have any comment?
>
>
>> --
>> James Manger (Telstra)
>