Baseline Expectations Office Hours Call, Tuesday, June 30, 2020

 Attending

• 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 

Introduction

This office hours call  focuses on the proposed Baseline Expectations requirements to encrypt all entity endpoints. See invitation email:

Discussion

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 .

SP issues

• 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

Operations

• 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.