The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Migrating to SHA-2

As of January 1, 2014, NIST disallows the use of the SHA-1 digest algorithm in conjunction with digital signatures (see: NIST SP 800-57 Part 1, Revision 3, July 2012, Tables 3 and 4). This was a major driver behind the Phase 1 Recommendations of the Metadata Distribution Working Group, which gave rise to the Phase 1 Implementation Plan, a major effort to phase out the use of SHA-1 in InCommon metadata that began on December 18, 2013 and ended on June 30, 2014.

As of June 30, 2014, all metadata aggregates distributed by InCommon are signed using the SHA-256 digest algorithm. Because of this, we know that many of the SPs in the InCommon Federation support SHA-256.

Like metadata, SAML messages may be digitally signed for authenticity and integrity. Any SAML entity (IdP or SP) may sign a message but in practice it is the IdP that wields a signing key since SAML assertions issued by the IdP MUST be signed. The SP uses the IdP’s public signing key in metadata to verify the signature on the assertion just-in-time, that is, when the assertion is presented to the SP by the browser user.

It is believed that most IdPs in the InCommon Federation are signing assertions using the SHA-1 digest algorithm. This is because most IdP deployments use the Shibboleth IdP software, which is known to support SHA-1 only, at least out of the box.

To enable SHA-2 support in the Shibboleth IdP, you can use a 3rd-party extension to enable SHA-2 capability for Shibboleth IdP versions 2.3 and later. Note that the resulting Shibboleth configuration is all or none, either SHA-1 or SHA-256.

Recommendations for Shibboleth IdPs

Sites running the Shibboleth IdP software should deploy a test IdP with SHA-2 support as described in the next section and then migrate to that test environment as appropriate.

OTOH, SimpleSAMLphp has good support for signing assertions using the SHA-256 digest algorithm. It can be configured to sign assertions on a per-SP basis, that is, a simpleSAMLphp IdP can sign assertions using the SHA-1 digest algorithm for some SPs and the SHA-256 digest algorithm for others.

Recommendations for simpleSAMLphp IdPs

Sites running the simpleSAMLphp IdP software can and should migrate to SHA-256 as soon as possible. A perfectly reasonable strategy would be to configure the use of SHA-256 by default but to fall back to SHA-1 for those few remaining SPs (perhaps external to InCommon) unable to handle SHA-256.

A Migration Strategy for Shibboleth IdPs

This section describes how to migrate a Shibboleth IdP from SHA-1 to SHA-256.

  1. Evaluate the use of back-channel protocols on your production IdP. Eliminate unused protocols and endpoints. Phase out seldom-used protocols if possible. An optimally configured IdP will support SAML2 on the front channel only.
  2. Deploy a test IdP at a distinct IP address. Configure this test IdP to be identical to your production IdP (same metadata sources, same attribute release policy, etc.).
  3. Using IdP-initiated SSO on the test IdP, systematically push SAML2 assertions to endpoints at select partner SPs.
  4. Install a 3rd-party extension on the test IdP. The extension allows you to change the signature/digest algorithm that the IdP uses to sign assertions. Configure the test IdP to sign assertions using the SHA-256 digest algorithm.
  5. Repeat step 3. This round of testing may uncover SPs that are not compatible with the SHA-256 digest algorithm.

  6. [optional] Map the IdP domain name (in metadata) to the IP address of the test IdP using /etc/hosts on a client machine. Using SP-initiated SSO, systematically test select partner SPs using the client machine.

If you encounter a partner SP that is not compatible with SHA-256, with no hope of upgrading, you can work around the incompatibility by deploying an IdP Proxy. The SP component of the IdP Proxy is integrated with your test IdP. Both are configured to sign assertions using the SHA-256 digest algorithm. The IdP component of the IdP Proxy is integrated with the partner SP. Both are configured to sign assertions using the SHA-1 digest algorithm.

Note: If the partner SP does not support message-level encryption, the IdP Proxy can compensate for that shortcoming as well.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels