Kerberos 1.14 - Java 1.6.0.24 incompatibility

[Greg Hudson]

On 12/12/2015 11:40 AM, Richard Basch wrote:
> - Java negotiates des-cbc-md5 and des-cbc-crc
> - KDC responds with support for both
> - Java actually makes request with type 3 (des-cbc-md5)
> - KDC now responds with BAD_ENCRYPTION_TYPE if the principal is defined as type 1 (des-cbc-crc).
> 
> Previous behavior in 1.13 and prior: KDC would issue ticket (skey=3, tkt=1)

I need a more precise description of the scenario.

* "Java negotiates des-cbc-md5 and des-cbc-crc": I assume this means the
client sends an unauthenticated AS-REQ with an etype sequence containing
3 and 1 in that order.

* "KDC responds with support for both": I assume you are talking about
ETYPE-INFO and/or ETYPE-INFO2 in the METHOD-DATA of a
KDC_ERR_PREAUTH_REQUIRED error.  This statement does not track, because
1.14 only ever creates a single ETYPE-INFO entry.  So:

  - Precisely what ETYPE-INFO and ETYPE-INFO2 are in the
PREAUTH_REQUIRED error generated by the 1.14 KDC?
  - What ETYPE-INFO and ETYPE-INFO2 are in the error generated by the
1.13 KDC?

* "Java actually makes request with type 3 (des-cbc-md5)": I assume this
is talking about an AS-REQ with a PA-ENC-TIMESTAMP padata entry,
encrypted in the des-cbc-md5 key corresponding to the password.  What
etype sequence is in this request?  {3 1} or just {3}?  In the 1.13
scenario, is des-cbc-md5 used for this step or is des-cbc-crc used?

* "Previous behavior in 1.13 and prior: KDC would issue ticket (skey=3,
tkt=1)": Do you have any local modifications to the 1.13 KDC to allow
des-cbc-md5 to be selected as the session key enctype, or a
session-enctypes string attribute on the server principal?  For a long
time, we have generally treated servers as not supporting des-cbc-md5 as
a session enctype, due to a historical interoperability issue.