<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>I wave come across an interop problem with OpenSAML 4
implementation of ECDH which I believe is a bug in Open SAML 4.<br>
</p>
<p><br>
</p>
<p>Background:<br>
</p>
<p>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.</p>
<p>The repo for this work is here:
<a class="moz-txt-link-freetext" href="https://github.com/swedenconnect/opensaml-security-ext">https://github.com/swedenconnect/opensaml-security-ext</a></p>
<p>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.</p>
<p>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:
<a class="moz-txt-link-freetext" href="https://github.com/swedenconnect/opensaml-security-ext/tree/release/1.0.7-release">https://github.com/swedenconnect/opensaml-security-ext/tree/release/1.0.7-release</a></p>
<p><br>
</p>
<p>The issue:</p>
<p>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 (<a class="moz-txt-link-freetext" href="https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eIDAS-Node+Integration+Package">https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eIDAS-Node+Integration+Package</a>)<br>
</p>
<p>The reason for the problem is that we send the following
ConcatKDF parameters by default:</p>
<p> <span class="hljs-tag"><<span class="hljs-name">xenc11:ConcatKDFParams</span>
<span class="hljs-attr">AlgorithmID</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyUInfo</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyVInfo</span>=<span
class="hljs-string">"00"</span> ></span><span
class="hljs-tag"><<span class="hljs-name">ds:DigestMethod</span>
<span class="hljs-attr">Algorithm</span>=<span
class="hljs-string"><a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha256">"http://www.w3.org/2001/04/xmlenc#sha256"</a></span>
/></span><span class="hljs-tag"></<span class="hljs-name">xenc11:ConcatKDFParams</span>></span></p>
<p>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.</p>
<p>This is true since the "00" is just a counter of padding bits.
The value "00" therefore means no value with no padding bits. </p>
<p><br>
</p>
<p>We think we understand were this interpretation of the standard
comes from. XML enc standard on this matter
(<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF">https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF</a>) states: "Their
presence is optional but AlgorithmID, PartyVInfo and PartyUInfo
must be present for applications that need to comply with
[SP800-56A]".</p>
<p>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.<br>
</p>
<p>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.</p>
<p>At the time we had a quite extensive discussion about this, which
if I recall this right, involved people at NIST. supporting that <span
class="hljs-tag"> <span class="hljs-attr">AlgorithmID</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyUInfo</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyVInfo</span>=<span
class="hljs-string">"00" would be a valid input to XML enc. I
even sent some e-mails to W3C at the time.</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string"><br>
</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string"><br>
</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string">Resolution:</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string">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: </span></span><span
class="hljs-tag"><span class="hljs-attr">AlgorithmID</span>=<span
class="hljs-string">"0000"</span> <span class="hljs-attr">PartyUInfo</span>=<span
class="hljs-string">"0000"</span> <span class="hljs-attr">PartyVInfo</span>=<span
class="hljs-string">"0000"</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string">But this will
not completely solve the problem as there are some current
implementations using 1.0.7 that will fail.</span></span></p>
<p><span class="hljs-tag"><span class="hljs-string">We strongly
suggest that OpenSAML 4 is fixed to accept also empty values </span></span><span
class="hljs-tag"><span class="hljs-attr">AlgorithmID</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyUInfo</span>=<span
class="hljs-string">"00"</span> <span class="hljs-attr">PartyVInfo</span>=<span
class="hljs-string">"00" for several reasons:</span></span></p>
<ul>
<li><span class="hljs-tag"><span class="hljs-string">These values
are not used for anything</span></span></li>
<li><span class="hljs-tag"><span class="hljs-string">As they are
fixed values, they don't add anything to the security of the
protocol</span></span></li>
<li><span class="hljs-tag"><span class="hljs-string">Making this
restriction solves no problem, adds no security, but causes
interop issues.</span></span></li>
</ul>
<p><br>
</p>
<p>Best regards</p>
<p>Stefan Santesson</p>
<p>IDsec solutions<br>
</p>
<p><span class="hljs-tag"><span class="hljs-string"><br>
</span></span></p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-signature">-- <br>
________________<br>
Stefan Santesson<br>
</div>
</body>
</html>