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.
