Phase 1 Implementation Plan FAQ

Phase 1 Implementation Plan Frequently Asked Questions

In September 2013, the Metadata Distribution Working Group submitted its Phase 1 Recommendations to the InCommon Technical Advisory Committee. This FAQ anticipates questions and concerns regarding a Phase 1 Implementation Plan that is currently taking shape.

General Questions

Is it really true that the HTTP location of InCommon metadata is changing?

Yes, for the first time since the beginning of the InCommon Federation, the location of InCommon metadata is changing. This is a big deal, we know. If we could avoid it, we would.

InCommon Operations will deploy two new metadata aggregates at the following permanent HTTP locations:

• http://md.incommon.org/InCommon/InCommon-metadata.xml (production)
• http://md.incommon.org/InCommon/InCommon-metadata-fallback.xml (fallback)

Moving forward, all new metadata services will be deployed on vhost md.incommon.org.

Multiple, heterogeneous services currently run on vhost wayf.incommonfederation.org, namely, Metadata Services and the InCommon Discovery Service. To provide better quality of service, these services need to be segregated onto their own vhosts (md.incommon.org and ds.incommon.org, resp.). Note: The InCommon Federated Error Handling Service is already running on ds.incommon.org.

Is the current HTTP location of InCommon metadata going away?

Yes. All metadata services on vhost wayf.incommonfederation.org will be decommissioned on March 29, 2014. At that time, we will install a redirect to the new fallback metadata aggregate.

The InCommon metadata signing certificate expires on May 2, 2014. More importantly, the InCommon metadata signing certificate is signed by a legacy CA whose certificate expires on March 29, 2014. This is why we chose the above migration deadline.

Both metadata aggregates will be signed using a new self-signed signing certificate set to expire on December 18, 2037. We don't intend to resign the metadata signing certificate unless it's absolutely necessary. Note that although the signing certificate is new, the signing key is not.

Why are there TWO new metadata aggregates?

Both metadata aggregates will be signed with the same key but will use different digest algorithms:

• The new production metadata aggregate will be signed using a SHA-2 digest algorithm.
• The new fallback metadata aggregate will be signed using a SHA-1 digest algorithm (which is what we use now).

Currently the XML signature on InCommon metadata uses a deprecated (and soon-to-be disallowed) SHA-1 digest algorithm:

• NIST deprecated the use of SHA-1 in conjunction with digital signatures on January 1, 2011.
• NIST disallows the use of SHA-1 in conjunction with digital signatures after January 1, 2014.
• See: NIST SP 800-57 Part 1, Revision 3 (July 2012), Tables 3 and 4

This is why we're moving to a SHA-2 digest algorithm.

What is a "fallback metadata aggregate?"

The fallback metadata aggregate comes into play when introducing a breaking change into InCommon metadata (such as SHA-2). When a change is made to the production metadata aggregate, and that change breaks a metadata process, the affected deployment can temporarily migrate to the fallback metadata aggregate. This gives the deployment time to adjust to the breaking change.

Questions about SAML Software

How does this implementation plan affect Shibboleth IdP deployments?

Shibboleth IdP deployments in the InCommon Federation are least affected by this implementation plan.

If you are running a supported version of the Shibboleth IdP, your software is compatible with SHA-2 and you can migrate to the new production metadata aggregate at your convenience (but no later than March 29, 2014). There are two modifications you need to make to your IdP’s metadata configuration:

1. The metadataURL XML attribute on the <MetadataProvider> element should point to the HTTP location of the new production metadata aggregate.
2. Securely download and install a copy of the new metadata signing certificate.

The second step above is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.

How does this implementation plan affect Shibboleth SP deployments?

Shibboleth SP version 2.0 (or later) supports SHA-2 but whether or not it can deliver that support depends on the version of OpenSSL installed. Since OpenSSL is bundled with the Shibboleth SP software on the Windows platform, SHA-2 support on Windows is assured.

If you're running the Shibboleth SP software on a non-Windows platform, the software depends on whatever version of OpenSSL is built into the underlying operating system. If Shibboleth is installed on top of an unsupported OS platform, it is likely you are running an old version of OpenSSL that doesn’t support SHA-2. For instance, RHEL 4 was built with OpenSSL version 0.9.7, which is known to be incompatible with SHA-2. In this case, you have no choice but to upgrade to a supported OS platform.

If your Shibboleth SP deployment is installed on a system with OpenSSL version 0.9.8 or later, you should migrate to the new production metadata aggregate; otherwise you should migrate to the new fallback metadata aggregate. In either case, there are two modifications you need to make to your SP’s metadata configuration:

1. The url XML attribute on the <MetadataProvider> element should point to the HTTP location of the new metadata aggregate.
2. Securely download and install a copy of the new metadata signing certificate.

The second step above is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.

How does this implementation plan affect simpleSAMLphp deployments?

The simpleSAMLphp metarefresh module will refresh and verify metadata automatically. Signature verification depends on the fingerprint of the signing certificate, so the fingerprint configured in the metarefresh module must be updated before migrating simpleSAMLphp to the new metadata aggregate.

If you're running simpleSAMLphp 1.11 (or later), your software is compatible with SHA-2 and you should migrate to the new production metadata aggregate; otherwise you should migrate to the new fallback metadata aggregate. In either case, there are two configuration changes you need to make to simpleSAMLphp's metarefresh module:

1. The src array element should point to the HTTP location of the new metadata aggregate.
2. The validateFingerprint array element must reflect the fingerprint of the new signing certificate.

The second step is critical for simpleSAMLphp deployments (despite the fact that the new signing certificate contains the same key as the old signing certificate). See the Metadata Consumption wiki page for instructions how to securely obtain the fingerprint of the new metadata signing certificate.

How does this implementation plan affect Microsoft AD FS 2.0 deployments?

Microsoft AD FS 2.0 is not able to consume the InCommon metadata aggregate, so the answer depends on the external process used to refresh and verify metadata on behalf of AD FS. Some deployments use a tool called FEMMA, which does not verify the signature on the metadata. In this case the XML signature on the new metadata aggregate will have no adverse effect. An AD FS deployment that uses FEMMA is advised to migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014).

An alternative to FEMMA called pysFEMMA will verify the signature on the metadata, however. Like the Shibboleth SP, an AD FS deployment that uses pysFEMMA will have difficulty migrating to the new metadata aggregate if the underlying crypto library is incompatible with SHA-2. See the AD FS Metadata Config wiki page for more detailed information about pysFEMMA.

How does this implementation plan affect deployments based on commercial products other than Microsoft AD FS 2.0?

AFAIK, no commercial product is able to consume the InCommon metadata aggregate, so the answer is more-or-less the same as it is for Microsoft AD FS 2.0: it depends on the tool chain used to refresh and verify metadata.