Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

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