Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

Got it. Thanks. 

Ann

Sent from my phone. 

On Sep 6, 2013, at 1:34 PM, "Eric Goodman" <> wrote:

Typo noted:

 

Interpretation of IAP Section 4.2.5.2 Resist Eavesdropper Attack

Because this section refers specifically to traffic between the Subject and the Verifier (not just the IDP), this section would apply to all authentication traffic between to the AD DS, not just Subject to IDP authentication.

The correction is noted here, and I’m fixing it on the web page.

 

Incomplete data noted:

 

Interpretation of IAP Section 4.2.8.2.1 - Network Security

"Network communications supporting IdMS operations" is interpreted to mean communications between the actual software elements of the IDMS operation or administrative traffic to the IDMS.

So the only AD-specific communications that would be in scope of this requirement is intra-domain controller password replication. (Note that provisioning of passwords into AD-DS is covered by 4.2.3.6.1)

The italic section was added on the website right at the end of the call, and probably just after David made this copy.

--- Eric

 

From: [] On Behalf Of David Walker
Sent: Friday, September 06, 2013 10:30 AM
To: Ann West
Cc: InCommon AD Assurance Group
Subject: [AD-Assurance] Interpretation of IAP requirements for AAC verification

 

Ann,

Here are the IAP requirement interpretations that the AD Assurance group would like to verify with the AAC before completion of the 2013 AD Cookbook.

David

---

 

Interpretation of IAP Section 4.2.3.4 - Stored Authentication Secrets

These requirements apply when AD DS is used as the IDP's Verifier.

We interpret this requirement to mean that encryption software that decrypts disk sectors (and not just individual Authentication Secrets) as they are accessed would meet the requirement of "only decrypt(ing) the needed Secret when immediately required for authentication" as spelled out in this section, presuming such software uses Approved Algorithms for the encryption process.

Interpretation of IAP Section 4.2.3.6.1 - Strong Protection of Authentication Secrets (subsection .1)

This requirement applies when IDP Verifier passwords are provisioned into an AD DS store, whether or not the AD DS store being provisioned to is the actual IDP Verifier.

For example, if an MIT Kerberos system is used as the IDP Verifier, but the passwords used by that Kerberos system are also provisioned into an AD DS, the AD DS provisioning process is in scope and therefore must use Protected Channels, even though it is not being used as the IDP's Verifier.

Interpretation of IAP Section 4.2.3.6.2 - Strong Protection of Authentication Secrets

Authentication Secrets[1] in the context of this requirement is interpreted to mean those secrets (passwords, Kerberos session keys, NTLM challenge responses, etc.) 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.

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 that incidentally use the same Verifier as the IDP, such as Windows/Kerberos Ticket used to authenticate a user to a domain (a la ctrl-alt-del)[3], 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.

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

[3] If the IDP login page supports SPNEGO authentication, then the Windows/Kerberos Tickets WOULD be in scope of this requirement.

Interpretation of IAP Section 4.2.5.1  Resist Replay Attack

This section applies only to communication between the Subject and the IDP itself.

Interpretation of IAP Section 4.2.5.2 Resist Eavesdropper Attack

Because this section refers specifically to traffic between the Subject and the Verifier (not just the IDP), this section would apply to all authentication traffic between to the AD DS, not just Subject to IDP authentication.

We interpret that in the context of the IAP 1.2, the use of the word "impractical" in the requirement text is used in the common "vernacular" sense, and does not intend to imply the strict quantitative measure noted in the NIST 800-63-1 footnote noted above. From the IAP text (emphasis added):

Any eavesdropper who records all the messages passing between a Subject and a Verifier or relying party must find that it is impractical to learn the Authentication Secret or to otherwise obtain information that would allow the eavesdropper to impersonate the Subject

Interpretation of IAP Section 4.2.8.2.1 - Network Security

"Network communications supporting IdMS operations" is interpreted to mean communications between the actual software elements of the IDMS operation or administrative traffic to the IDMS.

So the only AD-specific communications that would be in scope of this requirement.