To make it clearer, I would like to have a brief comment about the
unkeyed checksum checking as you cited of section 6.1 of RFC 3961,
probably in Checksum.verifyAnyChecksum() or/and CksumType.verifyChecksum().
Checksum.verifyAnyChecksum():
191 if (!cksumEngine.isSafe())
192 throw new KrbApErrException(Krb5.KRB_AP_ERR_INAPP_CKSUM);
204 if (!cksumEngine.isSafe()) {
205 return cksumEngine.verifyChecksum(data, checksum);
CksumType.java:
159 public boolean verifyChecksum(byte[] data, byte[] checksum)
160 throws KrbCryptoException {
161 throw new UnsupportedOperationException("Not supported");
162 }
I was wondering, if a CksumType object is not safe (!isSafe()) and does
not implement the verifyChecksum() method, an USPOE will be thrown. For
example, I'm not sure if Crc32CksumType.verifyChecksum() could be called
or not in practice. Is it better to have CksumType.verifyChecksum()
returns 'false'?
Otherwise, looks good to me. Need no more code review from me if you
have a good reason to keep it as-is, or take the comments above.
Xuelei
On 7/2/2019 6:34 PM, Weijun Wang wrote:
More justification from https://tools.ietf.org/html/rfc3961#section-6.1:
6.1. Unkeyed Checksums
These checksum types use no encryption keys and thus can be used in
combination with any encryption type, but they may only be used with
caution, in limited circumstances where the lack of a key does not
provide a window for an attack, preferably as part of an encrypted
message [6]. Keyed checksum algorithms are recommended.
Here the PA_REQ_ENC_PA_REP is a part of an encrypted message EncKDCRepPart.
Thanks,
Max
On Jul 2, 2019, at 11:13 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8226719/webrev.00/
This happens when authenticating to a Windows 2000 Server using DES encryption
type. The PA_REQ_ENC_PA_REP in the reply is using RsaMd5CksumType but it is
treated unsafe and rejected.
Here, unsafe means un-keyed. While it's unsafe to use it as a standalone
checksum but in this case the PA_REQ_ENC_PA_REP is embedded inside
EncKDCRepPart which is already encrypted. Therefore an attacker will not be
able to modify it without knowing the key. (Please note that when a keyed
checksum is used, the key is exactly the same as the one used to encrypt the
EncKDCRepPart field).
This fix added a new method verifyAnyChecksum() that can verify both a keyed
and an un-keyed checksum. The method is currently only used by the
PA_REQ_ENC_PA_REP verification.
Noreg-hard. Only reproducible when accessing a Windows 2000 Server, which is
exactly how our internal SQE test caught it.
Thanks,
Max