An open discussion list for topics related to the eduGAIN interfederation service.

[Nick Roy <nroy AT internet2.edu>]

Perhaps counterproductively adding to my rant below: ADFS is terrible, but works just well enough to lull people into the belief that it won’t screw everything up, as it invariably does, down the road. I spend at least 80% of my direct-end-user-contact time coaching people with ADFS problems. ADFS should not be used in the context of R&E federations, nor should other similar software. This is a real problem that I don’t know how to address in our context, but the problem is getting worse every day.

Nick

On 19 Nov 2019, at 15:55, Nick Roy wrote:

On 19 Nov 2019, at 8:02, Pål Axelsson wrote:

-----Ursprungligt meddelande-----
Från: edugain-discuss-request AT lists.geant.org <edugain-discuss-
request AT lists.geant.org> För Peter Schober
Skickat: den 19 november 2019 12:18
Till: Zenon Mousmoulas <zmousm AT noc.grnet.gr>
Kopia: Tomasz Wolniewicz <twoln AT umk.pl>; edugain-
discuss AT lists.geant.org
Ämne: Re: [eduGAIN-discuss] reference for expired certificate warning

* Zenon Mousmoulas <zmousm AT noc.grnet.gr> [2019-11-19 11:55]:

I am not suggesting removing the check/warning. I am just trying to
understand where it comes from, so that we can provide an argument to
federation members who are asking why we ask that they update their
expired certificates.

Sorry, I was under the (wrong) impression you were asking about some
eduGAIN component warning about expired *signing* *certificates* from
eduGAIN member federations -- because that's what item 1 on the page you
referenced is about:
https://wiki.geant.org/display/eduGAIN/Best+Current+Practice

So I'll reverse my previous statement (that SAMLMetaIOP does not apply

to

your question) and now state that the /above/ does not apply to your
question, but SAMLMetaIOP fully does.

You're right that expired certificates maybe have been a concern in the

past,

cf. the 6th bullet in section "Metadata" on the page:

https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop#Mic

rosoftInterop-ADFSV2
But that page hasn't been updated for years (and there's also no

supported

Shibboleth software left that would be maintained in the "SHIB2" space

of

that wiki, so it's purely of historical relevance).
Chris P. et al. will know all about the current state of affairs trying

to interop

with MS-ADFS, though.

Hi,

The problem with expired certificates still hits ADFS servers.Microsoft is
using the same TLS library for everything. We had that discussion within
SWAMID a month ago and did a recheck.

The effect is that your users will not be able to login to a service
"protected" with ADFS if your IdP has expired certificates andviceversa.

Pål

It’s not just ADFS that has this problem, numerous other bad SAML implementations also treat certs in metadata as if they were PKIX and incorrectly validate them that way. ADFS is certainly the one we see this with the most often. It’s also doubly (quadruply?) unfortunate when combined with the following facts:

1) ADFS also cannot deal with multiple keys in entity metadata at one time, preventing it from doing graceful key rollover.
2) By default, ADFS generates 2-year self-signed certs for signing and encryption operations.
2) ADFS will "helpfully" automatically roll this cert (not just re-sign the previous cert, but generate an entirely new keypair a few weeks before the old certs expire, without warning.

Nick

Other than that I guess referring to RFC2119 is all one can do if you

wanted

to know just how weak or strong that RECOMMENDATION from
SAMLMetaIOP about unexpired certs is.

I /certainly/ have expired certificates in entities' metadata and as

long as

noone complains about systems unable to interop with those (i.e., unable

to

confirm with SAMLMetaIOP, which actually is a formal requirement from

our

technical profile, but that doesn't help with entities registered in

other

federations, for example) I have no intention of forcing a key rollover.
Incidently none of these we currently publish to eduGAIN, which is why I
haven't spent any time thinking about that.

-peter

Attachment: signature.asc
Description: OpenPGP digital signature