CWE ID 327: AbstractNamedCurve.java:94

[Nate Klingenstein]

Jeremy,

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.

2.4.1.1:

https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

e.g.

https://samltest.id/saml/sp

      <md:EncryptionMethod Algorithm="
http://www.w3.org/2009/xmlenc11#aes256-gcm"/>

but as one example:

azure-docs/howto-saml-token-encryption.md at main ·
MicrosoftDocs/azure-docs (github.com)
<https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/active-directory/manage-apps/howto-saml-token-encryption.md>

Azure AD uses AES-256 to encrypt the SAML assertion data.

Take care,
Nate


On Thu, Sep 22, 2022 at 11:05 PM Jeremy Karlson via users <
users at shibboleth.net> wrote:

> > 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.
> >
> 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:
>
> >
> https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
> :
> > "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."
>
> 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.”
>
> > 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.
>
> 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.
>
> — Jeremy
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220922/b9a67129/attachment.htm>