Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Okay everyone,

I think this is a somewhat reasonable summary of at least some of the things we’ve been discussing (hopefully it even captures what we ended up with at the end of today’s call). As I wrote it, I got caught up – much as David did writing the Alternative Means statement – trying to keep straight which of these elements we felt strongly about, and which were ones we still had questions about, etc.

For those not on the call, this is a proposal (or clarification) we’d be submitting to the IAAF folks.

There are some new implications that I think will arise if we the following interpretation is “ratified” (e.g., we may need to disallow SPNEGO support on IDPs), but we can deal with those if this is accepted.

The way I dealt with my ongoing concern about the 800-63 language on “impracticality” and “2^80 cryptographic operations” was just by referencing it in footnote #2 below.

--- Eric

 

Proposal for Interpretation of 4.2.3.6.2

Clarify that only Authentication Secrets[1] that can be used to directly authenticate to the IDP, to modify authentication credentials (i.e., can be submitted directly to a change my password page) or to practically[2] determine a user’s password are addressed by this requirement

Another way of stating this is that the intent of 4.2.3.6.2 is only to protect against risks that can attack the IDP’s direct authentication to its Verifier; protection of non-IDP Authentication Secrets (session keys, challenges, etc.) that incidentally use the same Verifier as the IDP are not in scope of 4.2.3.6.2.

Discussion

Many authentication processes use the user’s password is used to protect the session information – e.g., Kerberos sends a message with an encrypted session key and NTLMv2 sends a message with a hashed response to a challenge – but do not transmit actual user passwords. Technically speaking, these messages would be considered “authentication secrets” and in the cases of these two technologies they do not use approved Encryption Algorithms in their Protected Channels.

As noted above, our proposal is that these authentication secrets are only in scope of 4.2.3.6.2 if the authentication information they contain can be used to directly authenticate to the IDP or to services that can directly modify the user’s credentials (such as a “change my password” page).

As an example, consider a file sharing service and an IDP that both use the same Verifier. A file system client authenticates and in doing so shares an Authentication Secret with the Verifier. If an attacker that managed to obtain the client’s Authentication Secret is then able to use that Authentication Secret to impersonate the user to the file sharing service (e.g., through replay attack), such an attack is immaterial to 4.2.3.6.2.

An attack is material to 4.2.3.6.2 only if the attacked Authentication Secret can be directly used to authenticate to the IDP (e.g., generate an assertion), to modify the user’s credential (again, e.g., via a “change my password page”, or can be used to practically[1] derive the raw IDP credential (password).

 

[1] The term “Authentication Secret” is assumed here to include the information in an authentication packet; e.g., the initial exchange of a session key or the response to an authentication challenge is an “Authentication Secret”.

[2] The use of the language “practically” here is echoing the language of 4.2.5.2 Resist Eavesdropper Attack, which requires that eavesdropping make it “impractical” to obtain the original secret through eavesdropping. It is NOT intended to reference the definition of “nearly impossible” as defined in NIST 800-63-1, page 17, footnote 26 (where “impractical” is given a numeric measure of requiring at least on the order of 2^80 cryptographic operations to break).