ConcatKDF Bug in OpenSAML 4 implementation of ECDH

[Stefan Santesson]

Hi,

I wave come across an interop problem with OpenSAML 4 implementation of 
ECDH which I believe is a bug in Open SAML 4.


Background:

I was the main developer of the inner logic of Sweden Connect Open SAML 
extension library where we added ECDH support to Open SAML 3.

The repo for this work is here: 
https://github.com/swedenconnect/opensaml-security-ext

We submitted this work to OpenSAML and got a nice response from Scott 
that you would look at this when implementing this in OpenSAML 4, which 
we assume you did.

Since OpenSAML 4 came out, we have removed ECDH from our library. The 
old version (version 1.07) of our lib that includes ECDH is available 
here: 
https://github.com/swedenconnect/opensaml-security-ext/tree/release/1.0.7-release


The issue:

In an interop test last week I discovered that an encrypted assertion 
created by our lib 1.0.7 with OpenSAML 3 could not be decrypted by a 
recipient using Open SAML 4. The recipient application is the EU 
commission CEF implementation of eIDAS nodes version 2.6 
(https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eIDAS-Node+Integration+Package)

The reason for the problem is that we send the following ConcatKDF 
parameters by default:

<xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="00" PartyVInfo="00" 
 ><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" 
/></xenc11:ConcatKDFParams>

This results in an error in OpenSAML 4 that complains that AlgorithmID 
has an illegal value. The problem is claimed to be that the 
ApplicationID parameter has no value.

This is true since the "00" is just a counter of padding bits. The value 
"00" therefore means no value with no padding bits.


We think we understand were this interpretation of the standard comes 
from. XML enc standard on this matter 
(https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF) states: "Their 
presence is optional but AlgorithmID, PartyVInfo and PartyUInfo must be 
present for applications that need to comply with [SP800-56A]".

Note here that SP800-56A defines the inner format of the data that 
follows after the initial padding byte ("00"). The use of the padding 
byte ("00") is simply a convention defined by XML enc. These padding 
bytes are not described in SP800-56A and they are stripped from the 
actual values being concatenated.

The problem here is that SP800-56 requires AlgorithmID, PartyVInfo and 
PartyUInfo values to be non null, but that XML enc overrules that by 
making SP800-56A parameters optional. The exact wording is: "must be 
present for applications that need to comply with [SP800-56A]". This 
means that we don't have to send a value unless our application intends 
to make use of those values in any meaningful way according to 
SP800-56A. And we don't, as we completely discard any content 
communicated here.

At the time we had a quite extensive discussion about this, which if I 
recall this right, involved people at NIST. supporting that 
AlgorithmID="00" PartyUInfo="00" PartyVInfo="00"  would be a valid input 
to XML enc. I even sent some e-mails to W3C at the time.



Resolution:

As an immediate fix, we will make a new release 1.0.8 that will send the 
following ConcatKDF that is accepted by OpenSAML 4: AlgorithmID="0000" 
PartyUInfo="0000" PartyVInfo="0000"

But this will not completely solve the problem as there are some current 
implementations using 1.0.7 that will fail.

We strongly suggest that OpenSAML 4 is fixed to accept also empty values 
AlgorithmID="00" PartyUInfo="00" PartyVInfo="00" for several reasons:

  * These values are not used for anything
  * As they are fixed values, they don't add anything to the security of
    the protocol
  * Making this restriction solves no problem, adds no security, but
    causes interop issues.


Best regards

Stefan Santesson

IDsec solutions










-- 
________________
Stefan Santesson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20220627/81823a73/attachment.htm>