Page History

...

1. The FOG survey showed 10 of 13 federations enable TLS on their metadata server.
2. Multiple TAC members agree that enabling TLS on the metadata server will circumvent questions from customers in the future.
3. Multiple TAC members disagree that the absence of TLS on the metadata server will cause deployers to do the Right Thing (in particular, verify the signature on the metadata).
4. Multiple TAC members agree we should clearly document that deployers should do the Right Thing (in particular, verify the signature on the metadata).
5. Make it as easy as possible for deployers to do the Right Thing. For example, provide clear and explicit documentation for configuring metadata refresh in the Shibboleth software.
6. Enabling TLS on the metadata server is a perception issue more than anything else.
7. If we haven’t received any questions about HTTPS yet, why would we start receiving questions now?
8. If we did start receiving questions from deployers, it’s likely those same people won’t understand TLS at all.
9. Wiki MarkupRegardless of what we decide to do with respect to TLS on the metadata server, this should have no effect on a deployer’s decision to migrate to the new server by March 29. \ [NOTE: Actually, it does. If you have an outbound firewall, and we enable TLS on the metadata server, you must migrate or your deployment will break.\]

Ops comments re metadata server:

1. Ops recommends to NOT deploy TLS on md.incommon.org
2. Metadata signed with a secure, offline signing key can not be replaced by HTTPS.
3. Metadata refresh via HTTPS assumes the metadata server is secure. Recall, however, that we run multiple physical servers, only one of which is under our direct control in Ann Arbor.
4. Signed metadata can be served from any server, regardless of whether it is TLS-enabled or not.
5. A TLS-enabled metadata server provides no real value.
6. InCommon has never advertised an HTTPS endpoint for metadata.
7. Wiki MarkupEven though we’ve never advertised an HTTPS endpoint for metadata, 2% of GET requests for metadata are HTTPS requests. \ [NOTE: This was erroneously reported as 20% on the call.\]unmigrated-wiki-markup
8. Is TAC suggesting we publish an HTTPS endpoint for metadata? \ [inctac:that’s not what we heard but we just want to be sure\]
9. We do not want have the HTTP vs HTTPS conversation with deployers. We would rather avoid this conversation altogether.

...

• John reports the work of the MD-Distro WG is complete and thanks the group’s members for their efforts
• The MD-Distro WG has submitted its Phase 2 Recommendations to TAC (see John’s note to the mailing list sent on 2014-01-16)
• For reference, the Phase 2 Recommendations are:
  1. Expand the usage of multiple metadata aggregates
  2. Conduct a pilot study that explores the feasibility and utility of per-entity metadata
  3. Conduct a community-driven review of InCommon key management practices
  4. Conduct a landscape study of the potential needs and uses of hardware security modules
  5. Participate in the samlbits.org project
• Comments, questions, and discussion:
  1. Most of the discussion centered around the proposed pilot study of per-entity metadata.
  2. The goal of the pilot is to bring relevant stakeholders to the table, explore the issues, and identify requirements. In particular, per-entity metadata has poorly understood consequences with respect to IdP discovery
  3. There’s a relationship between per-entity metadata and HSMs that needs to be explored
  4. The per-entity metadata pilot will explore both infrastructure requirements and software requirements
  5. What is the overlap with the samlbits.org project? Well, we might decide to distribute per-entity metadata via the samlbits.org content delivery network as part of the pilot. (As mentioned in the Recommendations, this is a desired outcome, not a requirement.)
  6. Do we have any reason to believe that any software vendor or project (besides Shibboleth) is concerned about per-entity metadata? The answer is most likely no, and so one of the goals of the pilot is to raise awareness of this issue.
  7. We need to make a Call for Participation in the pilot study, and we probably need to do this sooner, rather than later, since potential participants will need to prepare by developing software, deploying infrastructure, or whatever needs to be done in advance to participate in the pilot.
  8. The appropriate scope of the pilot is probably at the level of REFEDS, but the 2014 Work Plan is already determined, so one possible path forward is for InCommon to do an initial pilot in 2014 and then continue the second phase of the pilot in 2015 in conjunction with REFEDS.
  9. In terms of software, we want to include simpleSAMLphp in the pilot, which is why working with REFEDS is important, so that the simpleSAMLphp federations are invited to the table.
  10. As an aside, it’s probably unlikely Microsoft AD FS will ever support such a metadata distribution model.
  11. How does the pilot align with eduGAIN? Probably not at all since eduGAIN metadata is targeted at federations, not end entities.
  12. How do the Recommendations relate to the Priorities document recently submitted to Steering?
• See the full report for more detail
• John asked TAC to accept the Recommendations of the WG, and in the case of the key management recommendation at least, the ball is TAC’s court to take next steps
• AI: John and Steven will review the Phase 2 Recommendations and propose to TAC a list of items that need to be addressed as a result of accepting the Recommendations

...