JDK-8250582 : Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 15
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-07-25
  • Updated: 2022-06-27
  • Resolved: 2020-07-27
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 11 JDK 15 JDK 16 JDK 8 Other
11.0.10-oracleFixed 15.0.1Fixed 16 b08Fixed 8u271Fixed openjdk8u292Fixed
Related Reports
Relates :  
In JDK-8215032 ("Support Kerberos cross-realm referrals (RFC 6806)") we changed the Principal Name type to NT-SRV-HST when requesting TGS Kerberos tickets. This change can be seen in CredentialsUtil::acquireServiceCreds method (sun/security/krb5/internal/CredentialsUtil.java file), which used to contain the line "PrincipalName sname = new PrincipalName(service);" (implicitly meaning an NT-UNKNOWN Service Name Principal) and now creates an instance of PrincipalName with a PrincipalName.KRB_NT_SRV_HST constructor argument.

Even though real-case failures were not noticed as a result of this change, and RFC-4120 - Section 6.2 [1] makes us think that there shouldn't be, we will revert the change to the previous state.

A future enhancement would be to change CredentialsUtil::acquireServiceCreds method signature to receive the Principal Name type by parameter. Krb5Context class, as a method's caller, would need to send the proper value obtained from the Krb5Context::peerName instance.

[1] - https://tools.ietf.org/html/rfc4120#section-6.2
Fix request (8u) I'd like to have this minor fix in 8u. This would contribute to achieve parity between JDKs. Risk is low: the patch was baked enough in newer releases and there is nothing JDK-8 specific in it). Patch applies cleanly, after converting paths to the pre-modules scheme. No regressions observed in the sun/security/krb5 test category.

Fix request (11u) I'd like to request a backport of this bug to 11u, as this release is affected. It'll also be beneficial to align JDKs and improve compatibility. The change is trivial, with low risk. Patch applies cleanly.

URL: https://hg.openjdk.java.net/jdk/jdk/rev/507d2a75af29 User: mbalao Date: 2020-07-27 15:18:33 +0000

Review thread: https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022239.html