state of Algorithm Support
31 views
Skip to first unread message
Peter Schober
Apr 19, 2021, 9:18:04 AM4/19/21
to SimpleSAMLphp
Hey,
Has there been any updated wrt suppport for auto-generating Algorithm
agilty metadata?
While there's https://github.com/simplesamlphp/simplesamlphp/issues/536
(where changes may or may not be part of an existing release) that
does not seem to include support for producing EncryptionMethod?
(I don't see where that info could come from in
https://github.com/simplesamlphp/saml2/blob/master/src/SAML2/XML/md/KeyDescriptor.php
but I may very well be missing something.)
Context: Shibboleth 4 defaults to trying (and failing, if unsupported)
AES-GCM now and auto-generated metadata is the best method we (don't,
yet) have to determine what underlying libraries a SAML implementation
has available and therefore, what algos can be supported.
Best,
-peter
Has there been any updated wrt suppport for auto-generating Algorithm
agilty metadata?
While there's https://github.com/simplesamlphp/simplesamlphp/issues/536
(where changes may or may not be part of an existing release) that
does not seem to include support for producing EncryptionMethod?
(I don't see where that info could come from in
https://github.com/simplesamlphp/saml2/blob/master/src/SAML2/XML/md/KeyDescriptor.php
but I may very well be missing something.)
Context: Shibboleth 4 defaults to trying (and failing, if unsupported)
AES-GCM now and auto-generated metadata is the best method we (don't,
yet) have to determine what underlying libraries a SAML implementation
has available and therefore, what algos can be supported.
Best,
-peter
Tim van Dijen
Apr 19, 2021, 9:41:23 AM4/19/21
to SimpleSAMLphp
Hi Peter,
The changes were made to the SAML2-library and are part of every release since v2.3.5
However there still is no way to configure SimpleSAMLphp to insert algorithms to the metadata..
This is probably difficult to auto-configure, because as an IDP/SP we don't necessarily _want_ to support every available algorithm the xmlseclibs-library supports.
Leaves us with the optional configuration in the same way we support mdui/mdrpi, which is fairly simple to add. It would involve something along the lines of;
https://github.com/simplesamlphp/simplesamlphp/blob/simplesamlphp-1.19/lib/SimpleSAML/Metadata/SAMLBuilder.php#L299 AND
https://github.com/simplesamlphp/simplesamlphp/blob/0b861789f6b8e2e5d222a49a5e970cd490f29c7c/lib/SimpleSAML/Metadata/SAMLParser.php#L967However there still is no way to configure SimpleSAMLphp to insert algorithms to the metadata..
This is probably difficult to auto-configure, because as an IDP/SP we don't necessarily _want_ to support every available algorithm the xmlseclibs-library supports.
Leaves us with the optional configuration in the same way we support mdui/mdrpi, which is fairly simple to add. It would involve something along the lines of;
https://github.com/simplesamlphp/simplesamlphp/blob/simplesamlphp-1.19/lib/SimpleSAML/Metadata/SAMLBuilder.php#L299 AND
- Tim
Op maandag 19 april 2021 om 15:18:04 UTC+2 schreef Peter Schober:
Peter Schober
Apr 19, 2021, 12:08:38 PM4/19/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-04-19 15:41]:
where stuff breaks and where we need to move forward) and that only
has two relevant sets of algos atm: AES-CBC (which is insecure and
should be moved away from, for many years now but is mandatory to
support in the original SAML spec) and AES-GCM (which is not known to
be insecure and what we should use whenever there's library/platform
code to support it).
So with this rather specific view I'd disagree: Whenever AES-GCM
support is detected it should be listed and listed first. And AES-CBC
can always be listed (with lower priority) because listing it is the
same as not listing it. (Everyone uses and therefore supports it right
now. And not nearly enough entities support AES-GCM that anyone could
be running with AES-GCM *only* at this time, and -- sadly -- very
likely for the forseable future.)
> Leaves us with the optional configuration in the same way we support
> mdui/mdrpi, which is fairly simple to add. It would involve something along
> the lines of;
> https://github.com/simplesamlphp/simplesamlphp/blob/simplesamlphp-1.19/lib/SimpleSAML/Metadata/SAMLBuilder.php#L299
> AND
> https://github.com/simplesamlphp/simplesamlphp/blob/0b861789f6b8e2e5d222a49a5e970cd490f29c7c/lib/SimpleSAML/Metadata/SAMLParser.php#L967
Sorry, I'm not sure I understand your references. Did you mean to say
that the expectation would be for the admin to (1) sufficiently care
about this to (2) find out what algos are supported by xmlseclibs or
libssl or libnss or whatever deeper layers and enumerate them
manually?
If so then I think that wouldn't help at all as it's simply too
difficult for an entity operator to find out what algos are usable in
a given environment. (At least that's the case for the Shibboleth SP
software, maybe I'm missing an easy way to determine this for SSP
deployments?)
So I think this should be dealt with as much automatism as possible
and (where necessary) blocklisting known insecure algos.
-peter
> This is probably difficult to auto-configure, because as an IDP/SP
> we don't necessarily _want_ to support every available algorithm the
> xmlseclibs-library supports.
Hm. Currently I'm interested mostly in EncryptionMethod (since that's
> we don't necessarily _want_ to support every available algorithm the
> xmlseclibs-library supports.
where stuff breaks and where we need to move forward) and that only
has two relevant sets of algos atm: AES-CBC (which is insecure and
should be moved away from, for many years now but is mandatory to
support in the original SAML spec) and AES-GCM (which is not known to
be insecure and what we should use whenever there's library/platform
code to support it).
So with this rather specific view I'd disagree: Whenever AES-GCM
support is detected it should be listed and listed first. And AES-CBC
can always be listed (with lower priority) because listing it is the
same as not listing it. (Everyone uses and therefore supports it right
now. And not nearly enough entities support AES-GCM that anyone could
be running with AES-GCM *only* at this time, and -- sadly -- very
likely for the forseable future.)
> Leaves us with the optional configuration in the same way we support
> mdui/mdrpi, which is fairly simple to add. It would involve something along
> the lines of;
> https://github.com/simplesamlphp/simplesamlphp/blob/simplesamlphp-1.19/lib/SimpleSAML/Metadata/SAMLBuilder.php#L299
> AND
> https://github.com/simplesamlphp/simplesamlphp/blob/0b861789f6b8e2e5d222a49a5e970cd490f29c7c/lib/SimpleSAML/Metadata/SAMLParser.php#L967
that the expectation would be for the admin to (1) sufficiently care
about this to (2) find out what algos are supported by xmlseclibs or
libssl or libnss or whatever deeper layers and enumerate them
manually?
If so then I think that wouldn't help at all as it's simply too
difficult for an entity operator to find out what algos are usable in
a given environment. (At least that's the case for the Shibboleth SP
software, maybe I'm missing an easy way to determine this for SSP
deployments?)
So I think this should be dealt with as much automatism as possible
and (where necessary) blocklisting known insecure algos.
-peter
Tim van Dijen
Apr 19, 2021, 2:12:11 PM4/19/21
to SimpleSAMLphp
>
So with this rather specific view I'd disagree: Whenever AES-GCM
support is detected it should be listed and listed first
So how do you suggest this 'detection' works? There's no way..> Sorry, I'm not sure I understand your references.
> So I think this should be dealt with as much automatism as possible and (where necessary) blocklisting known insecure algos.
Op maandag 19 april 2021 om 18:08:38 UTC+2 schreef Peter Schober:
Peter Schober
Apr 20, 2021, 6:12:57 AM4/20/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-04-19 20:12]:
What does supporting AES-GCM for de-/encryption depend on? The SSP
version, xmlseclibs version, PHP version, possbily the SSL library
linked into PHP? All of the above? More?
I would have expected it to be possible to come up with some run-time
test that would determine the algos effectively possible on the given
platform / in the current environment.
If by running this code every time the metadata generation endpoint is
accessed (which might be acceptable though possibly expensive; if
prohibitively so then that would also be a security issue, allowing
remote unauthenticated DoS to the metadata generator URL) then at
least when it's accessed by an admin logged into the web UI or from a
allowlisted set of IP addresses or something like that.
Rephrased as a simple support question: Where can I as entity owner
find out whether my own SP deployment of SSP can support GCM for
encryption (short of federating with an external IDP hard-coded to use
AES-GCM for encryption and possibly seeing it fail on my SP)?
-peter
> So how do you suggest this 'detection' works? There's no way..
You could have lead with that. ;)
What does supporting AES-GCM for de-/encryption depend on? The SSP
version, xmlseclibs version, PHP version, possbily the SSL library
linked into PHP? All of the above? More?
I would have expected it to be possible to come up with some run-time
test that would determine the algos effectively possible on the given
platform / in the current environment.
If by running this code every time the metadata generation endpoint is
accessed (which might be acceptable though possibly expensive; if
prohibitively so then that would also be a security issue, allowing
remote unauthenticated DoS to the metadata generator URL) then at
least when it's accessed by an admin logged into the web UI or from a
allowlisted set of IP addresses or something like that.
Rephrased as a simple support question: Where can I as entity owner
find out whether my own SP deployment of SSP can support GCM for
encryption (short of federating with an external IDP hard-coded to use
AES-GCM for encryption and possibly seeing it fail on my SP)?
-peter
Tim van Dijen
Apr 20, 2021, 6:45:41 AM4/20/21
to SimpleSAMLphp
It's supported as of v1.19.0:
- Tim
Op dinsdag 20 april 2021 om 12:12:57 UTC+2 schreef Peter Schober:
Peter Schober
Apr 20, 2021, 8:02:24 AM4/20/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-04-20 12:45]:
"Currently the only algorithm supported is AES128_CBC or RIJNDAEL_128."
but OK.
So any SSP release of 1.19 or higher will support GCM, as long as SSP
itself can be run (supported PHP version) -- thanks.
OK, so we'd have to ask each entity operator for their SSP version to
determine whether they will be able to decrypt AES-GCM-encrypted
assertions, then.
Best regards,
-peter
> It's supported as of v1.19.0:
>
> https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-remote#section_2_1
The second sentence there is
>
> https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-remote#section_2_1
"Currently the only algorithm supported is AES128_CBC or RIJNDAEL_128."
but OK.
So any SSP release of 1.19 or higher will support GCM, as long as SSP
itself can be run (supported PHP version) -- thanks.
OK, so we'd have to ask each entity operator for their SSP version to
determine whether they will be able to decrypt AES-GCM-encrypted
assertions, then.
Best regards,
-peter
Reply all
Reply to author
Forward
0 new messages