[JIRA] (OSJ-355) ConcatKDF parameter requirements too restrictive in ECDH

Mon Jun 27 12:51:42 UTC 2022

Stefan Santesson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=5e1f387fa531f30ca3849078 ) *created* an issue

OpenSAML - Java ( https://shibboleth.atlassian.net/browse/OSJ?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 ) / Bug ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 ) OSJ-355 ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 ) ConcatKDF parameter requirements too restrictive in ECDH ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 )

Issue Type: Bug Affects Versions: 4.1.1 Assignee: Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) Components: Security Created: 27/Jun/22 8:51 AM Priority: Trivial Reporter: Stefan Santesson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=5e1f387fa531f30ca3849078 )

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:DigestMethodAlgorithm="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"* should be a valid input to XML enc.

*Resolution:*

As an immediate fix, we have just made a new release 1.0.8 that sends 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 as long as OpenSAML 4 is restrictive.

We 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.

( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiYjhkNDBhNWM2ZjhlNDUwZTg5ZDdlMjMxMzI1M2UwOGMiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- sha1:10a069b )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220627/38c5c8bf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-b2312d49-8059-47c9-b265-d1e6257741be
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220627/38c5c8bf/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-trivial-1734e3c6-9101-40e3-95e0-cf2ec798cc99
Type: image/png
Size: 563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220627/38c5c8bf/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-49d90fc6-f4fb-4b61-aab8-61e3349ea08c
Type: image/png
Size: 425 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220627/38c5c8bf/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-a4b24e32-d475-4dc2-9973-10b52b55c3f8
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220627/38c5c8bf/attachment-0007.png>