Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

David,

 

Probably the leverage depends on the specific network level control.  I’ll list some general ideas and then it would be up to each institution to identify how they meet or exceed, as compared with the standard.

 

Protected Channel (between IdMS system components):

   Meets: IPSec with an approved algorithm, between IdMS system components

   Meets: SSL/TLS tunnel with Approved Algorithm

   ?? SSL/TLS tunnel with strong encryption but not Approved Algorithm (i.e. RC4 128-bit)

   ?? VLAN over routers that are part of the campus network (internal network)

   ?? Isolated routers with no other outside network connections (internal network)

   ?? Firewall/router rules limiting network access to only internal addresses (internal network)

  ?? NAC – network access controls require authentication prior to allowing access

 

Some controls that might help “protect” a server with a credential store that doesn’t meet the specs:

 

  Intrusion Detection System - identify if credential store system has been compromised (then quickly take action to remediate?)

  Administrative Controls

-          Are remote logins allowed or is console-only access allowed?

-          Do administrators read email or web surf on domain controllers?

-          Is anti-virus software installed and up-todate?

-          Do administrator accounts require much stronger password policy, like 15+ characters?

-          Are servers in a tightly physical-access controlled location with keycard+PIN access and recorded video monitoring?

-          Do servers have alarms/monitoring for unexpected removal or service interruption?

 

 

Can anyone else think of some comparable or compensating controls that collectively may be worth consideration for alternative means on an otherwise difficult requirement to meet to the letter?

 

Jeff

 

From: [mailto:] On Behalf Of David Walker
Sent: Monday, May 20, 2013 12:43 PM
To:
Subject: Re: [AD-Assurance] NTLMv2 and Kerberos with RC4-HMAC

 

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