<div dir="ltr"><div dir="ltr">Jeremy,<div><div><br></div><div>The sad answer is that the SP can specify which cipher suites are acceptable to it through the use of metadata, but few IdP's actually honor it.  Shibboleth does.</div><div><br></div><div><a href="http://2.4.1.1">2.4.1.1</a>:</div><div><br></div><div><a href="https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf</a><br></div><div><br></div><div>e.g.</div><div><br></div><div><div><a href="https://samltest.id/saml/sp">https://samltest.id/saml/sp</a></div><div><br></div><div>      <md:EncryptionMethod Algorithm="<a href="http://www.w3.org/2009/xmlenc11#aes256-gcm">http://www.w3.org/2009/xmlenc11#aes256-gcm</a>"/><br></div><div><br></div></div><div>but as one example:</div><div><br></div><div><a href="https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/active-directory/manage-apps/howto-saml-token-encryption.md">azure-docs/howto-saml-token-encryption.md at main · MicrosoftDocs/azure-docs (github.com)</a><br></div><div><br></div><div><span style="color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:16px">Azure AD uses AES-256 to encrypt the SAML assertion data.</span><br></div><div><br></div><div>Take care,</div><div>Nate</div></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 22, 2022 at 11:05 PM Jeremy Karlson via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Bummer.  If the report can't provide more detail, then the only other thing I can think of is: Is there somewhere a list of the crypto algorithms that Veracode considers weak and that would trigger the CWE ID 327?  If so, then we could probably cross-reference to the list of EC named curves we support by default and see if there is an intersection.<br>
> <br>
Sorry for the delay in responding. I’ve spent the last couple of days doing other things, as well as thinking about this. There is no list of algorithms that Veracode considers weak that I know of; they seem to rely heavily on OWASP, and OWASP says:<br>
<br>
> <a href="https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html" rel="noreferrer" target="_blank">https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html</a>:<br>
> "For asymmetric encryption, use elliptical curve cryptography (ECC) with a secure curve such as Curve25519 as a preferred algorithm. If ECC is not available and RSA must be used, then ensure that the key is at least 2048 bits."<br>
<br>
Since the file it refers to is very specifically an ECC file, and it doesn’t specify exactly which curve it has complaints about, I don’t see any way to know. I assume that some curves are better than others, but it doesn’t list any specifically as “don’t do this.”<br>
<br>
> Beyond that, EC keys are then used with the fundamental crypto operations of signing (ECDSA) and encryption (ECDH) over SAML protocol messages and/or data within them.  I wouldn't characterize those as "negotiation" between systems, because there isn't a back-and-forth kind of exchange, it's one-sided really (unlike say TLS).  But these fundamental crypto ops are used to secure the messages and data exchanged between SAML entities, which for standard Web SSO use cases is primarily Identity Providers and Service Providers.<br>
<br>
For my own education… If it’s one-sided, in this exchange, who is the specifier of which encryption mechanisms are used? In my case, my employer is the Service Provider, and we are not an Identity Provider. If it’s the Service Provider, then maybe I have a hope of disabling the offending curve (if I ever find it). If it’s the Identity Provider, then I think I’d have fewer options because we are limited by what all of the IdPs would be willing / able to do.<br>
<br>
— Jeremy<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>