FULL PRODUCT VERSION :
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
RFC-1510 specifies that if a KDC or server receives two authenticators
with the same client and server pair and time stamps of the same
micro-second, the second will be considered as a replay and rejected.

Excerpt from the RFC:

If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned.  If the server name, along with the client name, time and microsecond fields from the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned (Note that the rejection here is restricted to authenticators from the same principal to the same server.

The RFC explicitly mentions microseconds. However we observed that the time in the authenticator has a much lower resolution (in the range of miliseconds) since we experience the KRB_AP_ERR_REPEAT error if we sequentially request two service tickets.

One possible solution is to make sure that the thread requesting the service ticket waits for at least one milisecond before requesting the next ticket so that the authenticator's time stamp differs from the previous one. However this only works if a client has only one process communicating with the same server. If for instance two seperate processes are requesting tickets and performing requests to the same service chances are high that two ticket requests are made in the same milisecond and one of the processes gets the KRB_AP_ERR_REPEAT error.

This behaviour has already been reported in 2003 (Bug ID: 4863290). As in JDK 1.6 we still experience this behaviour we reported a new bug.




STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) create a for loop to request for instance 100 service tickets for a kerberos service. Store the tickets in an array
2) in a second for loop try to validate the tickets

If the corresponding machine is fast enough to create two tickets within a milisecond an replay attack will be detected.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We expect that two or more subsequenltly requested service tickets can be validated even if two or more requests for a service ticket are made in the same milisecond. RFC 1510 states that the authenticator's microsecond field has to be different. This makes sense because two requests within the same microsecond are very unlikely.

REPRODUCIBILITY :
This bug can be reproduced always.