Photo by pina messina on Unsplash

Photo by pina messina on Unsplash

Pre-authentication for Kerberos services

Tailor-Made

Article from ADMIN 74/2023
By
The Kerberos protocol makes the process of logging in to a service completely transparent to the user. The MIT Kerberos library lets you implement different security requirements for individual services.

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).

Listing 1

Pre-Authentication

### 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.

Listing 2

PKINIT Process

### 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.

Listing 3

FAST Tunnel

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 [...]

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Password management with FreeIPA
    Passwords should be safe, but easy to remember – a contradiction that can be difficult to resolve. One remedy is a password manager that stores all passwords centrally. The open source tip this month shows a different approach: FreeIPA.
  • A REST interface for FreeIPA
    Access to the FreeIPA identity management framework is usually handled via a graphical web interface or a command-line tool, but the framework can also be queried directly via the JSON-RPC API.
  • Protect privileged accounts in AD
    Granular protection for highly privileged accounts is granted by the Protected Users group in Active Directory and Kerberos authentication policies.
  • Integrating FreeIPA with Active Directory
    Many companies use Active Directory for centrally managing existing systems, but if you mix in Linux systems, you have to take care of a few things, such as different forms of integration. We show you how to connect the FreeIPA identity management framework as an interface to an Active Directory domain.
  • Migration from LDAP to FreeIPA
    The change from centralized user authentication on a vanilla LDAP server to the FreeIPA identity management solution is easier than many admins think. Given attention to a few points, the migration takes very little time and effort.
comments powered by Disqus