Assurance

[Tom Scavo <>]

On Thu, May 1, 2014 at 6:00 PM, Eric Goodman 
<>
 wrote:
>
> ### 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)

I'll let Joe respond to this one since he's on top of what's happening
in the browser CA community.

> 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.

If you're talking about certificates in metadata, no, there is no
security concern there since the certificate wrapper on public keys in
metadata is wholly irrelevant. (If there were sufficient tooling to
handle bare keys, we'd probably be doing that.)

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

There are no compatibility issues with software that's doing the Right
Thing. If Microsoft were to issue a sunset date for SHA-1 in
certificates, we would have an interoperability issue AD FS
deployments, but I'm not how the TAC would respond to that.

> 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.

I just ran my scripts today, in fact. I tested a total of 2397 SAML2
HTTP-POST AssertionConsumerService endpoint locations in SP metadata.
Of those, only 7 tested positively incompatible with SHA-2. There are
100s of endpoints that gave inconclusive results (dead endpoints,
timeouts, inconsistent responses, etc.) but I consider this to be a
indicator of wide compatibility with SHA-2.

> Individual SPs
> (those not in InCommon) would need to be tested, well, individually.

Yes, and the best thing they can do is to point their metadata refresh
process at the production metadata aggregate:

http://md.incommon.org/InCommon/InCommon-metadata.xml

since it is signed using a SHA-2 digest algorithm. If they can consume
that metadata, then they can almost certainly consume a SAML assertion
signed using a SHA-2 digest algorithm.

Btw, on June 30, 2014, *all* metadata aggregates will be signed using
a SHA-2 digest algorithm, so every SAML deployment is strongly
encouraged to perform the above test and mitigate if necessary.
Otherwise we could see some breakage on June 30.

> 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.

I'll let someone else respond to that question.

> Compliance Concerns (if required): Forced user password changes – or at
> least user re-entry of plaintext password – required (if using SHA or SSHA).

Ouch.

> The LDAP clients I’ve looked at seem to support SSHA256 or other salted
> SHA-2 based schemes, either natively or via community plugins.

Hope this helps,

Tom