Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Eric,

 

I don’t have any solutions, but I thought I would try to come at the problem from a different angle and see if this covers it:

 

I think part of the reason we had so much protocol-centric concerns with IAP 4.2.3.6.3 in the AD cookbook was because we are trying to carve out a slice where we can make AD fit into the silver profile.

 

When we use HTTPS (with an approved cipher, of course) to transport a clear-text password, and let the IdP talk to the verifier on its own secure channel (LDAPS, start TLS, etc.) then we are “covered” for approved algorithms from the IdP side of things regardless of whether AD uses an approved algorithm.  (IAP 4.2.3.6.2)

 

However, when AD does its own (non IdP) authentications and protocols like NTLM, etc. (as a Verifier to a non-IdP app), then AD transports the secret around perhaps in a manner that is not using approved algorithms and so it would be helpful to identify those as either out of scope or non-IdP protocols so they don’t matter.   I think we say those ‘secrets’ aren’t used by the IdP (directly).

 

Of course, they do matter for offline password cracking (eavesdropper), but they wouldn’t matter for replay, hijack, etc., so that’s where those other cases get lumped in, even if they are covered under other parts of the IAP.  I think we already determined that IAP 4.2.5 applies only to IdP, whereas IAP 4.2.3 covers all credential technology.  But maybe we’re trying to say that we’re covering most (but not all) of the same requirements needed to ensure strong protection of authentication secrets.

 

This gets to be where we start shaving off some of the square peg and hammering it into that round hole.

 

Jeff

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Tuesday, March 11, 2014 3:05 PM
To:
Subject: [AD-Assurance] RE: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

Hi Eric, thanks for forwarding those comments to the list! :)

 

 

Chris' comment refers to the interpretation of IAP section 4.2.3.6.3. Tom Barton had also responded with comments on that section. Ironically, there are contradictory interpretations between us, Tom Barton and Chris Spadanuda on the meaning of the sections.

 

In short, what we seem to be saying is:

 

Question	Tom Barton	Chris Spadanuda	AD Cookbook Draft
What differentiates when IAP 4.2.3.6.2 vs. IAP 4.2.3.6.3 governs a circumstance?	Network transmission vs. in-app disclosure of secrets.	IdP vs. non-IdP app use of a credential.	Authentication protocol in question is used by IdP vs. not.

 

Tom's interpretation would lead me to delete IAP 4.2.3.6.3 from the Cookbook altogether (as I commented in response to his message), as it is not related to protocols or authentication, really, just in-app handling of secrets within non-IdP applications.

 

Chris' interpretation of IAP 4.2.3.6.3 would cause me to simplify the language in 4.2.3.6.2 to refer only to IdP use of credentials and to shift some of the language in our interpretation of IAP 4.2.3.6.2 (around use of credentials in the non-IdP applications) into IAP 4.2.3.6.3, and potentially to remove some elements from IAP 4.2.3.6.3 (around other non-IdP protocols).

 

 

It's not immediately obvious to me which way to go here. My take after reviewing the section against each interpretation is that Tom's interpretation is perhaps most literally correct, so I would be inclined to follow my previous suggestion of removing most references to IAP 4.2.3.6.3. However, if the AAC is split, it's not clear that we should use one vs. the other's interpretation.

 

But I guess we now at least have a topic for this Friday's call!

 

--- Eric

 

 

 

 

From: [] On Behalf Of Eric Goodman
Sent: Tuesday, March 11, 2014 11:35 AM
To:
Subject: [AD-Assurance] FW: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

Greetings AD Assurance folks.

 

This was the last comment (beyond Tom and Warren's) on our current draft, which was forwarded to me (and not the list) this AM.

 

I will respond to this shortly with my own thoughts on Chris' input, but I wanted to let Chris' message be in the thread as its own item for easier retrieval in the future.

 

--- Eric

 

 

From: Farmer, Jacob []
Sent: Tuesday, March 11, 2014 9:25 AM
To: Eric Goodman
Subject: FW: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

 

 

From: [] On Behalf Of Christopher A Spadanuda
Sent: Tuesday, February 25, 2014 2:31 PM
To:
Subject: Re: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

My two cents.

 

As Tom stated, it may be easier to say nothing about auth secrets that are not in the scope for the IAP. 

 

 

Looking at 4.2.4. Interpretation of IAP Requirement, Section 4.2.3.6.3 - Strong Protection of Authentication Secrets

 

FWIW my interpretation of 4.2.3.6.3 is that it is not about technical replay or technical protections during transit, but more about having protections in place for situations in which a non-IdP application might try to utilize the IdP's credentials. A mitigation might be a policy that informs users they are not to use their IdP credentials for non-IdP applications. e.g. - Users shall not use their university credentials for non-university applications such as facebook and twitter.  Or "Campus AD credentials shall not be used on the separate AD run by a School or College."

 

Chris

___________________________________________________________________
Chris Spadanuda
Assistant Director Network and Operations Services
University of Wisconsin–Milwaukee
University Information Technology Services
E-mail:
Cell Phone: 414 507-4761



>>

 

---

From: "Jacob Farmer" <>
To:
Sent: Tuesday, February 25, 2014 11:45:17 AM
Subject: FW: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

 

From: [] On Behalf Of Tom Barton
Sent: Sunday, February 23, 2014 5:14 PM
To:
Cc:
Subject: Re: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

Hi Eric and everyone,

I am really grateful for all of the work that has gone into the AD Silver Cookbook. This will be a valuable resource to many. Some comments about the near-final draft follow.

Cookbook section 4.2.3.

I agree with the statements that clarify which authentication secrets are in scope for the IAP. The second paragraph goes a bit further by giving a few examples of authentication secrets that might not be in scope, and says of these "These non-IdP Authentication Secrets are addressed elsewhere in the spec, such as in 4.2.3.6.3.". I don't think non-IdP authentication secrets, ie, those not used to authenticate to the IdP, regardless of what other apps they may be used to authenticate to, are specifically addressed anywhere in the IAP, with the possible exception of some authentication scenarios addressed in IAP 4.2.8.2.2. In particular, IAP 4.2.3.6.3 is scoped to the same set of authentication secrets as IAP 4.2.3.6.1 and 4.2.3.6.2.

Is it perhaps better to say nothing at all about authentication secrets that are not in scope for the IAP?

Cookbook section 4.2.5.

There is a typo: ^4.2.5.2^4.2.5.1

IAP 4.2.3.6.3 doesn't specifically address replay of non-IdP authentication/assertion traffic.

Cookbook section 4.2.6.

IAP 4.2.3.6.3 doesn't specifically address eavesdropping of non-IdP authentication/assertion traffic.

On 2/22/2014 12:22 AM, Eric Goodman wrote:

Greetings AAC Members,

 

As most of you are aware, the current AD Assurance Cookbook workgroup (henceforth “the Workgroup”) has been working on an update to the AD Assurance Cookbook (“the Cookbook”) that was originally released in 2012. One of the changes in the Cookbook update is the addition of the Workgroup’s interpretations of key InCommon Silver IAP requirements. These interpretations provide the basis of the Workgroup’s recommendations in later portions of the document.

 

In October 2013, the AAC reviewed the Workgroup’s interpretations, and the two groups met in November to discuss the AAC feedback. In response, the Workgroup made further edits to the structure and interpretations in the Cookbook. In early January we released a new draft of the Cookbook, and based on community comments we have made one more round of edits to the document. At this point we have created what we hope to be our “final” version of the document.

 

Before we release this “final” version of the Cookbook, the Workgroup requests that the AAC review the updated Interpretations section. The relevant text of the Cookbook is attached to this email. (Note that because the interpretations actually appear over two sections of the Cookbook, there is some language that reads oddly out of context, hopefully this isn’t too distracting).

 

On behalf of the Workgroup members, thank you in advance for your consideration, and we look forward to your feedback.

 

--- Eric

--

Eric Goodman | Identity and Access Management Architect

University of California, Office of the President

 

4.1.2. Interpretation of IAP requirement, Section 4.2.3.4 - Stored Authentication Secrets

This requirement applies to IdP Verifier passwords stored in an AD DS password store, whether or not the AD DS store is the actual IdP Verifier. Note that this requirement only applies to passwords for accounts that are actually authenticated by the IdP (non-IdP accounts that are "co located" in the AD DS have no such requirements).

We interpret that this section is concerned with two separate controls:1) Logical access controls to prevent users or co-resident applications from accessing the password store directly -- addressed in the second sentence of the requirement textand2) Physical access controls to prevent attacks on the raw data files (passwords) stored on the disk -- addressed by the listing of the three mechansims for encrypting passwords at rest

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

4.1.3. Interpretation of IAP requirement, Section 4.2.3.6.1 - Strong Protection of Authentication Secrets (First Sentence)

Note, this IAP requirement addresses both storage and transmission of passwords, so is addressed under both the "Encrypting Passwords" topic and the "Securing Authentication Traffic" sections.

This requirement applies to IdP Verifier passwords stored in an AD DS password store, whether or not the AD DS store is the actual IdP Verifier. Note that this requirement only applies to passwords for accounts that are actually authenticated by the IdP (non-IdP accounts that are "co located" in the AD DS have no such requirements). 

For example, if a non-Windows system is used as the IdP Verifier, but the same passwords used by that Verifier are also stored in an AD DS, the AD DS password store is in scope and must be protected per sections 4.2.3.4 and 4.2.8, even though it is not being used as the IdP's Verifier. (Again, this only applies to passwords for accounts that are actually authenticated by the IdP)

…

4.2.2. Interpretation of IAP requirement, Section 4.2.3.6.1 - Strong Protection of Authentication Secrets (Second Sentence)

Note, this IAP requirement addresses both storage and transmission of passwords, so is addressed under both the "Encrypting Passwords" topic and the "Securing Authentication Traffic" sections.

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. Note that this requirement only applies to passwords for accounts that are actually authenticated by the IdP (non-IdP accounts that are "co located" in the AD DS have no such requirements).

For example, if a non-AD DS system is used as the IdP Verifier, but the passwords used by that Verifier are also provisioned into an AD DS, that 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. (Again, this only applies to passwords for accounts that are actually authenticated by the IdP, or which allow modification of accounts authenticated by the IdP)

4.2.3. Interpretation of IAP Requirement, 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 or to directly modify authentication credentials (e.g., can be submitted directly to a change my password page).

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 Tickets used to authenticate a user to a domain (a la ctrl-alt-del)[2], are not in scope of 4.2.3.6.2. These non-IdP Authentication Secrets are addressed elsewhere in the spec, such as in 4.2.3.6.3.

[1] The term “Authentication Secret” is assumed here to include the information in an authentication packet; e.g., in addition to actual authentication credentials (username/password), the information negotiating the initial exchange of a session key or the response to an authentication challenge is an “Authentication Secret”.

[2] This assumes that the local Windows/Kerberos tickets cannot be leveraged to authenticate the user to the IdP, such as a standard webpage that prompts for entry of user credentials. If the IdP supports mechanisms that allow the user to generate authentication assertions based directly on the possession of local Windows/Kerberos tickets (e.g., SPNEGO, GSSAPI and certain ADFS configurations), then the Windows/Kerberos tickets used in that interaction WOULD be in scope of this requirement.

4.2.4. Interpretation of IAP Requirement, Section 4.2.3.6.3 - Strong Protection of Authentication Secrets

This section addresses all handling of IdP Verifier authentication secrets, even if those authentication secrets are not used to authenticate anyone to the IdP. Note that authentication secrets that could be replayed to authenticate directly to the IdP are also covered by section 4.2.3.6.2, which has stricter requirements around transport encryption.

That is, assuming an IdP that requires manual entry of a username/password:

• applications (including non-IdP applications) that handle the username/password would be covered by both sections 4.2.3.6.2 and 4.2.3.6.3.
• applications (including non-IdP applications) that handle non-IdP authentication secrets based on IdP passwords (e.g., LM, NTLMv1, NTLMv2 or Kerberos authentication packets for Silver IAQ users) would be covered only by section 4.2.3.6.3

This section requires that policies and procedures are in place to minimize the risk of this traffic being attacked in a way that would subvert the security of IdP authentication events. While traffic covered in this section may use Protected Channels to secure authentication communications, an institution could also use other mechanisms that are generally considered secure, even if they are not Protected Channels. 

For completeness, we note that protection of the password while it is being locally processed within any application is also required, not just protection while in transit to or from said application. However, security of the information while being handled in a transient fashion within a web application is beyond the scope of AD DS configuration, so is not covered here.

4.2.5. Interpretation of IAP Requirement, Section 4.2.5.1 -  Resist Replay Attack

This section refers specifically to traffic between the Subject and the IdP, the IdP's Verifier, and/or a relying party as part of an IdP authentication/assertion event. All other traffic between the Subject and the AD DS is beyond the scope of 4.2.5.2. Replay of non-IdP authentication/assertion traffic is covered by sections 4.2.3.6.2 and 4.2.3.6.3.

4.2.6. Interpretation of IAP Requirement, Section 4.2.5.2 - Resist Eavesdropper Attack

This section refers specifically to traffic between the Subject and the IdP, the IdP's Verifier, and/or a relying party as part of an IdP authentication/assertion event. All other traffic between the Subject and the AD DS is beyond the scope of 4.2.5.2. Eavesdropping on non-IdP authentication/assertion traffic is covered by sections 4.2.3.6.2 and 4.2.3.6.3. 

4.2.7. Interpretation of IAP Requirement, 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. 

The only AD DS-specific communications protocol 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)