Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

I looked over the TFPAP v1.1.0 Trust Criteria in Appendix A for (A-2) Assurance Level 2.  In the section directly related to 4.2.3.6 they refer to “private credentials”.

“Cryptographic protections are required for all messages between the Identity Provider and Verifier which contain private credentials or assert the validity of weakly bound or potentially revoked credentials. Private credentials shall only be sent through a protected channel to an authenticated party to ensure confidentiality and tamper protection. “

http://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_TFPAP_v1.1.0.pdf

By cross-referencing back to NIST SP800-63, the definition of a Private Credential includes the hashed value of a password.  Refer to section 7.1.1 in 800-63.

Curiously in the Bronze & Silver IAP v1.2 for 4.2.3.6, #1 says “Protected Channels must be used.”  #2 says “Protected Channels should be used.”  Maybe that allows some wiggle room depending on your definition of must & should?

--Jeff C.

 

From: [mailto:] On Behalf Of Michael W. Brogan
Sent: Monday, August 26, 2013 2:20 PM
To:
Subject: RE: [AD-Assurance] Interpretation of 4.2.3.6.2

 

Looks good to me. Thanks.

--Michael

 

From: [] On Behalf Of Ann West
Sent: Monday, August 26, 2013 6:23 AM
To:
Subject: Re: [AD-Assurance] Interpretation of 4.2.3.6.2

 

Hi Eric,

 

I suggest we add some intro text and include a shorter explanation. I've taken a stab below.

 

Thoughts? Everyone?

 

Ann

 

------

 

The AD Assurance Working Group is finalizing our work on the updated Cookbook and alternative means needed to address gaps with MS AD compliance 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

 

 

 

From: Eric Goodman <>
Reply-To: "" <>
Date: Friday, August 23, 2013 4:15 PM
To: "" <>
Subject: [AD-Assurance] Interpretation of 2.4.3.6.2

 

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