Kerberos 1.14 - Java 1.6.0.24 incompatibility

[Richard Basch]

There appears to be a protocol change in Kerberos 1.14 which causes older Java clients issues.

Assuming an environment supports weak encryption and is using des-cbc-crc keys, and a Java app is negotiating multiple encryption types, one scenario which can happen is:

- 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)

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Richard Basch
- 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.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Wang Weijun]

Hi Richard

Have you tried newer JDK? 1.6.0.45 is the latest jdk6u. We had a bug at https://bugs.openjdk.java.net/browse/JDK-6932525 on etypes in AS-REQ and it was fixed in 6u25.

Thanks
Weijun

--
I work on Java SE Kerberos at Oracle.

Post by Richard Basch
There appears to be a protocol change in Kerberos 1.14 which causes older Java clients issues.
- 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)
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev