JDK-8201814 : Kerberos sequence number issues
  • Type: CSR
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-04-18
  • Updated: 2018-05-19
  • Resolved: 2018-05-19
Related Reports
CSR :  
Description
Summary
-------

Introduce a system property to determine how to choose the initial sequence number if the acceptor has not sent one during a non-mutual Kerberos 5 authentication.

Problem
-------

According to [RFC 4121](https://tools.ietf.org/html/rfc4121#section-4.1.1), during the Kerberos 5 security context establishment, the initiator (client) and the acceptor (server) will inform each other a sequence number. After the security context is established, each side would include (and increment) its own sequence number when sending a message, so that the peer can detect if the message is out of order.
 
The security context establishment involves 2 messages: AP-REQ from initiator to acceptor, and AP-REP backwards.
 
If non-mutual authentication is requested (by default, authentication is mutual), there will be no AP-REP, i.e. no channel to transmit the acceptor's initial sequence number.
 
MIT krb5 and Microsoft assume it's the same as the initiator's initial sequence number. Heimdal (another popular krb5 implementation which is shipped with macOS) assumes 0. So they do not interop with each other. This can be observed with a simple test.
 
Java used the initiator's initial sequence number on its acceptor side, but assumes it's zero on its initiator side. Thus it can interop with neither correctly. It even cannot interop with itself. See compatibility risk below to find out why this hasn't been a disaster.

Solution
--------

Introduce a system property to choose which assumption to make.

Specification
-------------

This is not a Java SE interface.
 
When mutual auth is not requested by the Kerberos 5 initiator, there is no way to negotiate acceptor's initial sequence number. In this case, if the system property "sun.security.krb5.acceptor.sequence.number.nonmutual" is set to "initiator", both initiator and acceptor assume the acceptor's initial sequence number is the same as the one from initiator. If set to "zero" or "0", both assume it to be 0. The default value is "initiator". All other values are illegal and will trigger an error when the system property is read. 

The system property will be documented in https://wiki.se.oracle.com/display/~rgallard/JDK+Security+Admin+Guide+-+Notes and we are considering adding it (along with some other useful ones from the wiki page) to the next version of https://docs.oracle.com/javase/10/security/kerberos-5-gss-api-mechanism.htm.
Comments
Approving continent on documenting the property.
19-05-2018

Please update the request to include any additional updates to other spec and docs and then Propose or Finalize the request to get CSR review.
14-05-2018

A few comments and questions: Are there already sun.security.krb5.* properties to justify using the sun.* prefix rather than jdk.*? Should this change have a release note? Where will it be documented how to set this property to interact with different Kerberos implementations? Procedurally pending this request until these issues are sorted out.
02-05-2018