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,
The InCommon Community Trust and Assurance Board (CTAB) would like to invite
everyone to resume participation in the community consensus process for Baseline Expectations 2 (BE2). 
The BE2 community consensus process runs through August 14, 2020. 
Help us review BE2’s proposed requirements’ contribution to increased assurance and interoperability
within InCommon as well as the impact of implementation within your organization. 
CTAB will be hosting the next BE2 Office Hour on June 30th, 2020 at 10AM PT/1PM ET.
The focus of this Office Hour will be on
the requirements to encrypt all entity endpoints.
Mark the date on your calendar and join us!


Community Consensus for Baseline Expectations 2 Wiki for reference


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


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

  • No labels