Kerberos is the protocol most used in modern authentication system. Active Directory and other Identity management (like freeipa) use it for offer a single sign-on authentication method. Of course a good kerberos understanding is necessary by system administrator.

Give an answer to this need is the scope of this article.

All the examples have been implemented in an freeipa based laboratory: a free Identity Management with a kerberos key Distribution center (KDC) easy to install and configure. No hard job to do for creating kerberos environment.

The reference architecture:

For creating the laboratory installing following software:

1. Freeipa Server: http://www.freeipa.org/page/Quick_Start_Guide#Static_Hostname.
2. Freeipa Client: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html.
3. Web Server: this is a linux system with apache installed. The apache permits the access to its directory only by kerberos authentication.  Virtual host configured:

root@webserver:~#vi /etc/httpd/ conf.d/webserver.example.com.conf
<VirtualHost *:80>
ServerName webserver.example.com
DocumentRoot /var/www/html/example
<Directory /var/www/html/example>
# Make sure you’re using HTTPS, or anyone can read your Kerberos password.
AuthType Kerberos
AuthName “Kerberos Login”
KrbMethodK5Passwd On
KrbAuthRealms EXAMPLE.COM
KrbMethodNegotiate on
KrbVerifyKDC on
KrbSaveCredentials on
KrbServiceName HTTP/webserver.example.com@EXAMPLE.COM
Krb5KeyTab /etc/httpd/ conf.d/http.keytab
require valid-user
</Directory>
</VirtualHost>

All the kerberos transactions involved during the authentication process to above apache resource will be commented using Wireshark.

Before starting to analyze the first two kerberos packets, AS_REQ and AS_REP, I would like to show for better understanding of this article the diagram sequence scenario with all the messages involved in the authentication process used as test.

Let’s start now.

Kerberos Protocol: AS_REQ and AS_REP

Every service in kerberos protocol has a principal name of this form: name/domain@REALM. In our case the domain and the real are equal to EXAMPLE.COM.

The REALM is the name of company container that contains different domains. Every organization unit can be associated to an domain.

In our example there is a REALM with one only domain company. Generally every company has one only REALM with different domains. Every realm can be trusted with other REALM even if they come from windows world.

A ticket must be released for accessing to a service. There is a special service principal called krbtgt/domain@REALM (Ticket Granting Ticket): who has this has passed successfully the login phase.

The TGT, encrypted by KDC key, is issued transparently to client by authentication service (AS) exchange with the kerberos server.

The AS exchange has the scope to obtain authentication credentials for accessing to some service. The client asks to KDC a Ticket Granting Ticket and a session key to be subsequently used to obtain credentials for other services: in our example for accessing to web service with principal name HTTP/webserver.example.com@EXAMPLE.COM.

The authentication philosophy is that: first the ticket granting ticket, next the service ticket.

The AS exchange consists of two messages: AS_REQ from the client to Kerberos, and AS_REP or  in reply. The most important fields in AS_REQ are:

realm:  realm part of the client’s principal identifier. In our case is EXAMPLE.COM. The Realm is the unique name of the organization unit.

sname: It’s the service name: it’s the principal associated to the service for that the ticket is being asked. In the AS_REQ is equal to is krbtgt/EXAMPLE.COM@EXAMPLE.COM. KRBTGT is a reserved named used to ask the Ticket Granting Ticket (TGT): who owns this ticket is a regular user who verified to know the password and he can ask next a service.

cname: It’s the principal client that asks to KDC the TGT. In our case is admin.

The KDC answers to first AS_REQ  with a  PREAUTH_REQUIRED: this is to avoid DOS attack: it forces the user to send another AS_REQ wih a new PADATA field: a ciphertext (padata-value) with timestamp and client’s password and a key usage value of 1.

The last field is encryption type accepted by client.

For generating the AS_REQ packet, kinit command can be executed:

As you can see no password is sent to KDC.

The most important fields returned from KDC are:

Ticket: TGT encrypted with kerberos ticket that contains the session key shared between client and server. No one can decrypt it: it’s opaque ticket to give to KDC in any request.

enc-part. This contains the session key shared between client and KDC. This key, with the principal client, principal service and the life time, are encrypted with the user’s password and it is used next for asking the ticket service to be authenticated to web server. Only who knows the user’s password can decrypt it and extract the session key: it’s proof that this first phase has passed and it’s the same present in TGT.

The AS-REP trace:

The user contains now a session key shared with the KDC, the same inside the TGT. Only the kerberos server can decrypt the TGT. Using this TIcket and the session key, the client can ask to KDC another ticket, called service ticket, to access to web server resource.

This ticket service is encrypted by a secret key shared by KDC and the web server. This is why the webserver can authenticate the client: it is sure that the client has had the service ticket by a official and secure steps.

Let’s to recap the meaning of all tickets and keys involved in the protocol until now:

How can the client ask to KDC a service ticket? Using TG_REQ and TG_REP packets. Let’s talk about that.

Kerberos Protocol: TG_REQ and TG_REP

The client with the session secret key can ask a service ticket sending a new packet called TG_REQ.

The meaning of TG_REQ is that: I would like to receive a service ticket for accessing to web server; for proving that I’m a regular user authenticated I ciphered a part of request with my session key; the session key is valid because present in TGT that only KDC can decrypt.

The service ticket is associated to service key: it is inside the service ticket and released to client. Service ticket and key are used for being authenticated to web server.

The new tickets and keys issue by TG_REQ:

The service ticket and the service key can be obtained by kvno command:

[root@client~]# kinit admin
Password for admin@EXAMPLE.COM:
[root@client ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
05/22/16 16:55:18 05/23/16 16:55:17 krbtgt/EXAMPLE.COM@EXAMPLE.COM
[root@client ~]# kvno HTTP/webserver.example.com@EXAMPLE.COM
HTTP/webserver.example.com@EXAMPLE.COM: kvno = 1
[root@client ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
05/22/16 16:55:18 05/23/16 16:55:17 krbtgt/EXAMPLE.COM@EXAMPLE.COM
05/22/16 16:55:29 05/23/16 16:55:17 HTTP/webserver.example.com@EXAMPLE.COM

The client has a service ticket called HTTP/webserver.example.com@EXAMPLE.COM: it’s ready to be sent to KDC. The service ticket is encrypted by a shared key beetwen KDC and web server, created and imported on the web server in this way:

[root@ipa ~]# ipa service-add HTTP/webserver.example.com@EXAMPLE.COM
Added service “HTTP/webserver.example.com@EXAMPLE.COM”
Principal: HTTP/webserver.example.com@EXAMPLE.COM
Managed by: webserver.example.com

[root@webserver ~]#ipa-getkeytab -s ipa.example.com -p HTTP/webserver.example.com -k /etc/httpd/ conf.d/http.keytab
Keytab successfully retrieved and stored in: /etc/httpd/ conf.d/http.keytab

The authentication process can be triggered using the browser or curl command:

[root@client~]#  curl  -I –negotiate -u:  http://webserver.example.com/index.html
HTTP /1.1 401 Unauthorized
Date: Sat, 21 May 2016 13:55:20 GMT
Server: Apache/2.4.17 (Fedora) mod_auth_kerb/5.4
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm=”Kerberos Login”
HTTP /1.1 200 OK
Authorization: negotiate AP-REQ
[root@client~]# klist
Ticket cache: FILE:/tmp/krb5cc_414800001
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
08/05/15 15:00:21 09/05/15 15:00:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM
08/05/15 15:09:17 09/05/15 15:00:16 HTTP/webserver.example.com@EXAMPLE.COM

In the AP-REQ there is an Authenticator field, crypted with the service key, and the service ticket: this is enough for authenticating the client.

If the client doesn’t have any session ticket and session key, the curl command above triggers the TG_REQ automantically.

Now let’s take a look insideTG_REQ:

PA-TGS-REQ: It contains two important fields: the TGT and an authenticator or AP-REQ. The authenticator is a DER encoding of principal client with other information encrypted with the session key shared between client and server with AS-REQ/AS-REP messages.

sname: it’s the principal service name associated to the service for that the ticket is being asked: HTTP/webserver.example.com@EXAMPLE.COM

cname: It’s the principal client that asks to KDC the TGT. In our case is admin.

The TGT and the authenticator are inside a packet called AP-REQ, referred also authentication header.

TGS-REQ:

The KDC’s answer is TGS-REP with these important fields:

ticket: service ticket encrypted with the keytab shared beetwen web server and KDC. The service ticket containts a service key.  it’s opaque ticket to send to web server.

enc-part: it contains the service key above encrypted with the session key.

TGS-REP trace:

Now the client has a service ticket opaque to send to web server and a service key. Using AP-REQ and AP-REP the authentication is completed.

Let’s go to describe AP-REQ and AP-REP.

Kerberos Protocol: AP_REQ and AP_REP

The service authentication is implemented by AP-REQ packet sent directly to web server in the Authorization http header.

The authentication process can be simplified in this way: the client encrypt the string X with the service key. This service key is present in the service ticket released to client and forwarded to web server. The web server decrypts with key shared with KDC the service ticket, it extracts the service key and crypts the string X. If the encryption is equal to value sent by client, the authentication is completed successfully.

AP-REQ is created with the some approach of the AP-REQ inside TGS-REQ as explained above. The service key is used inside of session key: this is the main difference.

Moreover AP-REQ and AP-REP are encapsulated in the service protocol using mechanisms like SPNEGO (http service) or GSSAPI api (ldap service)  that implement the kerberos authentication.

These mechanisms define a way for the client to send verifiable authentication data to the services (http, ldap, etc) as done above in the Authorization http header.

CONCLUSIONS

Kerberos is one of best authentication protocol. No password are sent in the network and an single sign-on authentication is possible.

The service ticket with the service key permit to be authenticated to different services. The only prerequisite is to kerberize the service: it means creating a key shared between the service and the KDC.

The service key provided by KDC can be used not only for authenticating but for encrypting all data exchanged with the service.

I hope that every system administrator adopts the kerberos protocol in its corporate system authentication.

REFERENCE

The Kerberos Network Authentication Service: https://www.ietf.org/rfc/rfc4120.txt.

Kerberos protocol: http://www.zeroshell.net/kerberos/.