Assurance

[Eric Goodman <>]

Hi all,

 

I’ve not been paying close enough attention to the impacts of the SHA-1 digest algorithm rules change (no longer an Approved hashing Algorithm), so wanted to float my take on the impact.

 

I believe I see four potential areas where the SHA-1 digest use likely comes into direct play in meeting assurance requirements. I’d love feedback on any of these points (especially items 2 and 4, where I’m not sure if there’s actually a requirement or not) and/or identification of additional areas likely to be impacted.

 

I haven’t found one, but I recognize there’s a good chance this stuff has been outlined elsewhere. If there’s an existing summary that addresses these points, feel free to point me at that.

 

Thanks,

 

--- Eric

 

 

 

### SHA-1 uses (potentially) disallowed under Bronze/Silver by the NIST update:

 

 

1) Signatures on IdP TLS certificates

 

Required by IAP 4.2.5.3 “Secure Communication” for both Bronze and Silver (Communication between Subject and IdP)

 

Compliance Concerns: Discussion on this list indicated concern about browser support of SHA-2, especially for older browsers. (http://www.digicert.com/transitioning-to-sha-2.htm contains a list of browser compatibility)

 

 

2) Signatures on certificates used in IdP Signing/Encrypting operations.

 

Required(?) by IAP 4.2.7.3 “Cryptographic Security” for both Bronze and Silver

 

The requirements states “Cryptographic operations are required between an IdP and any SP. Cryptographic operations shall use Approved Algorithms.” Paralleling SHA-1 being disallowed for “front end” TLS certificates, I could see this disallowing use of SHA-1 signed certificates in metadata as well, especially if SOAP endpoints are exposed and protected by said certs.

 

Compliance Concerns: Key rollover could be required. Any SP compatibility issues?

 

 

3) Signatures on assertions

 

Required by IAP 4.2.7.3 “Cryptographic Security” for both Bronze and Silver

 

Compliance Concerns: Updating Shib to support SHA-2 XML signatures is an IdP-wide change See: https://wiki.shibboleth.net/confluence/display/SHIB2/Changing+IdP+Signature+Method+Algorithm

Last update I heard was that testing has indicated that InCommon SPs are almost all compliant with SHA-2 signed certs these days. Individual SPs (those not in InCommon) would need to be tested, well, individually.

 

 

4) Stored password hashes

 

Required by IAP 4.2.3.4 “Stored Authentication Secrets” for Silver only

 

This is particularly of note for those using LDAP-based solutions, where it’s common to store the userPassword as a SHA or SSHA hash. Is a salted SHA-1 password hash one of the disallowed uses of SHA-1 under the new rules? It’s not a message digest, which seems to be the main focus of the advisories, but it is clearly a hashing use of SHA-1.

 

Compliance Concerns (if required): Forced user password changes – or at least user re-entry of plaintext password – required (if using SHA or SSHA). The LDAP clients I’ve looked at seem to support SSHA256 or other salted SHA-2 based schemes, either natively or via community plugins.