Kerberos is a network authentication protocol that uses 'tickets' to enable secure communication between nodes in a non-secure environment, developed at MIT and utilized in Windows and Unix systems. It provides Single Sign-On (SSO) services through a complex authentication process involving a Key Distribution Center (KDC) and ticket granting mechanisms, with limitations in web environments addressed by the SPNEGO protocol. Despite its effectiveness in intranets, Kerberos poses challenges such as being a single point of failure and restrictions in scenarios involving external clients.

1. Introduction to
Kerberos
Tomek Kopczyński
www.sparkbit.pl

2. Kerberos is a computer network authentication protocol which works on
the basis of 'tickets' to allow nodes communicating over a non-secure
network to prove their identity to one another in a secure manner.
[Wikipedia]
What is Kerberos?
www.sparkbit.pl

3. Basic information
Developed on Massachusetts Institute of Technology (MIT)
Windows 2000 and later are using Kerberos as a default
authentication mechanism (although over Microsoft’s own
implementation)
Kerberos is built into Active Directory solution
UNIX-based operating systems have tools for authenticating over
Kerberos
Kerberos main use case is to provide SSO service in untrusted
networks
1
2
3
4
5
www.sparkbit.pl

4. Kerberos Realm
HTTP Service
Browser
Ticket Granting Server
Authentication Server
KDC CLIENTS KEY DISTRIBUTION CENTER
www.sparkbit.pl

5. The authentication process
Client
sends request
KDC
lookups the user
in its database
User ID
Requested Service ID (Ticket
Granting Server in this case)
Client network address
Requested lifetime of TGT
Plaintext Request
Ticket Granting Ticket
User ID
Timestamp
Client network address
TGT lifetime
Ticket Granting Server (TGS)
Session Key
issued by Authentication Server, signed
by
KDC's private key
www.sparkbit.pl

6. Successful authentication in Kerberos,
leads to authorization.

7. Kerberos authorization part I
Lorem ipsum dolor sit
amet, adipiscing elit,
sed diam nummy.
42 31
checks the Service ID
in its database
decrypts TGT and if it's
successful, Client is
granted access to
Service
issues a Service Ticket (signed by TGS
session key) which contains:
HTTP service ID
Timestamp
Ticket lifetime
HTTP service session key
Client KDC KDC KDC
To be able to authorize
with a service, Client sends
the Ticket Granting Ticket
with a Service ID to KDC
This is the moment when a trust
between Client and Service is
established
www.sparkbit.pl

8. Kerberos authorization part II
Client
Service
decrypts Service Ticket to check whether
Client is authorized to make requests
against this Service
encrypted
Service
Ticket
Service
Response
sends
returns this information
to Client
www.sparkbit.pl
Client uses cached Service Ticket
in all subsequent requests
as long as it is valid

9. Kerberos important notes
Target service does not have to talk to KDC during authorization
process
Authentication in Kerberos is ensured implicitly: important
information is sent encrypted and protocol will authorize Client if
those messages can be decrypted
Passwords are never stored in clear text and are not sent over the
network
www.sparkbit.pl

10. Kerberos in HTTP - SPNEGO
Kerberos is designed for client/server environments
It's difficult to use pure Kerberos in web and thin client environments
SPNEGO was created to overcome this issue –a wrapper protocol over
Kerberos
www.sparkbit.pl

11. SPNEGO
www.sparkbit.pl
When a Client wants to access protected Service without proper authentication data, it
gets rejected with a 401 unauthorised status code and with an additional header WWW-
Authenticate: Negotiate which instructs Client to use SPNEGO authentication
Client then has to request a ticket from KDC
Next, Client has to wrap the ticket in a SPNEGO envelope and send it in Authorization
header to a web server requesting the same Service
Web server can unwrap SPNEGO envelope and use the ticket as user credentials
If Service needs to access other Kerberos-protected resources to complete the call, it
can delegate the ticket sent by the Client to other requests
Each request to Kerberos-protected Service needs its own unique ticket. Reusing
tickets is forbidden –Kerberos treats them as replay attacks.

12. SPNEGO
www.sparkbit.pl
HTTP GET/api/service
401 Unauthorized WWW-Authenticate: "Negotiate"
HTTP GET/api/service Authorization: "Negotiate XeH83HiJ"
{result: "OK"}
Client Web Server

13. Kerberos limitation
www.sparkbit.pl
KDC is a single point of failure, though it can be mitigated by using
multiple servers
Kerberos has strict time limitations on difference between clocks on hosts
taking part in the process
Kerberos cannot be used in scenarios where clients come from outside of
the domain (typical Internet use case)
Problematic creating staged environment: single-domain vs separate
domain for each environment

14. Summary
www.sparkbit.pl
Authentication protocol well suited for intranets in companies
Integrated in Active Directory on Windows servers
Complicated usage in HTTP world, need to use wrapper protocol like
SPNEGO

15. Thank you for your time.
Take care!
www.sparkbit.pl