Transcript Document

Keberos
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
Kerberos

A computer network authentication protocol



Allows individuals communicating over a non-secure
network to prove their identity to one another in a secure
manner
A suite of free software published by Massachusetts
Institute of Technology (MIT) that implements this protocol
Aimed primarily at a client-server model

Provides mutual authentication


Both the user and the server verify each other's identity
Kerberos protocol messages are protected against
eavesdropping and replay attacks
Kerberos

Builds on symmetric key cryptography


Requires a trusted third party
Extensions to Kerberos can provide for the
use of public key cryptography during certain
phases of authentication
History and development
History and development

MIT developed Kerberos to protect network
services provided by Project Athena

Named after the Greek mythological character
Kerberos (Cerberus)


Monstrous three-headed guard dog of Hades in Greek
mythology
Several versions of the protocol exist

Versions 1–3 internal only at MIT
History and development

Version 4 published in the late 1980s

Steve Miller and Clifford Neuman



The primary designers of Kerberos
Targeted primarily for Project Athena
Version 5 (1993)




Addressed the limitations and security problems of
version 4
Designed by John Kohl and Clifford Neuman
RFC 1510
Made obsolete by RFC 4120 in 2005
History and development

MIT has a free version of Kerberos available


Copyright permissions similar to those used for BSD
Authorities in the United States classified Kerberos as a munition



Banned its export
Used the DES encryption algorithm (with 56-bit keys)
Non-US Kerberos 4 implementation, KTH-KRB



Swedish implementation was based on a version called eBones.




Developed at the Royal Institute of Technology in Sweden
System available outside the US before the US changed its cryptography export
regulations (circa 2000).
eBones was based on the exported MIT Bones release based on version Kerberos
4 patch-level 9
Stripped of both the encryption functions and the calls to them
This somewhat limited Kerberos was called the eBones release
A Kerberos version 5 implementation, Heimdal, was released by basically
the same group of people releasing KTH-KRB
History and development

Windows 2000, XP, Server 2003 and Vista


Use Kerberos as their default authentication method
Microsoft additions to the Kerberos suite of protocols




RFC 4757 documents Microsoft's use of the RC4 cipher
Microsoft uses the Kerberos protocol


Documented in RFC 3244
"Microsoft Windows 2000 Kerberos Change Password and Set
Password Protocols"
Does not use the MIT software
Apple's Mac OS X uses Kerberos

client and server versions
History and development


The IETF Kerberos working group is updating the specifications
Recent updates include:

“Encryption and Checksum Specifications”


“Advanced Encryption Standard (AES) Encryption for Kerberos 5”


RFC 3961
RFC 3962
New edition of the Kerberos V5 specification



“The Kerberos Network Authentication Service (V5)”
RFC 4120
Obsoletes RFC 1510


Clarifies aspects of the protocol and intended use in a more detailed and clearer
explanation
New edition of the GSS-API specification


“The Kerberos Version 5 Generic Security Service Application Program Interface
(GSS-API) Mechanism: Version 2.“
RFC 4121
Description
Description

Kerberos uses as its basis the Needham-Schroeder protocol
 It makes use of a trusted third party


Key Distribution Center (KDC),
Consists of two logically separate parts:



Kerberos works on the basis of "tickets“


An Authentication Server (AS)
A Ticket Granting Server (TGS)
Serves to prove the identity of users
The KDC maintains a database of secret keys



Each entity on the network — whether a client or a server — shares
a secret key known only to itself and to the KDC
Knowledge of this key serves to prove an entity's identity
For communication between two entities


KDC generates a session key
Used to secure their interactions
Uses
Uses

The following software can use Kerberos for authentication:























VMware ESX Server
AFS
Apache 1 (with the mod_auth_kerb module)
Apache 2 (using libapache-mod-auth-kerb)
Cisco routers and switches running IOS
Coda File System
Eudora
Mac OS X
Microsoft Windows (2000 and later) uses as default authentication protocol
Mulberry, an e-mail client developed by Cyrusoft, Inc.
NFS (since NFSv3)
OpenSSH (with Kerberos v5 or higher)
Oracle RDBMS
PAM (with the pam_krb5 module)
rcp Remote copy command in linux and unix
Samba since v3.x
SOCKS (since SOCKS5)
Netatalk
GSS-API
X Window System implementations
Indirectly, any software that allows the use of SASL for authentication, such as OpenLDAP,
Dovecot IMAP4 and POP3 server, Postfix mail server
Kerberos software suite also comes with kerberos-enabled clients and servers for rsh, FTP,
and Telnet
Any Java based software (since 1.4.2) using JAAS/JGSS can use Kerberos for security
Protocol
Protocol


Security of the protocol relies heavily on participants maintaining
loosely synchronized time and on short lived assertions of
authenticity called Kerberos tickets
Simplified description of the protocol
 Abbreviations:





AS = Authentication Server
TGS = Ticket Granting Server
SS = Service Server
TGT = Ticket Granting Ticket
Briefly:

Client authenticates to AS using a long-term shared secret


Client can use this ticket to get additional tickets for SS


Receives a ticket from the TGS
Doesn’t need to resorting to using the shared secret
These tickets can be used to prove authentication to SS
Protocol


In more detail:
User Client-based Logon Steps:


User enters a username and password on the
client
Client performs a one-way function on the entered
password

Becomes the secret key of the client
Protocol

Client Authentication Steps:

Client sends a clear-text message to the AS requesting services on behalf of
the user



The AS checks to see if the client is in its database. If it is, the AS sends
back the following two messages to the client:



Sample Message: "User XYZ would like to request services"
Note: Neither the secret key nor the password is sent to the AS
Message A: Client/TGS session key encrypted using the secret key of the user.
Message B: Ticket-Granting Ticket (which includes the client ID, client network
address, ticket validity period, and the client/TGS session key) encrypted using the
secret key of the TGS.
Once the client receives messages A and B, it decrypts message A to obtain
the client/TGS session key



This session key is used for further communications with TGS
(Note: The client cannot decrypt the Message B, as it is encrypted using TGS's
secret key.)
At this point, the client has enough information to authenticate itself to the TGS.
Protocol

Client Service Authorization Steps:
 When requesting services, the client sends the following two
messages to the TGS:



Message C: Composed of the Ticket-Granting Ticket from message
B and the ID of the requested service.
Message D: Authenticator (which is composed of the client ID and
the timestamp), encrypted using the client/TGS session key.
Upon receiving messages C and D, the TGS retrieves message
B out of message C. It decrypts message B using the TGS secret
key. This gives it the "client/TGS session key". Using this key, the
TGS decrypts message D (Authenticator) and sends the following
two messages to the client:


Message E: Client-to-server ticket (which includes the client ID, client
network address, validity period and Client/server session key)
encrypted using the service's secret key.
Message F: Client/server session key encrypted with the client/TGS
session key.
Protocol

Client Service Request Steps:

Upon receiving messages E and F from TGS, the client has enough
information to authenticate itself to the SS. The client connects to the SS and
sends the following two messages:



The SS decrypts the ticket using its own secret key and sends the following
message to the client to confirm its true identity and willingness to serve the
client:



Message E from the previous step (the client-to-server ticket, encrypted using
service's secret key).
Message G: a new Authenticator, which includes the client ID, timestamp and is
encrypted using client/server session key.
Message H: the timestamp found in client's recent Authenticator plus 1, encrypted
using the client/server session key.
The client decrypts the confirmation using the client/server session key and
checks whether the timestamp is correctly updated. If so, then the client can
trust the server and can start issuing service requests to the server.
The server provides the requested services to the client.
Kerberos drawbacks
Kerberos drawbacks


Single point of failure: requires continuous availability of a central
server
 When the Kerberos server is down, no one can log in
 Can be mitigated by using multiple Kerberos servers
Requires the clocks of the involved hosts to be synchronized
 Tickets have time availability period

Default configuration requires that clock times are no more than
10 minutes apart
 NTP daemons are usually employed to keep the host clocks
synchronized
Administration protocol is not standardized
 Differs between server implementations
 Password changes described in RFC 3244


If the host clock is not synchronized with the clock of Kerberos
server, the authentication will fail.
Single sign-on
Single sign-on

A method of access control that enables a user to authenticate
once and gain access to the resources of multiple software
systems
 Term enterprise reduced sign-on is preferred by some authors

They believe single sign-on to be a misnomer:


"no one can achieve it without a homogeneous IT infrastructure"
In a homogeneous IT infrastructure or at least where a single
user entity authentication scheme exists or where user database
is centralized, single sign-on is a visible benefit
 All users in this infrastructure would have one or single
authentication credentials


e.g. say in an organization stores its user database in a LDAP
database.
All Information processing systems can use such a LDAP
database for user authentication and authorization

In turn means single sign-on has been achieved organization wide