JDK-8168518 : rcache interop with krb5-1.15
- Type: Bug
- Component: security-libs
- Sub-Component: org.ietf.jgss:krb5
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2016-10-24
- Updated: 2024-04-02
- Resolved: 2016-11-03
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.
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 9 | Other |
|---|---|
9 b143Fixed  |
openjdk8u412Fixed |
Related Reports
|
Relates :
|
Sub Tasks
|
JDK-8168635 :
|
Description
Java's DFL-style rcache uses MD5 hash, which is the same as krb5-1.14 and earlier. krb5-1.15 uses SHA256. If the same AP-REQ is sent to krb5-1.15 first (which creates a new rcache entry) and then sent to a Java acceptor, Java cannot find a match in the rcache file and accepts it. Precisely, Java sees 2 entries there: 1st with SHA-256, 2nd the bare one. Java compares them to its own calculation and finds out 1) match the bare one 2) does not match the SHA-256 one, it then concludes the AP-REQ is a different one although sent at the same time. Two solutions: 1) understand the SHA-256 entry and treat it as a match. 2) discard the SHA-256 entry and treat the bare one as a match.
Comments
|