RE: ConcatKDF in xmlenc-core1: ambiguous concatenation

I now notice that http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF has the following sentence:

“Applications MUST also verify that these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800-56.”

To verify an attribute you need to understand the internal structure of the bitstring value it conveys, which includes knowing its expected (fixed) length, or understanding a length encoded within the bitstring. My original email suggested there was an “unstated assumption” that a recipient needs to check the lengths of the attributes. In fact, it is not unstated as it is covered by the spec sentence above.

Hence, theoretically the spec is ok. In practice, this “MUST” will invariably be ignored. Firstly because you can still interop while ignoring the “MUST”: you will not get the security ConcatKDF is supposed to deliver, but you still interoperate (sigh). An XML library can hardly implement “an application-specific way not defined in this document”. There isn’t even a way to identify which “application-specific way” is used. Magnus’s comment (“we could claim … we used an expected fixed-length”) implies Microsoft didn’t implement this “MUST”, which is unsurprising as I doubt any library will.

--
James Manger

From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
Sent: Friday, 12 July 2013 3:12 PM
To: Frederick.Hirsch@nokia.com
Cc: Manger, James H; public-xmlsec@w3.org; Mark.Priestley@vodafone.com
Subject: RE: ConcatKDF in xmlenc-core1: ambiguous concatenation

I agree, that seems like a good clarification to make.
Such a clarification also does not invalidate the interop vectors since we could claim that for the interop, we used an expected fixed-length for the fields that were used and hence did not need the length indicator used in 800-56A.
For example, a note to the interop vectors could be:

Note 1: For the PartyUInfo, PartyVinfo and AlgorithmID components of the ConcatKDF test vectors, the “fixed length bit string” option from 800-56A was used since the length of each respective component was known by the communicating entities.
Note 2: These interop vectors do not use padding for the AES-CBC portion; the focus was on interop for the ConcatKDF construction


From: Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com> [mailto:Frederick.Hirsch@nokia.com]
Sent: Wednesday, July 10, 2013 12:35 PM
To: Magnus Nystrom
Cc: Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>; James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>; public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>; Mark.Priestley@vodafone.com<mailto:Mark.Priestley@vodafone.com>
Subject: Re: ConcatKDF in xmlenc-core1: ambiguous concatenation

Thanks Pratik and Magnus.

comments inline

regards, Party F :)

Frederick Hirsch
Nokia



On Jul 9, 2013, at 9:47 PM, ext Magnus Nystrom wrote:

To answer the questions regarding the test vectors:

a)      Yes, Bruce did use a 272-byte key.
b)      The plaintext was actually 320 bytes, no padding was used (I realize now this is incorrect given the URI used for the encryption algorithm, and we (MSFT) initially had padding but IBM wasn’t using it so we created a new test vector w/o it. Presumably a note should be added in the test vector folder about this. I think you’ll find the same thing in IBM’s test vectors; no use of padding).

As for your other question James (the security concerns around the absence of a delimiter, potentially collapsing what would have been different derived keys onto the same key): I agree that our text preferably would have stated: “The concatenation SHALL be done using the original, unpadded bit string values encoded as specified in [SP800-56A].”

Shall we log this as an erratum - it seems a clarification that could only help interop?


But the current text does not state that. Let’s therefore assume that two communicating implementations, Party U and Party V, follows XML Encryption 1.1 and just concatenates w/o using the SP800-56A encoding (and don’t expect/use fixed-length fields which also is a possibility). Assume Party U only shares a given master key K with Party V. I think this is a reasonable assumption. In this situation, for different AlgorithmID values, different keys will still be derived (assuming Party U and Party V always are represented the same way). However, whenever the concatenated encoding of the SuppPubInfo and SuppPrivInfo equals the concatenated encoding of some other SuppPubInfo and SuppPrivInfo for the same AlgorithmID, Party U and Party V values, the derived key will end up the same (I doubt SuppPrivInfo will ever be sent since it is supposed to be private information, but let’s assume it is). Is this then a security concern? I agree that SP 800-56 A’s encoding does not allow this derived key collapse to occur since in the case of variable-length components, each component would have been preceded by a length indicator in the encoding before the derivation. My (current) inclination would be to say that the security risk is low, since the parties anyway share a secret key. And if Party U shares a key K2 with both Party V and Party W, then clearly (at least in the absence of a not-sent-but-still-shared SuppPrivInfo), Party W will be able to anyway derive any key that is derived between Party U and Party V when K2 is the master just by observing the inputs to the derivation. But perhaps there are also other scenarios with malicious parties?


Very good point, the derived key depends on a master key which should never be shared with more than one counter party; sharing with more than one counter party would be a mistake. Thus the risk overall requires a sensible security practice for the master key...



Best,
Party M

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.

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:ConcatKDFParams AlgorithmID="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:ConcatKDFParams AlgorithmID="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 at http://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