Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

It occurs to me that we don't have the following IAP section in our table:

4.2.5.3 (S) (B) SECURE COMMUNICATION

Communication between Subject and IdP must use a Protected Channel.

I believe this is intended to address communication of authentication secrets, particularly when combined with 4.2.5.1 and 4.2.5.2, but it doesn't actually say that.  I suppose this could be an alternative means proposal (to say that a protected channel isn't required unless an authentication secret is being transmitted), or we could simply state it as our interpretation.

Ann, what do you think?

David

On Mon, 2013-05-20 at 09:13 -0700, David Walker wrote:

Thanks, Brian.  I decided to remove the sentence.

David

On Mon, 2013-05-20 at 15:43 +0000, Brian Arkills wrote:

I think this is pretty accurate.

 

There are eavesdropper & replay attacks for both NTLMv2 & Kerberos, but they aren't isolated to attacks solely of those natures. Instead they are combination attacks which include eavesdropping, replay, and man-in-the-middle to achieve a session to the destination host whose pre-authentication exchange was previously eavesdropped.

 

I might wordsmith this sentence:

 

"There are currently no known off-the-shelf methods for breaking these protocols resistance to eavesdropper attacks in real-world environments."

 

to something slightly different, like:

 

"The only known method of breaking these protocols resistance to X attacks involves a combination of multiple attacks and styles of attack. For the purposes of the IAP, that method can be mitigated by employing reasonable security practices to domain controllers."

 

or perhaps it'd be cleaner to just drop that sentence.

 

From: [mailto:] On Behalf Of David Walker
Sent: Friday, May 17, 2013 5:44 PM
To: InCommon AD Assurance Group
Cc: DHW
Subject: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC


 

I went through the relevant IAP sections to determine which need an Alternative means statement for NTLMv2 and Kerberos with RC4-HMAC.  What I came up with is that none do.  See:

https://spaces.internet2.edu/x/hAlOAg


for a discussion and the warnings we agreed to provide about the use of those protocols.

Please look this over carefully and shoot me down; I'm probably suffering from late-Friday-afternoon muddled thinking.

David