Baseline Expectations Office Hours Call, Tuesday, June 30, 2020
- David Bantz, University of Alaska (chair)
- Mary Catherine Martinez, InnoSoft (vice chair)
- Brett Bieber, University of Nebraska
Tom Barton, University Chicago and Internet2, ex-officio
Ercan Elibol, Florida Polytech Institute
Richard Frovarp, North Dakota State
- Eric Goodman, UCOP - TAC Representative to CTAB
- Chris Hable, University of Michigan
- Robert Zybeck, Portland Community College
- Ann West, Internet2
- Albert Wu, Internet2
- Emily Eisbruch, Internet2
- Andrew Morgan, Oregon State University (guest)
Regrets (CTAB members not attending)
Jule Ziegler, Leibniz Supercomputing Centre
Rachana Ananthakrishnan, Globus, University of Chicago
- Jon Miner, University of Wisc - Madison
- John Pfeifer, University of Maryland
- Pål Axelsson, SUNET
Marc Wallman, North Dakota State University, InCommon Steering Rep, ex-officio
- Chris Whalen, Research Data and Communication Technologies
This office hours call focuses on the proposed Baseline Expectations requirements to encrypt all entity endpoints. See invitation email:
Email from June 24, 2020 to InCommon Participants email list:
Fellow InCommon Participants,
Community Consensus for Baseline Expectations 2 Wiki for reference https://spaces.at.internet2.edu/display/BE/baseline-expectations-2
Proposed Addition to Baseline Expectations 2.0
STATEMENT: All Identity Providers (IdP) and Service Providers (SP) service endpoints must be secured with current and community-trusted transport layer encryption.
Review of SSL Labs Testing Data from March 2020
- CTAB members did review of the data in the spreadsheet "Orgs with endpoints failing BE2 encryption"
- The data was from a March 2020 analysis performed by Shannon Roddy, InCommon Security Lead
- 330 fail (F or T) out of 6000
- Many endpoints that were getting an F grade are now get an A grade
- The proposed requirement to encrypt all entity endpoints may not be as challenging for the community as we thought
- Still there is concern about HE institutions with failing endpoints
What SSL Lab Grade?
- What SSL lab grade would define the baseline expectation?
- Andy supports a Baseline Expectation of A
- Not sure difference between A and A-
- Brett: U of Nebraska has hosted entities inside Amazon that may be problematic; there are issues related to AWS
- IDP susceptible to the robot
- It may be necessary to follow the dispute process when there are issues
- UCOP: Some SPs getting Fs are related to SSL concentrator issues
- Vulnerable to one attack (zombie poodle?)
- Once there was an upgraded of the OS on the device, the grade improved to B or A
- Andy : Familiar with AWS issues, the AWS sites get a B, need to bump to tighter security policy
- Assuming SSL Labs is capping the score at B if an organization is at TLS 1.0/1.1 , would we be unreasonable to require an A?
- Some sites may need to integrate with older browsers, backwards compatibility issues
- Exceptions can go thru dispute resolution if needed.
- Andy: Certificate issue May 30, 2020, altered chain
- Older systems have raw certificate problems
- Scan of all entities in InCommon as of March 2020, CTAB members have reached out to those with multiple fails
- Percentage of those failures is small.
- Many of those with failing grades have caught up between March 2020 and June 2020
- Difference between A and B , didn’t call those out
- Some sites don’t have the right server name in the certificate
- If browser won’t establish trust, it is a fail
- Certificate must be valid
- Host name is connection endpoints
- Some are radically different from entity ID
- Need an internal improvement if we are to run this SLL Labs test regularly
- Correlating is a challenge
- Question: For the testing Shannon Roddy of InCommon did in early 2020, how did we do a test against so many endpoints?
- Answer: Shannon Roddy wrote a script
- Took 1-3 months to do the testing
- Because SSL lab controls / throttles how many tests you can run
- Andy: surprised by the numbers of B versus A
- Maybe baseline should be B
- Maybe B is yellow and A is green
- Room for nuance
- Baseline as B
- And “talk to” the Bs about why they should move to A and the dangers of staying on B
Support Issues for InCommon Staff
- What kind of support issues might InCommon staff face based on the proposed Baseline Requirement around endpoints?
- Clarification doc has statement that Federation operator must scan and notify
- That will be a challenge given the speed of scanning
- Might not be able to do that on a regular basis with any efficiency
- Albert: administering this for the InCommon Federation is resource intensive.
- Not sure InCommon has the necessary bandwidth
- Could produce a report on findings ,
- what do we do if the organizations ignore?
- Do we remove the entity?
- Getting the last 5% into adherence takes a lot of work, as we learned from Baseline Expectations v1
Suggestion for Self Attestation
- Instead of promising that InCommon will do actively scanning , we could ask participants to do self attestation
- This could reduce the dead entities in the metadata
- Andy : have 4 IDP notes, 2 in AWS and 2 on premises
- So some are hidden inside internal DNS
- There are nodes you can’t see that are participants in the federation
- This is a consideration for self certification
- Does SLL Labs offer a paid option to provide non limited scans?
- When SSL labs bumps their requirement, then a large percentage of entities might be out of compliance.
- This is a reason for having self attestation
- And perhaps requiring an annual re attestation
- Makes it easier to enforce
- InCommon can pass info along to rest of InCommon if the grading is changing
Landscape and whether there should be a BE on endpoints
- CTAB should consult with SURFnet and others on they handle these issues
- Brett: our approach may need to reflect things that will always happen
- Grades will change, technology will change
- Forget the BE Requirement around endpoints?
- One approach is that we NOT change baseline expectations for endpoints
- Don’t require an A or a B
- Instead periodic work in the community to push out the Fs we find
- CTAB can just identify the problems and slowly push them out
- In future , browsers may not allow certificate lengths to be valid for over a year
- EricG: this started as a proxy for validating that the server is securely managed in some way?
- Brett: yes and we have in BE, a requirement for generally accepted security standards
- SSL is a standard process that is under the umbrella of generally accepted security
- And we are going to make a point of the SLL, and work through those.
- But don’t modify baseline expectations regarding endpoints
- Regarding issues a user might have at home institution, this is not a federation issue
- User Experience
- We should measure something relevant for the trustworthiness of the federation and perhaps the user experience.
- NOT that we want to police operations in your institution
- Certificate length could become a big user experience issue
- If users have trouble logging into your website, then CTAB does not need to worry about that.
- Maybe Seamless Access https://seamlessaccess.org/ can focus on user interface
- Are we going to require all endpoints to be encrypted in some way?
- Federation operator would need to block endpoints that are not encrypted?
- Instead we can message:
- We strongly recommend you implement these things
- Not doing so can cause problems
- TomB: We need to define what is exceptional if we use the suggested approach of having guidelines but no BE around endpoints
- The list of what is exceptional, and the guidelines, suggested best practice, will be baseline-esque
- Either it's a baseline matter, where the federation operator takes responsibility or it's not
- Which kind of treatment does it deserve?
- TomB thinks endpoint security should be a baseline expectations matter
- Potential relying parties (govt labs) ask about the characteristics of the federation to decide if their govt lab activities can rely on it .
- Eric: as an IDP operator I don’t care about the SPs grade so much
- The users are going to those SPs whether thru my IDP or not
- More concerned about the users when they go to the SP
- Would I refuse to release attributes to an SP because the SP is getting a C grade or because the SP does not run SSL
- In SAML, you are relying on the transport
- If the certificate is weak or absent, then anything sitting on the browser can be seen, data at risk
- Do IDP operators want to restrict access based on this endpoint issue?
- Tom: there are real concerns about value of federation and the infrastructure it makes available
- Brett: we need to operationalize how this works so it does not take as much effort
- Suggestion to have YELP for IDPs and SPs , I like this one, I downvote this one
- Provide more info to end users and operator on how that entity handles its operations
- How do we make it more efficient
- Andy: can there be a nuanced way to do self assertion?
- For example " I am SSL lab score A "
- Then entities can decide on their own if they trust that entity enough
- This would need to be an API you run at runtime
- Could bring up a new set of questions, around the Haves and the Have Nots
- MC noted in the Zoom call chat:
- One the one hand, I like the idea of having that info available, but generally speaking, I can't imagine it would be practical for customers of the software would really be able to take a lot of that into account - if I need X service and it uses my school login, I don't have a choice to say "no, I'd rather use this SP instead of that one"
- Maybe the IDP operators would play a part in the process when acquiring software as a whole, though?
Thanks to everyone who participated.