Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

Resending to cc the AD-Assurance Working Group.

Ann

From: Ann West <>
Date: Monday, August 26, 2013 1:58 PM
To: "" <>
Subject: AD Assurance: Clarification on Authentication Secrets

Good afternoon,

The issue below will be discussed on the AAC call tomorrow.

Best,

Ann

-------------

From the AD-Assurance Working Group:

The AD Assurance Working Group is finalizing our work on the updated Cookbook and alternative means needed to address gaps with MS AD compliance with the Profiles and with approved algorithms in particular. 

Our discussions and action plan rest completely on our understanding and correct interpretation of the Profile language and requirements.  Your help is needed to resolve an intent question, which, if we are correct, would simplify our recommendations to the Community: 

Regarding 4.2.3.6 Strong Protection of Authentication Secrets, and in particular 4.2.3.6.2, what authentication secrets are in scope for these criteria?

Proposal for Interpretation of 4.2.3.6.2

The AD Assurance WG interprets Authentication Secrets[1] in this context as those that can only 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.

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. They are addressed elsewhere in the spec, such as in 4.2.5 Authentication Process.

Do you concur with our interpretation?  

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

Ann West

Assistant Director,

InCommon Assurance and Community

Internet2 based at Michigan Tech

 

office: +1.906.487.1726