Skip Menu |
 

Subject: Krb5 Telnet[d] improperly truncates 3DES keys to DES key
Cc: kenh@cmf.nrl.navy.mil
Download (untitled) / with headers
text/plain 1.2KiB
The Krb5 Telnet[d] code accepts 3DES session keys but truncates all but
the first 8 bytes in order to produce a single DES key which is used for
both the inbound and outbound streams. This is incompatible with RFC 2952.

"As noted in the telnet ENCRYPTION option specifications, a keyid
value of zero indicates the default encryption key, as might be
derived from the telnet AUTHENTICATION option. If the default
encryption key negotiated as a result of the telnet AUTHENTICATION
option contains less than 8 bytes, then the DES_CFB64 option must not
be offered or used as a valid telnet encryption option. If the
encryption key negotiated as a result of the telnet AUTHENTICATION
option is greater than 16 bytes the first 8 bytes of the key should
be used as keyid 0 for data sent from the telnet client to the telnet
server, and the second 8 bytes of the key should be used as keyid 0
for data sent by the telnet server to the telnet client. Otherwise,
the first 8 bytes of the encryption key is used as keyid zero for the
telnet ENCRYPTION option in both directions (with the client as WILL
ENCRYPT and the server as WILL ENCRYPT)."

I do not have any idea how to fix this in a way which can be backward
compatible with existing deployed clients.
In conversations with Ken H., it appears that NRL's implementation of
ENCRYPT 3DES-CFB-64 does not follow the rules of RFC 2947. This means
that any combination of AUTH KRB5 with ENCRYPT other than single DES
session keys is simply a lost cause.

It appears the only solution is to replace the AUTH KRB5 mechanism with
a new AUTH KRB5_ENCRYPT option which negotiates KRB5; closes the attack
against the unprotected AUTH USER message; and automatically turns on
encryption using the provided session key.