Skip to Content.
Sympa Menu

ad-assurance - RE: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

RE: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC


Chronological Thread 
  • From: "Michael W. Brogan" <>
  • To: "" <>
  • Subject: RE: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC
  • Date: Mon, 20 May 2013 20:14:41 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none

Right. That is the interpretation we came to early on.

 

--Michael

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, May 20, 2013 9:45 AM
To:
Subject: RE: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC

 

I think this is because the IdP isn’t AD DS, just the verifier, and so communication between IDP and Subject is not AD specific.

 

It does imply some specific requirements that apply to this section (as we understand Protected Channels better), just nothing that’s specific to AD.

 

--- Eric

 

From: [] On Behalf Of David Walker
Sent: Monday, May 20, 2013 9:26 AM
To:
Cc: DHW
Subject: Re: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC

 

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: [] 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

 

 




Archive powered by MHonArc 2.6.16.

Top of Page