Minutes

Attending

Attendees: Keith Wessell, Heather Flanagan, Steven Premeau, Joanne Boomer, Matt Brookover, Matthew Economou, Eric Goodman

With (Also Starring): Nicole Roy, David Walker, David Bantz, Albert Wu

Regrets: Les LaCroix, Mark Rank

Agenda Bash

Initial take at the value proposition that Mark Rank wrote, will look at it in email before it goes any further.

Status Update

No June 16th meeting, next meeting on June 30th

Gentle nudge from Keith! work on workplan items!

Proposal to update entity ID validation rules

Requirements for new participants to register an entity

Meet saml specs
Domain control validation on domain used in entity ID to ensure participant controls domain
Must be URL, SAML spec allows URN, but InCommon will require URL, for new registrations only. SAML spec allows URN, InCommon does not allow URN

Seeing cloud solution providers that issue entity ID, but do not allow customers to modify entity ID. Happens with Azure, Amazon Cognito and Oracle Identity Cloud

Used domain control validation to have conversation with participant, do not know if this will continue to hold up
Rational becomes the focus instead of real stuff
Question: Is domain control validation on domain in entity ID necessary?

Domain validation on scope is a security issue
Is URL format necessary?
If we change this, how do we do it?
Who gets to decide if we move ahead?
Entity ID Uniqueness
On entity ID it is rare?
If we relax this requirement, do we see any harm?
Do not understand - What are the technical implications?

What we’ve been talking about in the Federated Identity Community group, adding another place where another domain is sneaking into it, that could make browsers kind of pissy

Several reasons for domain validation check

Way to check for uniqueness, domain must be unique when it is registered
We do not want a participant to spoof another parties entity ID
Spoofing an entity ID is highly detectable and less dangerous than spoofing a scope. It is very important that we distinguish those two things from a security perspective
Entity ID has very little value, other then it is a convenient unique identifier and it is required
If entity ID is required, participant must control a domain name, there is little risk of another participant using that entity ID
There are other ways to make that uniqueness check happen so that we can potentially relax the uniqueness requirement
If SPs are doing job correctly, they are binding identifiers unique to that unique identifier of the IDP as an issuer
If you don't control the domain that is issuing the identifiers, you have no control over who can issue identifiers - who owns the identifiers
All of the sudden you are trapped on Okta - we do not want people to be trapped on a platform and we’re being paternalistic about this because you do not know what you are getting yourself into, it is not a technical decision, but a policy issue. Who will get shot in the foot? It is the users of the IDP that are stranded in the services that they have accessed through federation if that entity ID changes. It is a tuple identifier, part of it is the entity ID.
If you do not control your domain and the software does not let you set the entity ID then the software will not work in a federated context. There is no way that the vendor is ever going to be able to consume metadata and release attributes to the R&S entity category and verify the signature and metadata or the things that we need that we talked about in the deployment profile context.
The community needs to figure out what it needs here
Scope - maybe we have focused too much on entity ID, should we bind identifiers on scope instead of entity ID? Maybe we have focused on entity ID incorrectly
The reason we say you have to do this is because stuff like office 365, see blog titled “The Road to Hell is Decorated with SAML assertions” - google it. Basically, MS was not binding identifiers to entity IDs and a user could bind as any user and read that user's email.
There are many SPs that do not check the scope and check that the identifiers come from an IDP that is authorized to assert that scope.
Scooped identifiers are only as good as the registration authority that registered them and most of the SPs that primarily prefer bilateral configurations don’t care.
More and more of these recommendations are about InCommon based federation, not about bilateral federation
Try to think of it, the only person that will read SAML2INT is already trying to integrate with multiple education based entity and is probably not MS or Google.
What advice do we give them, the scope is something we can control and make portable in the federation. The scope that we sign off in metadata is something that we have control over
But, we have recommendations about IDP as a service, and in the mix we have Uncon, Cirrus Identity, we have the proxy architectures that make anything behave the way we want and we are talking about enforcing the deployment profile.
The second thing on the agenda is on TLS and encrypted assertions and whether encryptions should be optional, when we relax one thing and make something else stronger. Can the rules about entity ID be relaxed?
Rules about entityID portability not about it needs to be a URL
The rest of the document does lay out a couple of proposals for how we might compensate on how we do domain control validation
If we relax it, assume the following, 1) we do DCV on any entity ID to have a conversation that we know will not work. We also know the domain they will register, windows.net, we can detect and intercept that registration and tell them it is not going to work and here’s why so rather then catching them on not meeting DCV requirements, we can engage on the part of the conversation that is relevant, including portability, if you bind this in, most IDP operators should understand the importance of non-portable immutable persistent identifiers, if you do that for a person then why not for your infrastructure
We hardly ever get to that conversation because people get caught at “I had to do the DCV then eventually give up”
Next compensating measure, if we care about uniqueness we can do a more proactive check when they register, SAML spec is not so clear on the scope of uniqueness, it says within your domain of interaction, does that mean edugain? We can check for uniqueness in edugain metadata. We can check for it in metadata in InCommon
We need to explain to participants why this will not work in azure AD directly. We need to write a clear document that explains the reason azure ad will not work
Amazon Cognito, is an example of an SP doing this. We do not know how many participants will try to register an SP that does this.
If you try to put an Amazon Cognito SP into the metadata, you still need to do a bilateral with the IDP because you can’t send the primary identifier as the nameID
Reason for proposal, we try to stay true to the real reason we require things 1) establish trust 2) ensure smooth integration
If we do not provide value, either let's not do it or do it differently so that we can improve
AWS cognito is an example of a cloud SP that is an entity ID is a URN format followed by customer ID
This proposal will relax the rule but still require a URL format.
The bit here is, do we relax and allow participants to use a URN?
Couple of thoughts

Scope and entity ID, scope is for automated transactions between relying parties and the IDP
On a human level, people are going to look at the entity ID and make assumptions and if they are not also looking at scope that could be an issue
It is critical about not using an entity ID that you do not control and by they time they are registering in InCommon, the decision has been made and the management has already decided to go a particular direction and the person that is interacting with the federation manager has little control to do anything
So true, federation is the last thing people think about when they are buying an IAS solution

There is a proposal for a sanity check and ultimately notify the owner, if let’s say Florida decides to register a domain that belongs to Florida State, we send a site admin of Florida state a notice that someone’s trying to register an entity in your domain and ask, do you concur?
The choice may boil down to keeping them out of InCommon or letting them take the risk of being locked into a vendor.
Think about strategies to migrate an entity ID?
We will get more and more requests for that.
Entity ID is a related and separate problem.
There are the folks that do not have a way to do parallel testing and choose to stand up a new entity.

In house or not, they use a different entity ID because they need to transition parallel operations, which necessarily means they have to register both in Incommon.
This is more of an education thing on the SP side, weather we provide tools to help make that transition, the SP needs to be aware that there is a practical matter of what I call version 3, long term change management issue, we are all at a point where we are transitioning from one IDP to another
Again, there are management issues pushing the change from one vendor to another
There is a document about the importance of a persistent identifier, we can reemphasize explicitly what the impact will be if you change the identifier. We can suggest the strategy for mitigating the impact of changing an identifier
On the SP side, we can stress that entity IDs are going to change.

A lot of what we have put into demonstrating control about scope versus the entity ID. The entity ID is something that the vendors do not care about so we can just control that and have all the domain control validation on the scope and the SPs must deal with it. SPs deal with it, it has us much less reliant on what the vendors do
If you support a scope, on the SP side, by rule, the SP is supposed to check that the metadata matches the scooped identifier.
Perhaps, what they tell the SP that is trying to do the scoping, do not scope it by not putting on the entity ID, but scope it by @InCommon scope. That way they are scoping on something that we control. If someone switches from one IDP to another we can say the same base.

Albert would like to send an email to TAC list asking for a vote with the options:

Do not change policy
Relax the policy,
Relax with compensating controls

Proposal to change message level encryption requirements

InCommon SPs to supply encryption key
Implication is we expect SP to support encrypted assertions
Up until baseline 2, we did not require SPs to encrypt the endpoints at the transport level, so message level encryption was the only thing we had
Now we require all SPs to encrypt endpoints and on top of that, we have encountered situations where the SP, even though they upload the key, they do not properly support encrypted assertions
And those gafs don’t always show immediately because they only appear if the IDP insists on encrypting the assertion
So what happens from time to time is a company would register an SP with encryption keys but not support encrypted assertions and tell the IDP to turn off encryption, the IDP relents and sends unencrypted assertion, problem solved
Once in a blue moon, recently, Cal Poly Pomona specifically raised this complaint because they are insisting on encrypting.

The company in question Qustica would not, Questica has relented, apparently, Cal Poly found the right person in the company.

The question, since we are requiring transport layer encryption, is message level encryption still necessary?
Bit of history, the reason we never required TLS certs was a holdover from the days when TLS certs were super expensive, which is not the case any more.
That enable us to do things like baseline requiring TLS certs but also because in the pre saml 2 days, you would get your assertion from a different backchannel endpoint and shibboleth actually used your signing key to do TLS on back channel on port 8443 which lead to the robot attack. All of that has been backed up, with a combination of baseline expectations and changes in technology. The reason we did this is no longer relevant because everybody has to do TLS. I don’t want to tamper with people's perception of this. I think that we need both things, but now, we are in a position to not need both??
Some are still using signing key on 443
When I encounter a vendor that does not do encryption, we expect the owner of the service to accept the risk. The risk being all the various vulnerabilities that we have encountered over the past several years, heart bleed, if https in compromised then you can access the payload and get access to unencrypted message and then there is the XML vulnerability from a couple of years ago that didn't impact if it was an encrypted assertion, but if it was not encrypted the message could be tampered with and allow the impersonation of another user by putting whatever attributes in there they want.

I don’t know to what degree those are legitimate concerns.
Do others have similar feelings?
Clearly the vendors that are doing this in the metadata are cheating

I agree with everything protecting against those reasons

We run proxies that are registered in InCommon with encrypted certs and the IDPs send us encrypted assertions which we parse, repackage, unencrypt and pass to the vendors that don’t do encryption

Touch on that point first, this is walking a legal contractual obligation tightrope

If I interpret federation stuff strictly, the obligation to encrypt is purely between the two entities. What you do once you receive the data actually falls outside of the requirement. That sounds bad and it is bad, but it is the actual technical requirement that we have in place. Once it arrives on your end, the SP you registered whether it is a proxy or not is the actual entity in the Federation. Once you arrive, what you do behind the SP is within your organization boundaries and no longer on the federation side
This triggers the how do we recognize proxy question/conversation, so I’ll defer to that conversation for this thread, but for this one, we are talking about, end to end from the IDP in the federation to the SP in the federation, is message level encryption sill required if we are already encrypting transport?
Presumably, this is to stop prying eyes in the middle from inspecting the information, only authorized parties can inspect the information.
TLS might be terminated at actual SP, it may be terminated at F5 and information send clear text from the F5 to the SP, this is an organizational decision so if they want to do it
Not quite the same as the SP proxy, but it separates the TLS processing from the SP host. This is one of those things that gets into the nitty gritty security analysis. Who has the decision rights and who gets to decide and move forward with this comes in more prominently here, raising this issue with CTAB
Do we have technical concerns that would cause us to not relax this requirement?
Do we put the Federation and its participants at substantial risk if we relaxed this requirement?
It seems silly as I say these worlds, I know that my organization would be that much more uncomfortable knowing that attributes that we are releasing to a contracted federated provider are available on a users machine, theoretically, it is the users machine and the users information, but, just having that information encrypted in that transit and knowing that the user for better or worse and arguments on both sides can’t see it or modify it. Really doesn't know what is being handed off about them because that’s in the eyes of my university, that's a contract bit of information rather than other information, and so I think it would change the scope of the conversation within my organization specifically if that was not, you know, actively enforced. And again, does that apply to federation? Does it leave room for knowing opt out rather than having folks lie to us? I don’t know.

I mean nothing about this change says that you as an IDP operator can’t continue to enforce this requirement on your own.
But without InCommen’s help, I am at that much more of a disadvantage and truly and ending up doing bilateral relationships rather then federated relationships which puts me at a disadvantage
I would argue because of the level un clarity around this as the current state, InCommon is actively not helping with this right now

Because we are saying that you as an SP must publish an encryption cert in metadata then allow you to not actually use it and to run software in the context of the federation that actively cannot accept encrypted assertions and it is up the IDP operator to say whether they are comfortable or not with that. Basically hardwire their IDP in that one case or 5 cases to ignore the encryption certificate. Definitely not enforced.
Either we stop… The alternative to not require encrypted assertions any more is actually requiring them and clarifying: SP must both publish an encryption cert in metadata and be able to accept encrypted assertions, and if you can’t accept encrypted assertions you can’t be in the metadata.
And that is what the person from Cal State Pomona wants is for InCommon to take a position and say this is not acceptable behavior
We cannot do that right now because there is nothing that says that it’s unacceptable behavior.
This is where this bleeds into the conversation on the saml deployment profile, there is a class where no information is being sent.
So, take a baseline approach and just arbitrarily force every SP to support encryption. Maybe a little harsh, but we might want to say that if you are going to publish an encryption key that you must support it correctly.
How do you execute this?
Even if you make it a requirement that does not keep the user's browser from having the unencrypted assertion when they go to the vendor because that’s literally what our proxy does. If you send an encrypted assertion, it goes through the browser, we decrypt it, then we send the unencrypted assertion back to the user's browser.
If you are making that requirement and you really want it to be useful, I don’t know I feel like it’s a hill that you’re just not going to be able to get to the top of and I don’t know if thats being too defeatist, but it’s going to bring in all the TLS termination questions and whatnot.
What is the reputation impact if we make a statement?
Simply saying we are replacing encryption is going to likely be interpreted by several parties as if we don’t care.
So, if we are doing this, we need to be very careful how we phrase this
Doing a fuller analysis of what is the real practical impact is probably going to be necessary. We can’t just simply say we relax and are done.
The hill part is that there is no amount of discussion that is going to make Cognito start accepting assertions. And that's where we look, even behind their proxies.
I disagree, though, that it can’t be behind the proxy because the proxy is the thing that is federated, not Cognito.
But that is a distinction that is a pedantic argument that can be easily solved by saying that if you put an encryption certificate in your metadata you must accept encrypted assertions.
What we do right now is the wrong mix of issues and it allows the presence of the cert that the cert is being used and that is not always the case, so we need to resolve that.
Right, that’s an interoperability concern, it's not a security concern.
Two issues, 1) if you put a certificate in there, you should probably be using it 2) do you still require everybody to put a certificate in metadata because everybody has to use it?
I think it’s not so much whether the user can see the assertion, but that malware in the browser can see it.
How do we describe this to the community?
Continue this in email or on another call, also, this conversation is going on in CTAB.
This is not cut and dry, but this is a good conversation

Emailed Updates

International Update

From: Heather Flanagan

Date: Wednesday, June 2, 2022

Hello from Chicago!

This is going to be an informational, short update on all the stuff I’ve got on my list:

REFEDS 44 is in less than two weeks. There is pre-reading. There is support for remote participation.

Identiverse is the week after TNC; while not R&E focused, it is probably the best identity-focused conference in existence at the moment. It is in Denver this year.

Browser discussions continue, with the most recent heated debate being Apple’s very strong pushback on a project coming out of Google called First Party Sets. The reason we care about that is because the Federated Credential Management API (FedCM) has an underlying assumption that FPS will be used to cut down on the number of prompts fed to the user during a federated authentication workflow. The Federated Identity Community Group is going to be chewing on this for a few weeks.

And related to Browser Work, I’ll be giving a presentation along with Tim Lloyd (LibLynx) and Todd Carpenter (NISO) tomorrow at the Society for Scholarly Publishing’s annual conference. Hopefully we will see more engagement from publishers and librarians in the browser discussions as a result.

CACTI Update

From: Steven Premeau

Date: Thursday, June 2, 2022

Usual updates (covered by the other TAC reports)
Welcomed Richard Frovarp to CACTI as the CTAB liaison.
Each participant provided an "elevator speech" for the NREN CEOs on the value of IAM / Federations / collaboration above the "network"

InCommon Ops Update

From: Nicole Roy

Date: Thursday, June 2, 2022

1) We updated the version of the Shibboleth Metadata Aggregator and its configuration in order to allow in some scopes coming from a couple federations (FEIDE and ZAMREN) which were formerly filtered out by rules about public suffixes in scopes, and probably more importantly, we used this opportunity to switch to using the new eduGAIN metadata signing key to verify the signature on eduGAIN metadata before import.

2) We introduced the ability for eduroam admins to add other eduroam admins within the eduroam Federation Manager.

3) We have hired a new Information Security Lead for InCommon/Trust and Identity Services: Andrew Scott. Andrew’s most recent position was as a cybersecurity program manager for the State of Connecticut’s NIST Manufacturing Extension Program. Andrew’s first day was yesterday, May 31st, and he will likely join TAC and CTAB calls in the future. He’ll also be attending BaseCAMP, which is next week.

4) Next week is basecamp - registration is still open, 96 registered so far

CTAB Update

From: Eric Goodman

Date: Thursday, May 1, 2022

Working group updates:

REFEDS MFA working subgroup (mostly about draft edits to MFA profile)
REFEDS Schema Editorial Board (pronouns, SCHAC 1.6.0, and R&S 2 vs. “anonymous, pseudonymous, personalized”
CACTI (will leave to others)
“Not Baseline Expectations 3”

Group is looking at how to facilitate interoperability in federation (without necessarily trying to be prescriptive in the “Baseline Expectations” sense).

BE2 status updates

The orgs that are not meeting baseline in general have not been responding.
InCommon is putting together a formal docket for next steps (e.g., initiating community dispute resolution process for non-responsive orgs)
Additional discussion about how to ensure BE compliance is more an ongoing process (and not just seen as a one time effort)

SP Encryption Keys in Metadata

This is a topic on TAC’s agenda, so will be covered in detail.

See TAC preread: https://docs.google.com/document/d/1QMF8AW9Gkoh3N8Sz2cg_MvUuQoRNNfvKJGZULyXiu7w/

Short version of preread

InCommon FM requires SPs submit an encryption key.
Not all SPs support encrypted assertions/responses.
Some are submitting dummy certs to get registered (but then telling peers to override and not use encryption).
So should encryption support be required of SPs?

Is SP support of encryption an actual InCommon requirement?

SAML2int argues it is.

In support of secure logout as well as mitigation against XML signature bypass attacks.

Many SPs don’t support it.

In a world of proxies, the SP you release assertions to may repackage the assertion to be unencrypted before it’s sent to the final SP.
Some argue that the new requirement for TLS endpoints means the assertions don’t require encryption.

TLS protects against “on the wire” snooping, but “not in the browser” snooping, and doesn’t provide mitigation against the XML signature bypass attacks.

I’m sure we’ll discuss more in TAC.

ECCS (eduGAIN Connectivity Check Service)

Service that attempts to confirm whether a given IdP actually consumes the eduGAIN metadata from its federation.

Page tree

InCommon TAC Meeting 2022-06-02