Max,
Changes look fine to me.
Thanks,
Valerie
On 06/01/10 01:33, Weijun Wang wrote:
Hi All
Please review this webrev:
http://cr.openjdk.java.net/~weijun/6844907/webrev.00/
Three notes:
1. The etype order change has effect on keys in a keytab file. In KeyTab.java,
I've made the following change:
public EncryptionKey[] readServiceKeys(PrincipalName service) {
....
- if (etypes != null && etypes != EType.getBuiltInDefaults()) {
+ if (etypes != null) {
Here, readServiceKeys() sorts the keys using the etype order. This sorting was only
performed when "default_tkt_enctypes" is explicitly defined, since the keys
inside the keytab file was already ordered at creation time. After this fix, a keytab
created earlier has a different etype order from the current defined, therefore, the
re-ordering is always performed.
2. Several methods are removed, since they are never called anywhere. Currently
the acceptor side also uses JAAS Krb5LoginModule and read keys from keytab in
the login process. (Of course, most likely a communication-less login when
isInitiator=false).
3. After this fix, the regression test SSL.java fails. I've filed another bug
on it. Will try to fix both bugs in a single push.
6946669: EncryptedData.reset(data, false) implementation error
Thanks
Max
Begin forwarded message:
*Change Request ID*: 6844907
*Synopsis*: krb5 etype order should be from strong to weak
=== *Description* ============================================================
In RFC 4120, 5.4.1:
KDC-REQ-BODY ::= SEQUENCE {
....
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
....
}
In the current impl, the etype list starts with DES and ends with AES. We
should probably reverse this order by putting stronger cryptos at the beginning.