JDK-6882687 : KerberosTime too imprecise
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 6u26,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2009-09-16
  • Updated: 2012-07-23
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b97Fixed
Related Reports
Duplicate :  
JDK-7085018 - Kerberos replay attack detection due to low JDK clock resolution
Duplicate :  
JDK-6950930 - test failure windows sun/security/krb5/auto/IgnoreChannelBinding.java
Relates :  
JDK-2217345 - KerberosTime does not take into account system clock adjustement
Relates :  
JDK-7077172 - KerberosTime does not take into account system clock adjustement
Description
Recently I notice a Kerberos test fails on CYGWIN saying an AP-REQ is a "replay detected". It turns out that the Windows time (returned by new Date()) is too coarse (15 millisecond precision) and the two AP-REQs in the test have the same KerberosTime value.

Also, the KerberosTime class is the source of microseconds value used in Authenticator etc. Since Date only provides milliseconds, this means even if on a system with ideal Date, the microsecond value is always a multiple of 1000.
Comments
EVALUATION Now using System.nanotime() to record the time.
24-05-2010
EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff9cc9789bb3
24-05-2010