Transcript kerberos

Overview of Kerberos
Chad Thoenen
Scott Redding (Project Leader)
Jim Luo
University of Tulsa
Department of Mathematical & Computer Sciences
CS 5493/7493 Secure System Administration &
Certification
Dr. Mauricio Papa
University of Tulsa - Center for Information Security
Presentation Layout
• Chad Thoenen
– Background Information, why you might use Kerberos, and
Design approaches
• Scott Redding
– Will present an overview of how the Kerberos protocol work
• Jim Lou
– Will cover the Guide to Windows 2000 Kerberos Settings
University of Tulsa - Center for Information Security
Background Information
• What is Kerberos?
– Kerberos is a network authentication protocol.
– It was designed to provide strong authentication for
client/server applications by using secret-key cryptography.
• Who developed Kerberos ?
– The Massachusetts Institute of Technology (MIT) developed
Kerberos in the 1980s as part of the Project Athena Network.
The Athena Project attempted to discover how to design,
implement, and manage distributed computing environments.
University of Tulsa - Center for Information Security
Background Information
continued …
• Why is Kerberos needed?
– Most computer systems use some form of password protection
scheme to authenticate users using userids and passwords.
• Anyone who happens to know the password can claim to be that user.
– So, with that said, it is important to prevent people from listening in
on the conversation between the computer and the user's
workstation or terminal.
– In a local-area network, several computers can share the same
network, and any computer on that network can listen in on the
others network traffic.
– With the advent of network monitoring packages, it is relatively easy
for a user to set up a program to listen in on a network for any and
all passwords being sent over the network.
University of Tulsa - Center for Information Security
Background Information
continued …
– Note, The Electronic Communications Privacy Act of 1986
makes stealing data a Federal punishable crime.
– In MIT circumstance, since Athena and MITnet use a
workstation-based model of computation, with most
operations taking place on a single-user workstation with
occasional requests (for files, etc.) going to other "server"
machines, Athena needed to set up some way of allowing
users to prove their identity to such server machines.
University of Tulsa - Center for Information Security
Key Terms
• service
A program or set of programs running on a computer
which is accessible over the network. The service
would like to know with certainty that the
workstation to which it is providing the service is
really being used by the user who claims to be logged
in on the workstation.
• principal
An entity that can both prove its identity and verify
the identities of other principals who wish to
communicate with it; each user and each service
registered with Kerberos is thus a principal.
University of Tulsa - Center for Information Security
Key Terms continue …
• ticket
A block of data which, when given to a user, enables
him to prove his identity to a service. In the Athena
environment tickets are stored in files in the /tmp
directory, and are automatically erased on log-out.
They contain information which must be considered
private to the user, and thus the file should be kept at
protection mode 700. As they contain a time stamp,
they cease to be valid after eight hours. One ticket is
needed for each service; tickets are used to build
authenticators, which are sent over the network to the
service.
University of Tulsa - Center for Information Security
Key Terms continue …
• authenticator
A block of data which a user's workstation sends over
the network to a specific service to prove that the
workstation really is in use by that user. An
authenticator expires after five minutes. One
authenticator is typically built per session of use of a
service; once the service decodes the authenticator, it
generally permits the user to operate for as long as
she wants. This behavior is not in any way mandated
by the Kerberos suite of programs and libraries (it is
just a detail of the implementation), but it is
convenient and considered secure enough for the
Athena environment.
University of Tulsa - Center for Information Security
Designing an Authentication
System
• Designing and Authentication System: a
Dialogue in Four Seasons
– http://web.mit.edu/kerberos/www/dialogue.html
– The dialogue was written in 1988 to help readers understand
the fundamental reasons for why the Kerberos V4 protocol
was the way it was.
– Still applicable for Kerberos V5 protocol, with only two
changes from the description of the “Kerberos” protocol in the
dialogue.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Abstract
– This dialogue provides a fictitious account of the design of an opennetwork authentication system called "Charon." As the dialogue
progresses, the characters Athena and Euripides discover the
problems of security inherent in an open network environment. Each
problem must be addressed in the design of Charon, and the design
evolves accordingly. Athena and Euripides don't complete their work
until the dialogue's close.
– When they finish designing the system, Athena changes the system's
name to "Kerberos," the name, coincidentally enough, of the
authentication system that was designed and implemented at MIT's
Project Athena. The dialogue's "Kerberos" system bears a striking
resemblance to the system described in Kerberos: An Authentication
Service for Open Network Systems presented at the Winter USENIX
at Dallas, Texas in 1988.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Characters
– Athena
• an up and coming system
developer.
– Euripides
• a seasoned developer and
resident crank.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Page 1 - 17
• Scene I
–
–
–
–
–
–
–
–
–
–
–
A cubicle area. Athena and Euripides are working at neighboring terminals.
Athena: Hey Rip, this timesharing system is a drag. I can't get any work done because everyone else is logged in.
Euripides: Don't complain to me. I only work here.
Athena: You know what we need? We need to give everyone their own workstation so they don't have to worry about sharing
computer cycles. And we'll use a network to connect all the workstations so folks can communicate with one another.
Euripides: Fine. So what do we need, about a thousand workstations?
Athena: More or less.
Euripides: Have you seen the size of a typical workstation's disk drive? There isn't enough room for all the software that you
have on a timesharing machine.
Athena: I figured that out already. We can keep copies of the system software on various server machines. When you login
to a workstation, the workstation accesses the system software by making a network connection with one of the servers.
This setup lets a whole bunch of workstations use the same copy of the system software, and it makes software updates
convenient. You don't have to trundle around to each workstation. Just modify the system software servers.
Euripides: All right. What are you going to do about personal files? With a timesharing system I can login and get to my
files from any terminal that is connected to the system. Will I be able to walk up to any workstation and automatically get to
my files? Or do I have to make like a PC user and keep my files on diskette? I hope not.
Athena: I think we can use other machines to provide personal file storage. You can login to any workstation and get to your
files.
Euripides: What about printing? Does every workstation have its own printer? Whose money are you spending anyway? And
what about electronic mail? How are you going to distribute mail to all these workstations?
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene I
– Main Concept
• Timesharing systems can prevent user from getting work
accomplished when everyone is logged in.
• They need to get everyone their own workstations so they don’t
have to share computer cycles.
– Problems surrounding Main Concept
• Individual workstations do not have enough disk space for the
system software stored on the timesharing machine
• Is everyone going to need a printer?
• How is mail going to be routed to the users?
• In an open network environment, machines that provide services
must be able to confirm the identities of people who request
service.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene II
– Resolution to Problem in Scene I
• Quick fix is to require a password to access a service.
• Each user knows her or his password, each service program knows its
password, and there's an AUTHENTICATION SERVICE (Charon) that
knows ALL passwords--each user's password, and each service's
password. The authentication service stores the passwords in a single,
centralized database.
– Main Concept
• Charon produces a ticket instead of a password.
• Issues with decrypting the ticket cause the two to add more to the
ticket. You can make a workstation think you are someone who you are
not, so they also added the workstation ip address to the ticket as well.
– {username:ws_address:servicename}
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene II continue …
– Main Concept continue …
• Tickets will be need to be reusable.
– Problems surrounding Main Concept
• Users only have to enter their passwords once, at the beginning
of their workstation sessions. This requirement implies that you
shouldn't have to enter your password every time you need a
new service ticket.
• The second requirement: passwords should not be sent over the
network in clear text.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene III
– Resolution to Problem in Scene II
• (Athena) I've met this requirement by inventing a new network service.
It's called the "ticket-granting" service, a service that issues Charon
tickets to users who have already proven their identity to Charon. You
can use this ticket-granting service if you have a ticket for it, a ticketgranting ticket.
– Main Concept
• Charon uses the username to look up your password. Next Charon builds
a packet of data that contains the ticket-granting ticket. Before it sends
you the packet, Charon uses your password to encrypt the packet's
contents.
• Your workstation receives the ticket packet. You enter your password.
kinit attempts to decrypt the ticket with the password you entered. If
kinit succeeds, you have successfully authenticated yourself to Charon.
You now possess a ticket-granting ticket, and that ticket can get you the
other tickets you require.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene III continue …
– Main Concept continue …
• Expiration timeframes for tickets and a ticket-destroying
program.
– Problems surrounding Main Concept
• At first, tickets had no expiration date. Then they decided on
tickets expiring after eight hours.
• If a user logs out before the eight hour window expires, for
example having six hours left, a user would have time if they had
stolen your tickets to REPLAY your tickets and gain access to
your data.
University of Tulsa - Center for Information Security
Designing an Authentication
System continued …
• Scene IV
– The final act …
– Scene four is the final round and they outline the process in
detail of how Kerberos works.
– I will stop here as Scott will talk about the details of how the
protocol works.
– This dialog was to give you some idea of how the protocol was
originally designed.
University of Tulsa - Center for Information Security
Players
• Client – Also called the principal, it’s the
Workstation user
• Server – Who the Client wants to
communicate with
• Authenticator – Facilitator for secure
communication, the Ticket Granting Server.
Can also be the Key Distribution Center
(KDC)
• KDC – Server where key database is kept
University of Tulsa - Center for Information Security
Terms
• Ticket – Similar to a carnival ticket, you must have
one to play the game
– Unforgeable, nonreplayable, authenticated object
– Contains
•
•
•
•
•
Client ID
Requested service
Access rights for the service
Timestamp
Symmetric cryptographic session key
• Ticket Granting Ticket – Allows the Client to request
tickets from the Ticket Granting Server
University of Tulsa - Center for Information Security
Process
• Authentication Service Exchange
– Initial exchange between Client and Authenticator
– They already share a secret key
– Client obtains ticket enabling Client to establish session with
a Server
– Server typically set up for session is the Ticket Granting
Server
University of Tulsa - Center for Information Security
Process
• Ticket Granting Service Exchange
– Doesn’t use the Client’s secret key, uses TGT
– Used to obtain ticket to establish session with Server
University of Tulsa - Center for Information Security
Process
• Client - Server Authentication Exchange
–
–
–
–
Between Client and target Server
Authenticates Client to Server
Authenticates Server to Client
Both share symmetric key that can be used for encrypted
communication
University of Tulsa - Center for Information Security
Next Slide Requires Power Point 2002 in order
to
View animation.
University of Tulsa - Center for Information Security
Authenticator (KDC)
Client
Client ID
Timestamp1
Request for
Credentials
Timestamp2
Server
Timestamp2, ID
University of Tulsa - Center for Information Security
It’s not really that simple
• Initial exchange is request for credentials to
talk with the Ticket Granting Service (TGS)
• Similar process to that just described gets
Client a Ticket Granting Ticket (TGT)
• TGT is used from this point forward to acquire
tickets from the TGS.
• Why? Single sign-on.
University of Tulsa - Center for Information Security
Challenges
• System Administration
– KDC – holds “keys to the kingdom”
– Physical security
– Network connectivity
• Software Integration
– “r” service program replacements
– Kerberization of programs
• User Education
University of Tulsa - Center for Information Security
Advantages
• Good protection
• Relatively inexpensive technology
• Passwords are not communicated over
network (not even encrypted passwords)
• Procedures exist for use across multiple
domains called realms “Cross-Realm
Authentication”
• Built-in support in some operating systems
University of Tulsa - Center for Information Security
Disadvantages
• Trusted, high availability servers required
• Time stamps require secure synchronized
clocks
• Scaling to large user populations is difficult
• Password, ticket security required on Client
system
• Applications need to be “kerberized”
University of Tulsa - Center for Information Security
Windows 2000 Kerberos
University of Tulsa - Center for Information Security
Authentication in Windows
2000
• Kerberos Version 5
– The default for Windows 2000
– Protocol of choice when there is a choice
• Windows NT LAN Manager (NTLM)
– Retained in Windows 2000 for backward compatibility
– The default authentication protocol for Windows NT 4.0
– Machines running Windows 3.1, Windows 98, and Windows
NT in Windows 2000 domains
– Windows 2000 machines authenticating through a Windows
NT server
– Stand alone Windows 2000 machines
University of Tulsa - Center for Information Security
How It Works
• The Kerberos Version 5 services are installed
on each domain controller
• A Kerberos client is installed on each Windows
2000 workstation and server.
• Every domain controller acts as a Key
Distribution Center (KDC). Clients locate
KDC’s through a DNS lookup.
• The nearest available domain controller serves
as the preferred KDC for that user during the
user's logon session.
University of Tulsa - Center for Information Security
How It Works
1 The user on a client system, using a password or a
smart card, authenticates to the Key Distribution
Center (KDC).
2 The KDC issues a special ticket-granting ticket (TGT)
to the client.
3 The client uses TGT to access the ticket-granting
service (TGS). The TGS issues service ticket to the
client.
4 The client presents this service ticket to the
requested network service. The service ticket
University of Tulsa - Center for Information Security
provides mutual authentication
Kerberos Advantages
•
•
•
•
•
•
More efficient authentication to servers
Mutual authentication
Delegated authentication
Simplified trust management
Interoperability
Invisible to users
University of Tulsa - Center for Information Security
Kerberos Policy
• Kerberos policy is defined at the domain level
and implemented by the domain's Key
Distribution Center (KDC).
• Kerberos policy is stored in Active Directory as
a subset of the attributes of a domain security
policy.
• Kerberos is normally an automatic process
and you are not required to set it up. There
are very few policy choices that can be applied
to Kerberos.
University of Tulsa - Center for Information Security
Kerberos Policy
• “The primary thing to remember about
configuring Kerberos is that the default is
good… Unless there is some specific reason to
change one of the parameters, you should
leave the parameters alone”
– Microsoft
• NSA agrees.
University of Tulsa - Center for Information Security
Kerberos Policy
• Enforce User Logon Restrictions
– Default Value: Enabled. NSA Recommendation: Enabled
• Maximum Lifetime That a User Ticket Can Be
Renewed
– Default: 7 days. NSA: 7 Days
• Maximum Service Ticket Lifetime
– Default: 10 hours. NSA Recommendation : 10 hours
• Maximum Tolerance for Synchronization of Computer
Clocks
– Default value: 5 minutes. NSA Recommendation: 5 minutes
• Maximum User Ticket Lifetime –
– Default value: 10 hours. NSA Recommendation: 10 hours
University of Tulsa - Center for Information Security
Account Policy
• Smart Card required for interactive login
– Default Value: Disabled NSA Recommendation: Disabled
• Account trusted for delegation
– Default Value: Disabled NSA Recommendation: Disabled
• Account is sensitive and cannot be delegated
– Default Value: Disabled NSA Recommendation: Disabled
• Use DES Encryption for this account
– Default Value: Disabled NSA Recommendation: Disabled
• Does not require Kerberos pre-authentication
– Default Value: Disabled NSA Recommendation: Disabled
University of Tulsa - Center for Information Security
Kerberos Interoperability
• The Microsoft Windows 2000 operating system
implementation of Kerberos conforms to the
MIT Kerberos version 5 reference
implementation for interoperability
• It can integrate with Kerberos services in
heterogeneous networks running different
operating systems.
University of Tulsa - Center for Information Security
Kerberos Interoperability
• A Windows 2000 Server domain controller can
serve as the Kerberos Key Distribution Center
(KDC) server for MIT Kerberos-based client
and host systems
• Windows 2000 Professional clients can be
configured to use a Kerberos realm, with
single sign-on to the Kerberos realm and the
local Windows 2000 Professional-based client
account
University of Tulsa - Center for Information Security
Kerberos Interoperability
• The Windows 2000 Kerberos Security Support
Provider (SSP) implements the General Security
Service Application Program Interface (GSS API)
Kerberos Mechanism Token formats defined in RFC
1964. Windows 2000 does not provide the GSS API;
instead, the Kerberos support is available to Microsoft
Win32 API-based applications using the SSPI APIs
implemented by the Kerberos SSP. Client applications
on UNIX using GSS API can obtain session tickets to
services on Windows 2000, and can complete mutual
authentication, message integrity, and confidentiality
University of Tulsa - Center for Information Security
Interoperability Configuration
• Interoperability with Kerberos services
requires minor configuration changes from the
default installation.
• For example, a Windows 2000 workstation
that uses a Kerberos realm must be configured
to:
– Locate the Kerberos realm
– Locate available KDC servers
– Locate available Kerberos change password servers.
University of Tulsa - Center for Information Security
Kerberos Interoperability
Tools
• Ksetup – Configures Kerberos realms, KDCs,
and Kpasswd servers.
• Ktpass – Sets the password, account name
mappings, and keytab generation for Kerberos
services that use the Windows 2000 Kerberos
KDC.
• Gssclient – tests RFC 1964 interoperability
• Gssserver – tests RFC 1964 interoperability
• Klist – examines the Kerberos credential
cache.
University of Tulsa - Center for Information Security
Interoperability Limitations
• Only DES-CBC-MD5 and DES-CBC-CRC encryption
types are available for MIT Kerberos interoperability.
• Hierarchical realm support for cross-platform trust
between the Windows 2000 and MIT Kerberos realms
is not included; however, transitive trust is supported
between Windows 2000 domains in the domain tree.
• The KDC does not support post-dated tickets.
• Any upgraded user accounts and the administrator
account in a new domain must have the password
changed before non-Windows Kerberos clients can use
them.
University of Tulsa - Center for Information Security
Kerberos in Linux
University of Tulsa - Center for Information Security
A Few Words in Linux
• No simple way of migrating passwords from
Unix databases to Kerberos databases
• Only partly compatible with Pluggable
Authorization Modules (PAM’s)
• Applications have to be source modified to use
Kerberos to authenticate
• Adoption of Kerberos is all or nothing.
University of Tulsa - Center for Information Security
QuEsTiOnS?
University of Tulsa - Center for Information Security
References
• http://web.mit.edu/is/help/kerberos/whatis.html
• http://web.mit.edu/kerberos/www/dialogue.html
• http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=18
University of Tulsa - Center for Information Security