Kerberos Telnet computes the DES keys incorrectly when there is more then 8 bytes of key data. The fundamental problem is that the keys must be inserted into the encryption engine before the engine knows which type of encryption is going to be used. You can add support for 3DES or CAST-128 encryption provided you are willing to compile out the support for DES support. This of course disables compatibility with existing clients.

Jeffrey Altman

Markus Moeller wrote:
Jeffrey

Markus:

Your patch is close to the correct way to do this.  The primary issue is
the question of the encryption key to use.  You want to use the 3DES
session key if it is available.

However, there is a bigger problem.  The existing Kerberos 5 telnet code
base always takes the first 8 bytes of the key regardless of length and
uses it for both the inbound and outbound keys.


I thought with the changes I did in kerberos5.c I will use a longer session
key (.e.g. 16 for RC4-hmac).
I have to look at the inbound and outbound key generation.


This is in violation of
the current Telnet Encryption draft.  That is why there is a restriction
for Kerberos 5 that it can only use single DES session keys.  If a
session key with greater than 8 bytes of key data were used, the
truncation applied in the current code would make the communication
between the client and server incompatible if single DES were ever
negotiated.



I tested that I can use DES for kerberos 5 with DES-CBC-MD5 keys and 3DES
for kerberos 5 with RC4-hmac keys.
(at least the debug output told me so)


- Jeffrey Altman




Thank you
Markus


________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos


________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to