Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

I failed to complete my action item of consulting with David on “long term” vs “short term” authentication secrets. I will note that the IAP uses the term “plain text passwords” or “passwords” and not 800-63’s more general “authentication secrets”, which seems to support David’s argument that NTLMv2 and non-armored Kerberos meet the IAP “as is” for purposes of this portion of 4.2.3.5.2 (Basic Protection of Authentication Secret (B)), 4.2.3.6.1b/2 (Strong Protection of Authentication Secrets (S)).

Well, I was in Hawaii, so I would have been hard to track down...

Personally, I wouldn't consider a challenge or response as a secret.  The secret in this form of authentication is the encryption key used to create the response from the challenge.  Generally, I would assume that public key encryption would be used, so the only "secret" would be the private key that (in theory) would never leave the control of the user.  The 800-82 document that Jeff referenced, though, implies a shared symmetric key (perhaps common practice for industrial control systems?), which would have many of the same risks as passwords, although still not transmitted during authentication.

David

On Thu, 2013-05-30 at 23:42 +0000, Eric Goodman wrote:

AD Cookbook edits

 

Despite starting my editing process at least an hour earlier than on previous weeks, my edits are barely complete before CoB for those of us on the west coast.

 

The edits were rather small at this point, but I hope they address the most recent round of comments.

 

I still haven’t done anything to the appendices.

 

Other AIs

 

I failed to complete my action item of consulting with David on “long term” vs “short term” authentication secrets. I will note that the IAP uses the term “plain text passwords” or “passwords” and not 800-63’s more general “authentication secrets”, which seems to support David’s argument that NTLMv2 and non-armored Kerberos meet the IAP “as is” for purposes of this portion of 4.2.3.5.2 (Basic Protection of Authentication Secret (B)), 4.2.3.6.1b/2 (Strong Protection of Authentication Secrets (S)).

 

However, given my failing to consult with David, I didn’t update the cookbook to reflect David’s response to my questions.

 

Kerberos Timeskew

 

According to RFC 4430 (http://tools.ietf.org/html/rfc4430), timeskew is a simple difference in clocks (i.e., ABS(time1-time2)). There is other interesting (but largely irrelevant to the “replay attack” issue) information about how clockskew will not necessarily cause logins to fail (see http://blogs.technet.com/b/askds/archive/2012/08/24/friday-i-mean-saturday-mail-sack-very-wordy-edition.aspx) but nothing that disagrees with the basic definition of how skew is calculated.

 

Unfortunately, learning this information didn’t really help in terms of understanding what our group recommendation is (assuming we have one) for how skew should be configured before we think a service should be considered to meet Silver requirements.

 

--- Eric

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Friday, May 24, 2013 10:37 AM
To:
Subject: [AD-Assurance] Notes from the May 24 AD Assurance call

 

Notes are online in the usual place. Action Items for Ron, Eric, Mark and to some extent David.

 

https://spaces.internet2.edu/display/InCAssurance/May+24%2C+2013

 

--- Eric