AES256-CBC for encryption?
kwessel at illinois.edu
Fri May 10 18:12:20 EDT 2019
Thanks, Scott. That explains why my encrypted assertion is still going as AES128. Yes, we do control the metadata. Is it as simple as just adding this to their metadata?
I don't have to make mention of any signing algorithms or anything else as long as they're good with our defaults, correct?
As for the vendor's name... Yeah. My thoughts exactly.
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, May 10, 2019 5:01 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: AES256-CBC for encryption?
On 5/10/19, 3:22 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> We're federating with a vendor, CrowdStrike Falcon,
> First question: is it a bad idea from a security standpoint to offer this? That is, is it any worse than AES128-CBC?
No, not really.
> Second question: Is it as easy as a new security configuration bean
> that I could associate with their relying party config that looks like this?
Yes, but the problem with the way the security stuff works is that you have to plugin a top level object called a SecurityConfiguration that contains all the signing and encryption settings in one structure. So when you want to change one part, you have to be careful to create the overall object to carry what you want, and the wiring can get sort of ugly with more duplication than would be ideal.
If you control the metadata, you might want to consider using the algorithm extension metadata Shibboleth supports that lets you embed an EncryptionMethod element in the metadata to tell it what algorithm to use. The SP generates metadata with that extension in it, so if you have one handy somewhere you could look at what it generates for a sample.
> Just wanted a sanity check before shooting myself in the foot.
You're not off base at all, it's just sometimes a bit tricky to override only what you want. I suspect we'll end up adding a MetadataFilter to add in those algorithm extension elements because it's a lot simpler to do that than muck with the wiring.
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users