Assurance

[Eric Goodman <>]

Thanks Tom and Joe,

Followup comments below.

--- Eric

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

[...]
 
> 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.)

So basically, the key being in metadata, associated with a specific set of 
endpoints proves the provenance of the key itself, irrespective of the 
signature. And since the metadata (for InCommon at least) is signed with 
SHA-2, then presuming you validate the metadata's signature when you consume 
the data, then you’re “transitively” using an Approved Algorithm. 

I'm wondering if there's still a compliance requirement for those that are 
not auto-consuming (and validating) metadata.

-----------
> > Compliance Concerns: Key rollover could be required. Any SP
> > compatibility issues?
> 
> There are no compatibility issues with software that's doing the Right
> Thing. 

I think that's a given, no? :)


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

[...]

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

The testing web page at 
https://spaces.internet2.edu/display/InCAssurance/Transition+to+SHA-2 doesn't 
contain those results. Might be worth linking to them from those pages if you 
have the results published. (The translation pages make it sound much more 
worrisome that the discussion of the results do).

> > 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: [...]
> 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.

I was largely thinking of providers who don't leverage (or validate) the 
metadata, but this is a good tip for those that do -- or at least can. Thanks.


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

Hopefully someone will! :)

--- Eric