Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Jeff,

Do you have something in mind for how we could leverage network-level controls here?  With respect to security, I believe most campus networks are more open than what is typically thought of as internal/controlled.

David

On Mon, 2013-05-20 at 16:25 +0000, Capehart,Jeffrey D wrote:

We should probably consider some of the assumptions in NIST SP 800-63 and apply those assumptions to Bronze and Silver.  For example, authentications over the internal network for AD-DS probably use the internal (controlled) network, whereas Federated Shibboleth and SAML 2.0 authentications and assertions would be more likely to use the external network. 

 

“The guidelines in this document assume the authentication and transaction take place across an open network such as the Internet. In cases where the authentication and transaction take place over a controlled network, agencies may take these security controls into account as part of their risk assessment.”

 

How to take those security controls into account is a question we should probably consider.

 

More assumptions from SP800-63:

 

•                     A trusted entity is considered to be implemented appropriately if it complies with the recommendations in this document and does not behave maliciously.

•                     While it is generally assumed that trusted entities will not behave maliciously, this document does contain some recommendations to reduce and isolate any damage done by a malicious or negligent trusted entity.

 

Assumptions about the NETWORK:

An open communications medium, typically the Internet, that is used to transport messages between the Claimant and other parties. Unless otherwise stated, no assumptions are made about the security of the network; it is assumed to be open and subject to active (i.e., impersonation, man-in-the-middle, session hijacking) and passive (i.e., eavesdropping) attack at any point between the parties (e.g., Claimant, Verifier, CSP or RP).

 

See also SP800-63 section 8.2.2. Threat Mitigation Strategies

 

•                     Eavesdropping resistance

•                     Replay resistance

•                     Hijacking resistance

•                     Man-in-the-middle resistance

 

Jeff

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Monday, May 20, 2013 11:43 AM
To: InCommon AD Assurance Group
Subject: RE: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC

 

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