Package: krb5
Version: 1.4.4-7etch2
Severity: important

Hi,
I found some rather major bugs with the enctype handling in MIT Kerberos
1.4.4-7etch2 at least.

1)
We have a principal with the following keys:
> Key: vno 3, DES cbc mode with RSA-MD5, no salt
> Key: vno 3, Triple DES cbc mode raw, no salt

or

> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 1, DES cbc mode raw, no salt

Whenever preauth is activated for this principal AS_REQ always fails with the 
error below
> Aug 28 09:59:44 XXX krb5kdc[30626]: AS_REQ (7 etypes {18 17 16 23 1 3 2}) 
> xxx.xxx.xxx: NEEDED_PREAUTH: [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED], 
> Additional pre-authentication required 
> Aug 28 09:59:45 XXX krb5kdc[30626]: preauth (timestamp) verify failure: No 
> matching key in entry having a permitted enctype

Changing the order of those two keys fixes this, if the last key is not
in mode raw it works as expected. Also removing the raw keys fixes it.

When using an AES key and some raw key it always works, no matter what the
order is.


2)
Another problem with preauth and a Windows client is the following. We have a 
principal with the keys below:
> Key: vno 34, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 34, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 34, ArcFour with HMAC/md5, no salt
> Attributes: REQUIRES_PRE_AUTH

When trying an AS_REQ this fails with the following:
> Aug 23 12:11:05 XXX krb5kdc[1680]: AS_REQ (7 etypes {23 -133 -128 3 1 24 
> -135}) xxx.xxx.xxx.xxx: NEEDED_PREAUTH: [EMAIL PROTECTED] for krbtgt/[EMAIL 
> PROTECTED], Additional pre-authentication required
> Aug 23 12:11:05 XXX krb5kdc[1680]: AS_REQ (1 etypes {23}) xxx.xxx.xxx.xxx: 
> BAD_ENCRYPTION_TYPE: [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED], KDC has 
> no support for encryption type

i.e. the KDC thinks it doesn't support 23 (aka RC4-HMAC-MD5) although it in 
reality does.
Changing the keys to the following fixes the problem.

> Key: vno 35, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 35, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 35, ArcFour with HMAC/md5, no salt
> Key: vno 35, DES cbc mode with CRC-32, no salt
> Attributes: REQUIRES_PRE_AUTH

> Aug 23 14:16:20 XXX krb5kdc[1680]: AS_REQ (7 etypes {23 -133 -128 3 1 24 
> -135}) xxx.xxx.xxx: NEEDED_PREAUTH: [EMAIL PROTECTED] for krbtgt/[EMAIL 
> PROTECTED], Additional pre-authentication required
> Aug 23 14:16:20 XXX krb5kdc[1680]: AS_REQ (3 etypes {23 3 1}) 
> xxx.xxx.xxx.xxx: ISSUE: authtime 1187871380, etypes {rep=23 tkt=3 ses=1}, 
> [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED]

And as one can see (rep=23) the KDC even uses the enctype it said it doesn't 
support
at all before.



3)
When creating a new principal and specifying almost the same enctype twice with
only a difference in the hash used only the first one is created:

addprinc -policy user -e "des-cbc-md5:normal des-cbc-crc:normal" test
getprinc test
> Number of keys: 1
> Key: vno 1, DES cbc mode with RSA-MD5, no salt


addprinc -policy user -e "des-cbc-crc:normal des-cbc-md5:normal" test
getprinc test
> Number of keys: 1
> Key: vno 1, DES cbc mode with CRC-32, no salt


addprinc -policy user -e "des-cbc-crc:normal des-cbc-md5:normal des-cbc-md5:v4" 
test
getprinc test
> Number of keys: 2
> Key: vno 1, DES cbc mode with CRC-32, no salt
> Key: vno 1, DES cbc mode with RSA-MD5, Version 4


Changing another component of the enctype will make both created, only a 
difference
in the hash will only create the first one specified.


Bye



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to