Software Engineering Institute

Simon Josefsson has published a paper describing several active man-in-the-middle attacks against the Kerberos Telnet protocol. Kerberos is a trusted third-party authentication protocol that can be used to secure applications that otherwise transmit authentication information in plain text. Kerberos can further be used to establish encrypted communications channels for applications that normally transmit data in plain text. RFC 1510 defines the Kerberos V protocol.

Telnet (RFC 854) transmits data in plain text, including authentication information. Two RFCs describe options to secure Telnet communications: the Telnet Authentication Option (RFC 2941) and the Telnet Data Encryption Option (RFC 2946). Kerberos can be used to provide these options for Telnet, as specified in RFC 1411 (Kerberos IV) and RFC 2942 (Kerberos V).

While establishing a Kerberos Telnet connection, the client and server exchange information about their authentication and encryption preferences. In simplified terms, the client first requests Kerberos authentication and may request data encryption. The server then replies with an ordered list of supported authentication and encryption options. The integrity of this list is not cryptographically protected, and an attacker may be able to modify the list and cause the client to choose less secure authentication or encryption options. For example, a client that requests Telnet data encryption may be directed by an attacker to negotiate a connection with no encryption. In addition, the attacker can intercept warnings from the server that encryption is not enabled. As Josefsson notes, the Telnet Authentication Option specification suggests that the integrity of the data exchanged in the negotiation process may be protected, however neither the Kerberos IV or Kerberos V Telnet protocols implement such behavior. RFC 2941 describes this vulnerability under the Security Implications heading.

An attacker with the ability to modify Kerberos Telnet negotiation commands sent from server to client may be able to cause the connection to negotiate less secure authentication and encryption options, including no encryption. The attacker may then be able to read data that the user presumes to be securely encrypted. This is exacerbated by another vulnerability in KTH Kerberos Telnet clients. When a user requests encryption and the server does not appear to support it, KTH Kerberos Telnet clients continue negotiation and establish a connection with no encryption (VU#390280).

Modify Protocol Specification
The Kerberos Telnet protocol specification could be modified to require cryptographic protection of the negotiation of authentication and encryption options. Such a solution would necessitate changes in current implementations of the protocol.

Enforce Client Encryption Preference

One defense against the attacks described in Josefsson's paper is to strictly enforce the client's preferences and abort the connection if authentication or encryption cannot be negotiated. The following is an excerpt from a man page entry for a BSD-derived telnet command option to enable data encryption:

    -x  Turn on encryption of the data stream.  When this option is turned on,  tel-
        net  will  exit  with  an error if authentication cannot be negotiated or if
        encryption cannot be turned on.

Josefsson references a patch for the KTH Kerberos V (Heimdal) implementation that enforces the client's encryption preference.