Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] Re: AD Assurance: Clarification on Authentication Secrets

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] Re: AD Assurance: Clarification on Authentication Secrets

Chronological Thread 
  • From: Ann West <>
  • To: "" <>
  • Cc: "" <>
  • Subject: [AD-Assurance] Re: AD Assurance: Clarification on Authentication Secrets
  • Date: Mon, 26 Aug 2013 17:59:09 +0000
  • Accept-language: en-US

Resending to cc the AD-Assurance Working Group.


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.




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 Strong Protection of Authentication Secrets, and in particular, what authentication secrets are in scope for these criteria?

Proposal for Interpretation of

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

Archive powered by MHonArc 2.6.16.

Top of Page