Transcript Kerberos: A Network Authentication Tool

Kerberos: A Network
Authentication Tool
Seth Orr
University of Missouri – St. Louis
CS 5780 System Administration
Overview
•
•
•
•
•
•
•
•
Introduction
History
Components
Protocol
Installation and Configuration
Strengths and Weaknesses
Conclusions
References
Introduction
• Security
– As we have already seen, the world is full of
unscrupulous people, and we must protect
vital data and services.
– Many tools exist for system administrators
that provide security.
– But, as security increases, so does user
burden.
– System administrators need a tool that is
tough and convenient.
Introduction
• Kerberos provides toughness and
convenience.
• So what is Kerberos any way?
Introduction
• RFC 1510 States:
Kerberos provides a means of verifying the identities
of principals, (e.g., a workstation user or a network
server) on an open (unprotected) network. This is
accomplished without relying on authentication by the
host operating system, without basing trust on host
addresses, without requiring physical security of all
the hosts on the network, and under the assumption
that packets traveling along the network can be read,
modified, and inserted at will. Kerberos performs
authentication under these conditions as a trusted
third-party authentication service by using
conventional cryptography, i.e., shared secret key.
Introduction
• Jason Garman’s Keberos: The Definitive
Guide defines Kerberos as a “secure,
single-sign-on, trusted, third-party mutual
authentication service.”
• What does this mean exactly?
Introduction
• Kerberos provides a way to authenticate
clients to services to each other through a
trusted third party.
• Kerberos makes the assumption that the
connection between a client and service is
insecure.
• Passwords are encrypted to prevent
others from reading them.
• Clients only have to authenticate once
during a pre-defined lifetime.
History
• Kerberos was designed and developed at
MIT by Project Athena.
• Currently, Kerberos is up to Version 5.
• Version 4 being the first version to be
released outside of MIT.
• Kerberos has been adopted by several
private companies as well as added to
several operating systems.
History
• Its creation was inspired by client-server
model replacing time-sharing model.
• Users could not be trusted.
Components
• Principals
• Realms
• Key Distribution Centers (KDC’s)
– Authentication Service
– Ticket Granting Server
• Tickets
• Authenticators
Components
• Principals
– each entity, such as clients or application
servers, is represented as a principal
– coupled with a key
– stored with their keys in a database on the
Key Distribution Center or KDC
– must be unique
Components
• Realms
– companies and organizations are composed
of different departments, each with a different
function
– to make things less complex, system
administrators represent each department
with a realm
– each realm has its own KDC(s)
Components
• Key Distribution Centers (KDC’s)
– composed of an Authentication Service and
Ticket Granting Server
– has a database that houses all principals and
their keys for a given realm
– at least one KDC per realm
Components
• Authentication Service (AS)
– piece of software that accepts requests from
clients
– creates TGT’s based on the information in
the request (principal names for client and
service)
– also establishes the secret session key used
for communication between clients and
services
Components
• Ticket Granting Server (TGS)
– responsible for accepting Ticket Granting
Tickets
– verifies that the TGT’s are correct
– returns application service tickets clients
based on the TGT’s
– its existence allows for convenience because
clients only have to authenticate themselves
once to the AS to get TGT’s, which are
presented to the TGS
Components
• Tickets
– according to Garman, “Tickets serve two
purposes: to confirm identity of the end
participants and to establish a short-lived
encryption key that both parties can share for
secure communication (called the session
key)”
– contains valuable data used by clients or
services in order to confirm that the
authentication is real
Components
• Tickets
– includes data such as: requesting client’s
principal name, the application service’s
principal name, when the ticket expires, a list
of valid IP addresses, and a secret session
key shared between the client and the
application service
– can either be Ticket Granting Tickets (TGT’s)
for the TGS or for application services
Components
• Authenticators
– consist of timestamps that are encrypted with
the secret session key shared between the
client and the application service
– can only be used once
– timestamp can’t exceed maximum time frame
– used to prevent replay attacks
Components
Protocol
• Since clients could possibly be trying to
access certain critical and important data
or service from network applications, they
have to prove in some way their identity.
• We need some protocol for doing this
authentication.
• The Kerberos Version 5 authentication
protocol is fully detailed in RFC 1510.
Protocol
Protocol
• What if a client wants to access a service
in another realm?
• Cross-Realm Authentication
– two realms, A and B
• A’s TGS principal’s name and key are in B’s KDC
principal database
• B’s TGS principal’s name and key are in A’s KDC
principal database
– direct trust
– hierarchical trust
Installation and Configuration
• MIT
– software available
• http://web.mit.edu/kerberos/www/krb5-1.3/
– installation and configuration guides
•
•
•
•
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-install.html
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-user.html
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-admin.html
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb425.html
• Heimdal
– software available
• http://www.pdc.kth.se/heimdal/
– installation and configuration guide
• http://www.pdc.kth.se/heimdal/heimdal.html
Installation and Configuration
• Windows
– overview and guide
• http://www.microsoft.com/technet/prodtechnol/wind
ows2000serv/deploy/confeat/kerberos.mspx
• Shishi
– software available
• http://josefsson.org/shishi/
Installation and Configuration
• Other guides
– a resource with advice on how to “Kerberize”
your site
• http://www.ornl.gov/~jar/HowToKerb.html
– a very good overview on Kerberos and its
installation and configuration
• http://www.ms.washington.edu/Docs/Kerberos/krb5-server1.2.7/install.html
– FAQ and information on configuration files
• http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberosfaq.html
Strengths
1. Passwords are never sent across the
network unencrypted. This prevents those
unscrupulous people from being able to read
the most important data sent over the
network.
2. Clients and applications services mutually
authenticate. Mutual authentication allows
for both ends to know that they truly know
whom they are communicating with.
3. Tickets have a limited lifetime, so if they are
stolen, unauthorized use is limited to the
time frame that the ticket is valid.
Strengths
4. Authentication through the AS only has to
happen once. This makes the security of
Kerberos more convenient.
5. Shared secret keys between clients and
services are more efficient than public-keys.
6. Many implementations of Keberos have a
large support base and have been put
through serious testing.
7. Authenticators, created by clients, can only
be used once. This feature prevents the use
of stolen authenticators.
Weaknesses
1. Kerberos only provides authentication for
clients and services.
2. Kerberos 4 uses DES, which has been shown
to be vulnerable to brute-force-attacks with
little computing power.
3. The principal-key database on the KDC has to
be hardened or else bad things can happen.
4. Like any security tool, it is also vulnerable to
users making poor password choices.
Conclusions
• Organizations have networks based on the
client-server model, but clients and
servers never meet.
• How do we prove identities then?
• Must have some way of authentication to
enable security.
• However, an increase in security increases
user burden.
Conclusions
• Kerberos provides a means of
authentication coupled with convenience
over an unprotected network.
• Kerberos never allows passwords to be
sent unencrypted.
• Initially developed at MIT, Kerberos is
available from many sources and has a
wide support base and documentation.
References
•
•
•
•
•
•
•
Bryant, Bill, and Theodore Ts’o. Designing an Authentication System: a Dialogue in
Four Scenes. February 1997. Massachusetts Institute of Technology. 1
November 2004 <http://web.mit.edu/kerberos/www/dialogue.html>.
Garman, Jason. Kerberos: The Definitive Guide. Sebastopol, CA: O’Reilly, 2003.
“Kerberos: Advantages and Weaknesses.” Duke University. 20 November 2004.
< http://www.oit.duke.edu/~rob/kerberos/kerbasnds.html >.
Kohl, J, and C. Neuman. The Kerberos Network Authentication Service (V5).
September 1993. Internet Engineering Task Force. 1 November 2004
<http://www.ietf.org/rfc/rfc1510.txt>.
Naval Research Laboratory, Computational Meta-Facility. 8 August 2000. Frequently
Asked Questions about Kerberos. 15 November 2004
<http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html>.
Neuman, B. Clifford, and Theodore Ts’o. Kerberos: An Authentication Service for
Computer Networks. September 1994. Information Sciences Institute, USC. 15
November 2004 <http://gost.isi.edu/publications/kerberos-neuman-tso.html>.
Tung, Brian. The Moron’s Guide to Kerberos, Version 1.2.2. 19 December 1996.
Information Sciences Institute, USC. 11 November 2004
<http://www.isi.edu/gost/brian/security/kerberos.html>.