Transition to SHA-2
Background
In sp800-131A, published in January 2011, NIST updated its recommendations for use of several cryptographic algorithms and key lengths for use in the US Federal government. In particular, it calls for discontinuing use of the SHA-1 digest function or hash algorithm in digital signatures effective January 1, 2014 and recommends using any of the digest functions known collectively as SHA-2 for use in digital signatures.
There are two federation use cases in which SHA-1 is or might currently be used for digital signatures.
- Many SAML protocol messages and assertions are digitally signed. All releases to date of the Shibboleth IdP use SHA-1 as the digest function and for RSA signatures.
- InCommon metadata is signed using SHA-1 as the digest function and for RSA signatures.
Although NIST recommendations need not be binding outside of the US Government, InCommon must pay attention for two reasons. The first is that the InCommon Identity Assurance program references NIST recommendations with regard to cryptographic algorithms. Basically, crypto algorithms used in a Bronze or Silver compliant implementation either must be approved by NIST or be covered by an InCommon-approved Alternative Means (AM). So, campuses wanting Silver or Bronze must either use SHA-2 or InCommon must approve an alternative they can use. So, unless an AM would say "it's ok to continue using SHA-1 for digital signatures", some change to widely deployed behavior is needed, and for that appropriate testing and validation needs to be done to ascertain how it will work and how to advise deployers accordingly.
So why shouldn't an AM be approved that says "SHA-1 is still ok"? Recall that an approved AM must demonstrate that the alternative means addresses the risk addressed by the means it is alternative to in a comparable or superior manner. So the only possible basis for approval is if switching to SHA-2 would introduce greater risk to operations than sticking with SHA-1. That could be the case if a sufficient number of production SPs with which a given IdP interoperates are not capable of processing SHA-2 signatures from the IdP, or are not capable of processing assertions signed variously by different IdPs using SHA-1 or SHA-2 signatures. Hence, adequate testing needs to be done that will either validate that almost all SPs play well with SHA-1 and SHA-2, or that many do not and fixing them is non-trivial.
The second reason InCommon should pay attention to sp800-131A is that, as a matter of best practice, NIST has moved the bar up a notch. InCommon should implement best practices to continue to earn the trust of its members; that is its essential reason for being. InCommon should adapt its metadata distribution operations accordingly, and it should enable participants wishing to achieve Bronze or Silver to likewise observe best practice.
What needs to be done?
The following proposals are offered to start discussion. I'm confident that the collective experience of TAC members will improve upon these.
I'll note that there is reason to be optimistic. Searching for a little while indicates that releases of most SAML implementations in the last year or two that are prevalent in InCommon support SHA-2. I'm less certain how well some of these (non-Shibboleth) releases handle a mix of SHA-1 and SHA-2.
Prepare a Shibboleth IdP extension that makes it easy to switch to SHA-2
For the Shibboleth IdP, an extension to change the algorithm the IdP uses to sign SAML messages already exists in a rudimentary form. A further enhancement is needed that would enable an IdP operator to deploy the extension in a simple fashion. Future shibboleth IdP releases should incorporate a simple means to select the digest function to be used in signing assertions.
The doc at the URL above also contains some detailed information about prerequisites and caveats for enabling SHA-2 for IdPs or SPs.
Test handling of SHA-1 and SHA-2 by InCommon SPs
Arrange to send an unsolicited SHA-1 signed response or assertion and a SHA-2 signed response or assertion to each production SP in InCommon and see how they respond. The results should help us identify a set of SPs that accept SHA-1 but not SHA-2. Probably should contact a subset of SP operators to learn about releases, configurations, and operating environments that produce the problem, and assess prospects for remedying.
Even though all current SPs handle SHA-1, sending both SHA-1 and SHA-2 would help us determine when a failure of the test procedure is unrelated to the digest algorithm.
Depending on the results of this testing, a next step would either be focused on disseminating documentation to deployers about how to enable SHA-2 in their operation, or if the data indicate that shifting to SHA-2 would expose many InCommon members to unacceptable operational risk, an Alternative Means would be written on that basis.
Design and implement an enhancement to InCommon's metadata distribution that enables use of SHA-2
Perhaps this can simply be publishing two signed metadata files, one using SHA-1 and the other SHA-2, so that participants wanting or needing to use SHA-1 have that option available to them. The primary aggregate should be migrated to SHA-2 in order to move the federation forward.
Who should do what?
The SHA-2 Shibboleth IdP extension would best be one that exists in a single, established code namespace, so that each deployment does not need to deal with namespace issues. It would also be simplest if the resulting extension and corresponding wiki doc exist on the shibboleth.net site in suitable locations. Perhaps this is best done by the Shibboleth developers.
A TAC subcommittee should quickly be chartered and spun up to do the testing. Liaison with the InCommon Assurance Advisory Group would be desirable so that they can monitor and see whatever the result will be at the earliest opportunity. We should aim for the testing to be done and analysis and follow ups complete by end of August 2012. A fun summer project for a couple of inspired techies! Also, we can ask technical leads affiliated with common SAML implementations to help us.
Another TAC subcommittee, perhaps the Metadata Distribution Working Group, should take on the task of metadata distribution.