JDK-6388659 : krb5 shouldn't use an empty salt field in KRB_ERROR
- Type: Bug
- Component: security-libs
- Sub-Component: org.ietf.jgss:krb5
- Affected Version: 6
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: solaris_10
- CPU: sparc
- Submitted: 2006-02-22
- Updated: 2010-11-04
- Resolved: 2006-03-23
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.
| Other | JDK 6 |
|---|---|
| 1.4.2_14Fixed | 6 b78Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
The salt field in the KRB-ERROR 25 (precisely, the salt in PA-ETYPE-INFO/2 as the edata field inside KRB-ERROR) is used by the server to suggest the correct salt. However, when connecting to a Windows Server with an encryption type the server does not support (like AES-128) it can be an empty string(""). When trying to renegotiate with the server, current Java code will use the empty string as the new salt and throws an Exception.
When the user does not explicitly specify encryption type in krb5.conf and try to connect to a Windows Server, this bug always shows.
Comments
|