Changing IDP Metadata Cert

[Jason Rotunno]

Thanks, Scott. That's actually helpful. I feel like I have some other
questions/ideas but I can't quite articulate them right now. I'll think
this over and check out the links you provided.

Jason


On Tue, Aug 16, 2022 at 3:08 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> None of this has any sort of simple answer. I've covered the challenges
> and processes involved in key changes on the list pretty often.
>
> But this situation can also be addressed through the thing Shibboleth does
> not have ideal or simple support for, dedicated signing keys for specific
> SPs, because you can't just go changing the cert and count on most
> non-compliant software from breaking. That can effectively be a key change
> for all intents and purposes when it's done globally.
>
> > Instead it has:
>
> Absence of use="signing" or use="encryption" implies both signing and
> encryption, which should not be done with an IdP because of the huge
> challenges and differences in rotating them. Only very old versions
> defaulted to that approach because back then we didn't even support IdP
> decryption so the absence of the attribute was somewhat accidental, and it
> shouldn't be done that way in any "real" metadata as published by
> federations.
>
> >    Apart from that, though, this sounds like what needs to be changed,
> given
>  > the fact that it's in the metadata.
>
> Metadata reflects deployment state, but key changes involve critical and
> ordered steps that separate the content of the metadata from the
> configuration to ensure graceful outcomes. But that applies to full
> rotation, not one-off situations where metadata might not even be involved.
> Only SPs using a tiny handful of implementations support metadata to begin
> with.
>
> > I do see, however, that the end of that page has a 'Metadata Signing Keys
> > and Certificates' section. And while the section title sounds relevant,
> the
> > contents do not.
>
> Metadata signing is about metadata signing, not runtime assertion or
> message signing. Entirely different.
>
> >So my first question is which key/cert needs to be updated, the signing
> > key/cert or the metadata signing/key cert?
>
> The former, except that you don't want to do that unless you're prepared
> to enter a multi-month process or break a lot of systems, or do some work
> up front to determine what the risk really is.
>
> > I'm assuming that when SHA-1 went EOL, everyone had to deal with this.
>
> Many people got ahead of it long before they had sufficient non-Shibboleth
> (i.e. broken) SAML SPs at scale to deal with. So not everyone had to deal
> with the full scope of the problem. Maybe you don't either, it depends on
> the scale of your deployment.
>
> I definitely rolled mine off SHA-1 before the cloud got huge, just a
> matter of luck, but I also subsequently did a full rotation of the key,
> which took, yes, 9 months of calendar time and easily 120 or more hours of
> meticulous work.
>
> As for generating something outside of using OpenSSL, there's
> $ idp/bin/keygen.sh --help
>
> And if you go down the "override key for an SP" route, it's covered in
> https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631697/SecurityConfiguration
>
> Configuration -> Per-Profile Credential
>
> It's ugly, it's not something we really target as a use case and have
> never made it that clean to pull off. But avoiding it by rolling the cert
> outright is a difficult undertaking that just depends on too many local
> factors to map out a plan for.
>
> Among the emails in the archive on this:
>
> https://marc.info/?l=shibboleth-users&m=158086168427222&w=2
> https://marc.info/?l=shibboleth-users&m=161125296125093&w=2
>
> Directly on point:
> https://marc.info/?l=shibboleth-users&m=162507942204859&w=2
>
> Essentially, as I say there, if you do a key rotation by issuing a new
> cert with the same key, you can expect Shibboleth SPs to work (even if they
> never get updated metadata), and you can expect an unknown number of SPs to
> work or not work if they don't get updated metadata or get manually
> updated. It's hard or impossible to predict.
>
> I'm sure you hate this response, but that's all I can do on list. This is
> a deep, deep member support sort of topic that would require much more time
> to do proper justice to.
>
> We need a ton of docs on this topic, most of which have little to do with
> Shibboleth at all, just no time to do it.
>
> -- Scott
>
>
>

-- 

Jason Rotunno
System & Security Administrator
Swarthmore College
500 College Ave
Swarthmore, PA 19081
610.328.8505

*VERIFY before you click!!*
  - Attackers make their emails look like they come from someone they don't.
  - Attackers make links look like they go to websites they don't.
  - Attackers disguise malware as receipts, invoices, faxes, etc.

Forward suspicious emails to phishing at swarthmore.edu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220816/64c5e203/attachment.htm>