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