-
Enhancement
-
Resolution: Not an Issue
-
P4
-
None
-
7u80
-
x86_64
-
linux_suse_sles_11
A DESCRIPTION OF THE REQUEST :
For the future JDKs, we would like to have a new feature in Kerberos v5 implementation. At the creation of KRP_AP_REQ, the client generates a random sequence number which is also part of the RFC4120 (see https://datatracker.ietf.org/doc/rfc4120/?include_text=1 --Section 3.2.2), but this field is not used to compare authenticators in the replay cache in case a same time-stamp is received before. We are suffering false positive replay detections.
We have created a severity 3 service-request on support.oracle: SR 3-12168794711 but unfortunately we were directed to here (http://bugs.java.com/)
JUSTIFICATION :
This enhancement will resolve the false positive replay detections.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If the same time-stamp is in the cache, check and verify the sequnce-number on the receiving end, in case that sequence-number is also in the cache, then the krb_ap_req can be discarded as a replay.
CUSTOMER SUBMITTED WORKAROUND :
In the application code, thread spawning is done with 1 millisecond pauses to get a different time-stamp for each request.
For the future JDKs, we would like to have a new feature in Kerberos v5 implementation. At the creation of KRP_AP_REQ, the client generates a random sequence number which is also part of the RFC4120 (see https://datatracker.ietf.org/doc/rfc4120/?include_text=1 --Section 3.2.2), but this field is not used to compare authenticators in the replay cache in case a same time-stamp is received before. We are suffering false positive replay detections.
We have created a severity 3 service-request on support.oracle: SR 3-12168794711 but unfortunately we were directed to here (http://bugs.java.com/)
JUSTIFICATION :
This enhancement will resolve the false positive replay detections.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If the same time-stamp is in the cache, check and verify the sequnce-number on the receiving end, in case that sequence-number is also in the cache, then the krb_ap_req can be discarded as a replay.
CUSTOMER SUBMITTED WORKAROUND :
In the application code, thread spawning is done with 1 millisecond pauses to get a different time-stamp for each request.