Versions Compared

Old Version 1

changes.mady.by.user Emily Eisbruch (internet2.edu)

Saved on

compared with

New Version Current

changes.mady.by.user Emily Eisbruch (internet2.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

CTAB Call Tuesday May 31, 2022

Attending 

  • David Bantz, University of Alaska (chair)  
  • Jon Miner, University of Wisc - Madison (co-chair)  
  • Ercan Elibol, Florida Polytech Institute  
  • Richard Frovarp,  North Dakota State  
  • Eric Goodman, UCOP - InCommon TAC Representative to CTAB  
  • Meshna Koren, Elsevier 
  • Andy Morgan, Oregon State University 
  • Rick Wagner, UCSD  
  • Chris Whalen, Research Data and Communication Technologies  
  • Jule Ziegler,  Leibniz Supercomputing Centre 
  • Tom Barton, Internet2, ex-officio 
  • Johnny Lasker, Internet2 
  • Kevin Morooney, Internet2, 
  • Ann West, Internet2 
  • Albert Wu, Internet2  
  • Emily Eisbruch, Internet2 

 

Regrets

  • Pål Axelsson, SUNET  
  • Sarah Borland, University of Nebraska
  • Dave Robinson, Grinnell College in Iowa, InCommon Steering Rep, ex-officio
  • Robert Zybeck, Portland Community College

 

Action Items from previous CTAB calls

  • David to remind board to approve work plan on wiki (! - one more chance to review)
  • Albert to open work plan access publicly
  • David send note re “!=BE3”  to CTAB 

New Action Item

  • AI: forge a better more informative name than “!=BE3” (Tom, Emily, et al)

Discussion

Working Group updates 

  • SIRTFI Exercise WG (Tom)
    • Did a run through of the tabletop scenario previously developed.
    • Learned much in the process that should make it more likely to be successful when it is done with real participants.

  • REFEDS Assurance Working Group WG 
    • No update, assurance WG call canceled last week

  • REFEDs MFA Working SubGroup (Albert)
    • Edits to proposed draft of updated version of REFEDS MFA Profile. The “draft” adds additional clarifying detail folks widely asked about during the NIH MFA work.
    • Lots of discussion on what can and can’t be required. (E.g., semantics of ForceAuthn, Duo-specific concerns like “remember me”)
    • I (Albert) think we are in the home stretch: editing the message protocol binding sections now -> new to profile: explicit binding specs for SAML and OIDC
    • Hope to not change the meaning of the profile, primarily to add clarity
    • 12 hour window will likely be a topic of discussion


  • REFEDS Schema Editorial Board (entity categories, R&S 2.0, etc) (David)
  • InCommon TAC updates (David)
    • TAC/CACTI working group on SAML Identifier adoption and pairwise ID proposed
    • Extended discussion of next steps for “Federation 2”; REFEDS regarded as vague and/or outside of authority to act; on agenda at the TNC meeting at Trieste
    • Interest in data on interfederation traffic; unclear how to measure
    • Identity “Wallets” discussion in I2  Slack channel #inc-did-wat

  • CACTI updates (Richard F attended last week’s CACTI meeting as the CTAB rep)
    • Hypothetical elevator pitches about the value of federation to NREN CEOs, focus on traffic between federations, one of values of InCommon is multilateral federation.  To help make value case for the InCommon 
    • CACTI is looking for a member to be liaison to  for CTAB


  • !=BE3 (Not Baseline Expectations 3) group updates (David)

    • This group has met twice
    • Broad topic is:  how to increase trust and assurance levels in InCommon
    • Suggestion that it would be useful to have a service catalog, for orgs to know what resources they will have access to if they are a member of InCommon.  Could send note to SPs and ask them to provide some info for such a catalog.
      • It’s hard to develop this and challenging to maintain
      • Might want to check in with REFEDs/ Heather F  to ask about their efforts in this area
    • David will send out poll for another meeting of this group
    • https://docs.google.com/document/d/1aSUYVqVefWBESTrndMiZEyPVl-Zx6Flx/edit 
    •  group would benefit from a clearer name
    • AI: forge a better more informative name than “!=BE3” (Tom, Emily, et al)

BE2 status update and next steps (Albert)

    • 53 orgs not meeting baseline expectations
      • 23 of those are IDPs
      • Some of the 53 orgs are missing contacts
      • Some have not responded to us at all
    • The 53 excludes the TLS expectation, need to be careful in communication
    • Need to communicate that baseline is not a one time box to check
    •  Albert will create a formal docket with actions for InCommon Steering
    • It will be helpful to determine priorities 
    • Trigger the final round of communication
    • We have a larger list of non complying entities than last time (BE1)
    • Staff turnover at IDPs and SPs has been an issue
    • Process  
      • Federation operator (InCommon Operations staff)  issues a list
      • Starting dispute process: Baseline Expectations Community Dispute Resolution Process 
      • InCommon contacts each organization
      • Refer first to CTAB, then to InCommon Steering
      • InCommon Steering might be involved in November or December 

Weird federation entity behaviors:  (Albert, David)

    • SP inability to consume encrypted assertions despite cert public key in metadata (requiring IdP override).
    • Should assertion encryption (still?) be required? (Albert)
    • There is a requirement for transport level encryption. Do we still need message level encryption as a requirement?
    • Should federation operator unilaterally decide and move forward in these cases?
    • What is the preferred change management process?
      • Federation operator decides with advisory committee?
      • Bring this up to InCommon Steering?
      • Have a community consultation?
    • SAML 2 int (https://kantarainitiative.github.io/SAMLprofiles/saml2int.html) requires an SP encryption certificate in SDP-MD08, SDP-SP10, SDP-SP38
      • [SDP-IDP11]
      • In the event the HTTP-POST binding [SAML2Bind] is used, assertions MUST be encrypted and transmitted via a <saml:EncryptedAssertion> element. Information intended for the consumption of the SP MUST NOT be further encrypted via <saml:EncryptedID> or <saml:EncryptedAttribute> constructs.
      • While encryption is viewed in some quarters as onerous or unnecessary, interoperability is enhanced by uniformity. Moreover, a spate of recent vulnerabilities across the industry would have been almost entirely mitigated by its use, demonstrating that it is no longer acceptable to view it as an optional part of front-channel delivery of assertions, if it ever was.
  • Some places require encryption cert, but little detail on what that means to the SP
  • By providing a cert, we expect the SP to support encryption using that cert, but this is not explained
  •  We have many cases of SPs that can’t handle encryption
    • We proxy our SPs, but then re-assert the info in an unencrypted assertion.
    • Arguably this defeats the purpose of requiring encryption (and it’s not something that can be “defended” against within the metadata/federation, since the proxied SP is outside of the federation)
  • It’s easier to make the argument that the IDP must honor encryption if the SP provides a certificate
  • It was noted that  everything with ambiguity does not need  to be resolved with a policy
  • There is an argument that damage has been done. On campus level, there is no clarity, this has created stress for the InCommon member.  InCommon is not supporting this requirement and there is a perceived gap. 
  • question: is message level encryption essential?
  •  Operationally, Fed Manager requires a cert. 
    • Some orgs put in encryption keys to get registered, but can’t handle the encryption. 
    • The operational question for InCommon is: If an SP cannot handle encryption, should the Fed Manager allow them to publish without a cert? 
  • It was noted that encryption is good hygiene.
  • It's the responsibility of all parties to protect that data.  
  • Some engineers are just looking for simplicity. They may not be aware of the risks. 
  • We may want to focus on security risk education.
  • InCommon now requires transport level encryption
  • There is double encryption in some cases
  • If you are already encrypting at the transport level, then the ? can be redundant
  • What is the population that is not supporting encryption? Is it commercial SPs mostly doing bilateral?
    • Answer: hard to tell, we have no way of knowing, we only know if an org escalates their concert to InCommon
  • Assertion level Encryption also provides some protection against XML signature attacks. TLS does not. That was very timely when we were discussing SAML2INT.
  • Message encryption ensures that personal user attributes supplied by the IdP are only available to the intended recipient. That covers much more ground than transport encryption, and it is something that privacy-minded IdPs might want to take advantage of.
  • Can we look at this as a community dispute?
    • Answer: Yes, that was the path, then the organization backed off from the dispute.
  • Albert: It’s not a one time concern
  • We create a space for a bad user integration experience
  • The IDP’s conversations with the Service Provider create a sour feeling
  • This topic is also being discussed at InCommon TAC
  • Not an easy thing to solve, but a timely use case
  • Do we really need an encryption key?
  • If not, let’s clarify that.
  • IdP inability to consume federation SP data (c.f. ECCS) (David)
  • David B showed a GEANT check service edugain connectivity  tool. https://technical.edugain.org/eccs


Next CTAB Call:   Tuesday, June 28, 2022

Tuesday, June 14, 2022 CTAB meeting is cancelled due to TNC