We will be looking two trusted third party (TTP) protocols – the Needham-Schroeder protocol and Kerberos. There are many scenarios in the world of computing that we exercise trust via a TTP. For example, authentication via a key distribution centre (KDC), trusting of digital certificate based on certificate authority, etc. Here we will be looking into how TTP are used to enable entities to authenticate one another and agree session keys.
1. The Needham-Schroeder Protocol
Alice request to initiate a communication with Bob through Trent (the KDC). Alice also includes a nonce (NA) for verification of freshness in the return message.
Trent replied with a session key (K), the session key that is encrypted using Trent and Bob’s long term key, and Alice’s nonce for verification of freshness. Trent authenticates itself to Alice by encrypting the entire message using its long-term key with Alice.
Alice sends Bob the session key from Trent that is encrypted using Trent and Bob’s long term key. This message acts as an assertion from Trent.
Bob authenticates himself to Alice by obtaining the session key by decrypting the message (message 03). Alice authenticates herself to Bob as the session key can only be obtained from Trent. Alice and Bob exchange nonce, to proof freshness, at the same time.
The Needham-Schroeder protocol provides key storage efficiency, as each client will only have to hold one long-term key, instead of (no. of hosts – 1) keys. However, in an enterprise network, the KDC in this protocol could potentially cause bottleneck; a single point of failure. In additional to performance issue, it is a high risk having the long-term key between the KDC and the client kept in the endpoints. If the long-term key is compromised, entities can be impersonated.
Next we will be looking into a more comprehensive authentication protocol that overcome drawbacks of Needham-Schroeder protocol, and has stood the test of time – Kerberos.
Kerberos can be a complicated service to understand. It took me a long time to truly understand the protocol. I’m grateful to Dr. Geriant Price and Dr. Allan Tomlinson who taught me “Security Technologies” and “Applications and Business Security Development”, respectively, at Royal Holloway, University of London, allowing me to fully appreciate the protocol.
Here I will attempt to explain how Kerberos works to show my appreciation to this comprehensive authentication protocol.
Introduction to Kerberos
Kerberos (RFC 1510) is an authentication protocol, depending on trusted third-party (TTP), developed from the basis of the Needham-Schroeder protocol. It was developed under Project Athena started by MIT in 1980s. Kerberos is one of the longest-standing proxy-based single sign-on schemes, and it exists in both Unix / Linux and Windows operating system.
Principals of Kerberos
In contrast to the TTP authentication protocol mentioned above, there are two important principals in a Kerberos system that acts as the Key Distribution Centre (KDC), an authentication server (AS) and ticket granting server (TGS):
- Authentication Server (AS) – client authenticate to AS based on long-term key. AS is the issuer of ticket granting ticket (TGT) and short-term keys (between client and TGS) in the protocol.
- Ticket Granting Server (TGS) – client authenticate to TGS based on TGT and short-term key. TGS issues a ticket and short-term key (between client and requesting services) to the client. The client can now authenticate to any service that accept the ticket as a valid authentication token.
The motivation of having two principles is to minimise the risk of exposing the long-term key. The long-term key can be removed from the client as soon as the short-term key is established with the TGS.
The client initiates the communication by requesting for a TGT of a certain TGS from the AS. The client also includes a nonce for verification of freshness in the returning message.
The AS replies the client that initiated the communication, with a TGT that only allows the requesting client to request a ticket from the TGS specified by the client in the first message. The AS also concatenate the encrypted short-term key , that will be use for communication between the client and TGS, and client’s nonce for client to check for freshness of the message, using the long-term key .
From here on, client will no longer have to go through step 1 and 2 again if he / she needs to request for a ticket from the same TGS. The long-term key will also be deleted from the client to limit risk exposure.
The client initiate the communication with the TGS by requesting the TGS for the ticket, using the TGT ( issued by AS). The client authenticates to the TGS using the short-term key issued by the AS. The client also includes a nonce for verification of freshness in the returning message.
The TGS replies the client that initiated the communication, with the ticket that is use as an authentication token to whichever server that accepts it. The TGS also concatenate the encrypted short-term key , that will be use for communication between the client and the requesting service, and client’s nonce for client to check for freshness of the message, using the AS issued short-term key .
From here on, client will no longer have to go through step 3 and 4 again if he / she needs to authenticate to the same server within the life span of the ticket and short-term key.
The client can now authenticate the requesting service using the ticket and requesting for a proof of liveliness using the short-term key between the client and server .
The protocol ends with the server replying to the client with a proof of liveliness.
Drawbacks of Kerberos
Kerberos is not a silver bullet of electronic authentication. Kerberos can be difficult to maintain, as there must be trust establishment between the Kerberos realm: Client and AS, AS and TGS, and TGS and Server. On top of that, Kerberos is built on two weakness link of security. Firstly, the authentications between the client and AS are often base on password entry. Secondly, TGT, tickets, and short-term keys are trusted on the hands of the usually unsafe / unprotected end-points (i.e. client).
Read more about Kerberos:
- Kerberos: The Network Authentication Protocol (the original documents describing Kerberos).
- Limitation of the Kerberos Authentication System, Steven M. Bellovin and Michael Merritt, AT&T Bell Labs
3. Integrating Kerberos into NIS
Now let’s look at how Kerberos can be implemented in a real world scenario – We will be looking at how Kerberos can be used to provide security features to NIS (Network Information Service, formerly known as Yellow Pages).
NIS is a client-server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network. […] Administrators have the ability to configure NIS to serve password data to outside processes to authenticate users using various version of the UNIX hash algorithms. However, in such a cases, any NIS client can retrieve the entire password database for offline inspection. Kerberos was designed to handle authentication in a more secure manner.
My demonstration Setup
Setting up Kerberos KDC
First, install the necessary packages for your KDC,
and configure it accordingly to your network. Kerberos [realms] is where encryption key is stored, and [domain_realm] is the list of machine that is a member of the realm.
Now, initialise the Kerberos databases so it can start up automatically.
Most administrative task are performed using kadmin.local on the KDC. Now, add some administrative and user principals to the Kerberos database.
You can view the principals and the details of it by using the command listprincs and getprinc respectively.
Adding the final touch to the KDC setup, create the keytab files for its application server (in this case the NIS), and fix any SELinux error, before starting the KDC.
Configuring NIS to use Kerberos for authentication
A raw NIS setup allows any NIS client to retrieve the entire password database. In addition, NIS also transmit account information in plaintext over the network. Kerberos can be integrated into the service to provide secure authentication, while NIS serves it essential to provide account information.
First, create a host principal on the KDC,
and extract the new principal into a keytab file
kadmin.local: ktadd -k /etc/krb5.keytab host/EdgisSecurity
On the NIS server, install the necessary package (yum install krb5-workstation) and copy the krb5.conf file from the KDC.
Still on your NIS server, use kadmin and create a new host principal for the NIS server and create a host principal of itself, and extract it into a keytab file.
kadmin: ktadd-l /etc/krb5.keytab host/centos6
Lastly, enable the use of Kerberos with NIS.
If any error occurred, ensure your iptables rules is set correctly (allowing port 88 and 749), and the date and time for all machines are synchronised.