When a user is validated by the Kerberos authentication protocol through a key distribution center (KDC), the user is given a ticket granting ticket (TGT) at the end of the process that then enables transparent login to more Kerberos services. Before this can happen, however, the user must initially prove their identity to the KDC. This process is also known as pre-authentication and provides protection against attackers who send an arbitrary request to the server and then go on to use a dictionary or brute-force attack to try to guess the user password.

This attack would be possible without pre-authentication because, in such a case, the KDC would simply send data to the client encoded with a key derived from the user password. Attackers would then have plenty of time to carry out an offline attack, ultimately to extract the user password.

Password First

To prevent such an attack, all current Kerberos implementations require pre-authentication. When a client initiates a login to a KDC, the connection is first interrupted, and the server asks the client to authenticate. In the simplest case, the user simply has to enter their password; then, a key (long-term key) is derived from the password used to encode a timestamp. The timestamp is then transmitted to the KDC to authenticate the user. If this works, the user is also given a TGT. This method is described in the initial Kerberos RFC [1], as well, which means that it is supported by all Kerberos implementations (Listing 1).

### A trace from kinit shows the selected pre-authentication method.
# KRB5_TRACE=/dev/stdout kinit tscherf
[20981] 1655644410.292205: Received error from KDC: -1765328359/Additional pre-authentication required
[20981] 1655644410.292208: Preauthenticating using KDC method data
[20981] 1655644410.292209: Processing preauth types: PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2), PA-FX-COOKIE (133)
[...]
[20981] 1655644412.754459: Preauth module encrypted_timestamp (2) (real) returned: 0/Success

However, this approach has the disadvantage that attackers might still be able to obtain data encoded with a user key. A dictionary or brute force attack would still be possible in this case.

Protection Against Password Attacks

Fortunately, other pre-authentication methods exist. For example, RFC 4556 defines the PKINIT (public key cryptography for initial authentication) [2] procedure, which relies on a public and a private key. The public key is part of an X.509 certificate signed by a certificate authority (Listing 2). In this example, the private key is stored in a PEM file along with the certificate, but it can also be on a smart card if required.

### Using PKINIT, the user proves their identity with the help of a certificate....
# KRB5_TRACE=/dev/stdout kinit -X X509_user_identity='FILE:/home/tscherf/ tscherf.pem' tscherf
[107503] 1655649304.486966: Received error from KDC: -1765328359/Additional pre-authentication required
[107503] 1655649304.486969: Preauthenticating using KDC method data
[107503] 1655649304.486970: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[...]
[107503] 1655649304.486973: Preauth module pkinit (147) (info) returned: 0/Success

Anonymous PKINIT and FAST

Interestingly, the KDC can issue a TGT for a user, but the ticket is not tied to the identity of the user. This setup is useful when you want to set up an encrypted tunnel between the client and the KDC. Users can then communicate securely with the KDC through this tunnel without potential attackers having access to the transmitted data.

The encrypted tunnel is particularly helpful for multifactor authentication (MFA), where another factor, such as a one-time password (OTP), is transmitted in plain text in addition to the user password. RFC 6113 [3] defines the flexible authentication secure tunneling (FAST) pre-authentication method for this approach.

For practical use, you first need to call kinit with the -n option to give you an anonymous TGT:

kinit -n
klist
Ticket cache: KCM:0
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[...]

You can now use this ticket to open a secure tunnel between the client and the KDC (Listing 3). After the tunnel has been set up, the user authentication can take place by way of an arbitrary pre-authentication method.

01 ### You can create a secure tunnel using FAST.
02 # ARMOR_CCACHE=$(klist|grep cache:|cut -d' ' -f3-)
03 # KRB5_TRACE=/dev/stdout kinit -T $ARMOR_CCACHE tscherf
04 Password for tscherf@EXAMPLE.COM
05 [108350] 1655651317.859136: FAST armor ccache: KCM:0:45797
06 [108350] 1655651317.859139: Using FAST due to armor ccache negotiation result
07 [...]