KRB_ERROR Definition

The KRB_ERROR message consists of the following fields:

   KRB-ERROR =  {
             pvno[0]               INTEGER,
             msg-type[1]           INTEGER,
             ctime[2]              KerberosTime OPTIONAL,
             cusec[3]              INTEGER OPTIONAL,
             stime[4]              KerberosTime,
             susec[5]              INTEGER,
             error-code[6]         INTEGER,
             crealm[7]             Realm OPTIONAL,
             cname[8]              PrincipalName OPTIONAL,
             realm[9]              Realm, -- Correct realm
             sname[10]             PrincipalName, --
                                   Correct name
             e-text[11]            GeneralString OPTIONAL,
             e-data[12]            BYTE STRING OPTIONAL
                }

Table 9.13 describes the fields in this message.

If the error-code is KRB_AP_ERR_METHOD, then the e-data field contains an encoding of the following sequence:

METHOD-DATA = {
             method-type[0]   INTEGER,
             method-data[1]   BYTE STRING OPTIONAL
              }

Table 9.14 describes the fields in this option.

Kerberos Workstation Authentication Problem

Requests for Kerberos Ticket Granting Tickets are sent in plaintext to the Kerberos server, which responds with credentials encrypted in the requesting principal’s secret key. The program then attempts to decrypt the data with the supplied password and considers the authentication “successful” if the decryption appears to yield meaningful results, such as the correct principal name.

The problem here is that the requesting program cannot know for sure whether the decryption succeeded or, more importantly, whether the response actually came from the Kerberos server. An attacker could, for example, walk up to an unattended machine and “log in” as a nonexistent user. Kerberos eventually responds with an appropriate error, but the attacker can arrange for another program to deliver a fake response to log in first. He then types the correct password, which he knows because he created the fake response in the first place, and succeeds in spoofing login.

The solution to this problem is for login to verify the Ticket Granting Ticket by using it to acquire a service ticket with a known key and comparing the results. Typically, this means requesting an rcmd.<hostname> ticket, where <hostname> is the local host name, and checking the response against the key stored in the machine’s /etc/srvtab file. If the keys match, the original Ticket Granting Ticket must have come from Kerberos, because the key only exists in the srvtab and the Kerberos database, and login can permit the user to log in.

The solution works only as long as the host has a srvtab containing an rcmd.<hostname>, or any other standard principal entry. This is fine for physically secure or single-user workstations, but does not work on public workstations in which anyone could access the srvtab file.

Kerberos Port Numbers

The file src/prototypes/services.append in the MIT Kerberos distribution contains the commonly used port assignments. This file is not the whole story, however. Kerberos has officially been moved to port 88, although people will have to listen on port 750 for some time to come and assume that many servers won’t be converted to listen to port 88 for some time.

“kerberos_master” and “krb_prop” have not been reserved, but they are used only for intra-site transactions, so having them reserved probably isn’t necessary. Furthermore, both of their port numbers have already been assigned to other services, so requesting an official assignment forces them to change.

eklogin, kpop, and erlogin have not been officially reserved, but probably should be. Their ports currently aren’t assigned to other services, so hopefully they will not have to change if an official assignment is requested.

Kerberos Telnet

An experimental Telnet Authentication Option has been defined, and is described in RFC1416. A separate document, RFC1411, describes how that option is to be used with Kerberos version 4, but no RFC exists for its use with Kerberos version 5. These RFCs define only how authentication must be performed. The standard for full encryption remains under development.

An implementation of Kerberos version 4 telnet is available through anonymous FTP from the following site:

net-dist.mit.edu/pub/telnet/dist/940-407/telnet,95.10.23.tar.Z.

It predates both of the earlier-mentioned RFCs, however, and therefore almost certainly isn’t compliant with them. A Kerberos version 5 telnet implementation, based on the 4.4BSD telnet/telnetd, also exists, but has been temporarily removed from distribution—probably because it also does not comply with the proposed standards.

Kerberos ftpd

The IETF Common Authentication Technology (CAT) Working Group has published the Internet Draft “FTP Security Extensions” <draft-ietf-cat-ftpsec-05.txt>, which defines Kerberos version 4 and GSS-API authentication systems. Source code for a Kerberos version 4 ftp/ftpd with the extensions is available through anonymous FTP from this site:

thumper.bellcore.com:pub/lunt/ftp_ftpd.tar.Z

Other Sources of Information

Plenty of Kerberos-related sources are available on the Internet.

The WWW offers much useful information, but it changes frequently enough that listing sites here would be pointless. The common search engines all list several sites, and most of the sites point to other useful sites.

The main newsgroup is comp.protocols.kerberos.