Meeting the InCommon Assurance profile criteria using Active Directory

["Michael W. Brogan" <>]

I have no disagreement with your statement from an overall risk management perspective, but that isn’t necessarily the same thing as what the IAP requires. I just thought it curious that the language in 4.2.5 seemed focused on IdP authentication events and it doesn’t mention non-IdP applications at all.

 

In risk management exercises I look for cost-effective security. Investing a lot to replace/upgrade weak crypto while interfering with business operations is worth it only if eavesdropping, man-in-the-middle, session hijacking, and replay attacks are frequent avenues to credential compromise. But that doesn’t appear to be the case, despite all the potential threats that exist. The biggest problem at the UW (and I suspect many institutions) is that attackers ask users for their passwords and the users  comply.

 

I’m off on vacation for the next 10 days, so I’ll miss any interesting discussion about this that might come up on the next call.

 

--Michael

 

 

From: [mailto:] On Behalf Of David Walker
Sent: Friday, August 09, 2013 5:36 PM
To:
Subject: Re: [AD-Assurance] VERY drafty alternative means statement

 

Interesting point.  A principle I've always used is that credentials must be protected independent of where they may be stored or used.  So, it really doesn't matter, for example, if a password is exposed by unencrypted LDAP between the IdP and the Verifier, or in some other authentication event.  It's still the the credential, and it's still been exposed.

David

On Fri, 2013-08-09 at 23:22 +0000, Michael W. Brogan wrote:

To more directly answer the question you asked, yes, the argument is for the “inclusive and” and under that interpretation you’d do LDAPS and be done. In other places in the IAP there are specific references to non-IdP apps, but not in section 4.2.5. Why did the authors call this out in some sections and not others? Just an oversight? Or maybe they had a narrower interpretation in mind and it was intentional.

 

--Michael

 

From: Michael W. Brogan
Sent: Friday, August 09, 2013 4:14 PM
To:
Subject: RE: [AD-Assurance] VERY drafty alternative means statement

 

One use case is that AD is the IdP’s verifier (though that isn’t the case at the UW). But if you set up AD to be the verifier which authentication protocols are used? Are LM, NTLMv1, NTLMv2, LDAP, LDAPS, and Kerberos all necessarily on the plate? Isn’t there control over how the IdP uses AD to verify credentials?

 

--Michael

 

From: [] On Behalf Of Eric Goodman
Sent: Friday, August 09, 2013 4:05 PM
To:
Subject: RE: [AD-Assurance] VERY drafty alternative means statement

 

Isn’t the IdP’s verifier the AD domain?

 

Or are you positing that it’s an “inclusive and”; i.e., only those authentication events that specifically include BOTH the IdP and the verifier? (So authentication events between IdP and AD, excluding all others…)

 

I’ve certainly had the broader assumption, and the entire AD cookbook (even before the Alternate Means discussion) is based on that assumption as well. Otherwise just setting up your IdP to use LDAPS for authentication and lookup would solve the entire 4.2.5 section.

 

As to what the intent was, I can’t speak to that, not having written it, but I do think there’s language that implies the broader applicability. Don’t think I’ll have a chance to look for that before I break for the day though…

 

--- Eric

 

From: [] On Behalf Of Michael W. Brogan
Sent: Friday, August 09, 2013 3:56 PM
To:
Subject: RE: [AD-Assurance] VERY drafty alternative means statement

 

I have a really basic question about the IAP requirements and our gaps table.

 

I believe we’ve interpreted section 4.2.5 (Authentication Process) to apply to any authentication events that involve a credential that is also used by the IdP. That’s why we’ve had to spend time discussing NTLM and LDAP. But as I read through the IAP I wonder if that was the intent of the requirements:

 

·        Under 4.2.5 the IAP talks only about the subject and the IdP

·        Under 4.2.5.2 the IAP talks only about the subject, verifier, and relying party

·        Under 4.2.5.3 the IAP talks only about the subject and IdP

·        Under 4.2.5.5 the IAP talks only about the IdP

·        4.2.5 makes no mention of non-IdP apps

 

I understand that attacks against authentication events involving non-IdP apps can compromise credentials also used by the IdP, but I’m questioning if section 4.2.5 has a scope any broader than authentication events involving the subject, the IdP, and the IdP’s verifier.

 

We made this narrower interpretation at the UW during a preliminary gap analysis based on IAP 1.1. I don’t think the changes in IAP 1.2 would have affected that interpretation.

 

Are we making too much work for ourselves in regards to 4.2.5?

 

--Michael

 

From: [] On Behalf Of David Walker
Sent: Thursday, August 08, 2013 4:58 PM
To: InCommon AD Assurance Group
Cc: DHW
Subject: [AD-Assurance] VERY drafty alternative means statement

 

In our last call, I said I'd take a stab at an alternatives means statement for the use of unapproved algorithms in AD.  As I got further into writing, though, I realized I'm really not sure what we're looking for and where in the IAP we need it.  Looking over our "gaps" table, I think we need this only in 4.2.5.1 and 4.2.5.2 for MS Kerberos's use of MD4-HMAC without a tunnel, that NTLMv2 is OK, so I've written it up that way.  Is that all we're concerned about, or are we also wanting to include weaker authentication protocols like NTLMv1 and unsigned/unencrypted LDAP?  I apologize that my memory of last week's discussion is not up to the task.

Anyway, take a look at https://spaces.internet2.edu/x/soB2Ag , and we can talk about it tomorrow.  It has the arguments for allowing less than perfect security in AD; I just don't know what sections of the IAP we want to apply them to.

I also suggest that we make a pass over the gaps table to make sure it reflects our current thinking.  It'll make it easier for us keep track of what we still need to resolve.

David