Meeting the InCommon Assurance profile criteria using Active Directory

["Rank, Mark" <>]

Eric:

I would support this analysis. I do feel there is some merit in the suggestion of explicitly recommending deliver defaults not be exceeded since the risk does exist. 

For me 4.2.5.1 boils down to how "impractical" is defined. Since there is no definition in glossaries of the IAAF, NIST 800-63 or NIST 800-53, falling back to the "industry standard" as a cap seems like a reasonable way to make it concrete for implementers.

Thoughts?

Mark

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------

---

From: [] on behalf of Eric Goodman []
Sent: Friday, May 31, 2013 12:15 PM
To:
Subject: [AD-Assurance] Kerberos Time Skew

One of the topics on today’s call was around the Replay Attack Prevention section of the AD cookbook. The language from the cookbook (which is still in the updated version) has a discussion of Kerberos time skew and references two technical documents that talk about Kerberos time skew, but there is no actual recommendation provided. Even the management assertion that follows the links does not make any reference to the Kerberos time skew (instead it references the replay cache and account lockout settings).

 

So the question on the call was whether we should add a specific recommendation for time skew, and if not, what we should do with that language.

 

Reading the whitepaper from the original doc (note the URL is different from the one in the cookbook, which appears to be broken):

 

http://csis.bits-pilani.ac.in/faculty/sundarb/courses/old/spr06/netsec/evals/project/projrefs/kerb/AIWSC03_kerberos_replay_attacks.pdf

The authenticator timestamp only enforces a maximum time skew of a few minutes. In practice, this will not be of any help. An attacker will be able to mount the attack within seconds of recovering the KRB_AP_REQ. If the maximum time skew is configured to be too small, the nodes will face problems with time synchronization.

 

The paper goes on to identify other mechanisms that would mitigate this risk (such as the use of a replay cache, as stated in the cookbook), but states that in no case will a time skew limit by itself limit the ability of credentials to be used in a replay attack; it simply limits the window of time the attacker has to execute such an attack.

 

From this, my conclusion is that we do not have any specific configuration recommendations/requirements for time skew settings (at least not related to preventing replay attacks), and the background information on time skew could be moved to a “background information” section or document, but should not remain in the configuration section. Keeping the management assertion language in the document makes sense, however, since the replay cache is really the built in Windows defense against replay attacks.

 

--- Eric