Kerberos

1
Kerberos
2

• Assume an open distributed environment in which
  users at workstations wish to access services on
  servers distributed throughout the network.

3
Threats

• A user may gain access to a particular
  workstation and pretend to be another user
  operating from that workstation.
• A user may eavesdrop on exchanges and use a reply
  attack to gain entrance to a server or to disrupt
  operations.
• A user may alter the network address of a
  workstation so that the requests sent from the
  altered workstation appear to come from the
  impersonated workstation.

4
Kerberos

• A secret key based service for providing
  authentication in open networks
• Authentication mediated by a trusted 3rd party on
  the network
• Key Distribution Center (KDC)

5
Key Distribution

• At many points so far, we have run into problems
  with using cryptography for network security.
• How can we securely store and distribute key and
  password information?
• How can we certify that keys and password are
  safe and to be trusted?
• To solve these issues, we make use of a variety
  of trusted intermediaries.

6
Trusted Intermediaries

• Symmetric key problem
• How do two entities establish shared secret key
  over network?
• Solution
• trusted key distribution center (KDC) acting as
  intermediary between entities

• Public key problem
• When Alice obtains Bobs public key (from web
  site, e-mail, diskette), how does she know it is
  Bobs public key, not Trudys?
• Solution
• trusted certification authority (CA)

7
Key Distribution Centers (KDCs)

• Alice, Bob need shared symmetric key.
• KDC server shares different secret key with each
  registered user (many users).
• Alice, Bob know own their symmetric keys, KA-KDC
  and KB-KDC , for communicating with KDC.

KDC
8
Key Distribution Centers (KDCs)
Q How does KDC allow Bob, Alice to determine
shared symmetric secret key to communicate with
each other?
KDC generates R1
KA-KDC(A,B)
KA-KDC(R1, KB-KDC(A,R1) )
Alice knows R1
Bob knows to use R1 to communicate with Alice
KB-KDC(A,R1)
Alice and Bob communicate using R1 as session
key for shared symmetric encryption
9
Key Distribution Centers (KDCs)

• Problems
• How are the keys shared with the KDC originally
  agreed upon and distributed?
• Most approaches assume some form of manual key
  generation and distribution with the KDC.
• The KDC is a critical, centralized part of
  network infrastructure.
• This makes the KDC subject to interruption
  attacks to disrupt the general security of the
  network.
• How does this approach scale?
• A single KDC can not service all users of the
  Internet!
• To scale, we require a collection of KDCs, that
  work together for key distribution.

10
What is authentication?

• Positive verification of identity (man or
  machine)
• Verification of a persons claimed identity
• Who are you? Prove it.
• 3 Categories
• What you know
• What you have
• Who you are

11
What you know

• Password
• Pass phrase
• PIN

12
What you have

• Digital authentication
• physical devices to aid authentication
• Common examples
• eToken
• smart cards
• RFID- Radio Frequency Identification-(Integrated
  circuit(s) with an antenna that can respond to an
  RF signal with identity information)

13
eToken

• Can be implemented on a USB key fob or a smart
  card
• Data physically protected on the device itself
• On the client side, the token is accessed via
  password
• Successful client-side authentication with the
  password invokes the token to generate a stored
  or generated passcode, which is sent to the
  server-side for authentication.

14
Who you are

• Physical Biometrics
• Behavioral Biometrics

15
Physical Biometrics

• Fingerprint
• Iris
• Ear Shape
• Retina

• Smell
• Thermal Face
• Nail Bed
• DNA

16
Behavioral Biometrics

• Signature
• Voice
• Keystroke
• Gait

17
Review Three Categories

• What you know
• Password
• PIN
• What you have
• e-Token
• RFID
• Who you are
• Biometrics

18
Motivation

• Real-world considerations
• What you know and what you have
• Can be stolen or forgotten
• Susceptible to replay attacks
• Who you are
• Unique biometrics that hinder replay attacks and
  imposters

19
Three approaches to security

• Rely on each individual client workstation to
  assure the identity of its users and rely on each
  server to enforce a security policy based on user
  identification (ID).
• Require that client systems authenticate
  themselves to servers, but trust the client
  system concerning the identity of its users.
• Require the user to prove identity for each
  service invoked. Also require that servers prove
  their identity to clients.

20

• In small, closed environment, the first or
  perhaps the second strategy may suffice.
• But in a more open environment. The third
  approach is needed.
• The third approach is supported by Kerberos.

21
Requirements for Kerberos

• Secure
• A network eavesdropper should not be able to
  obtain the necessary information to impersonate a
  user.
• Reliable
• Kerberos should be highly reliable and should
  employ a distributed server architecture, with
  one system able to back up another.
• Transparent
• Scalable

22
Kerberos

• Developed in 1988 at MIT as part of Project
  Athena.
• Athena was started in 1983 with the goal to
  provide campus-wide access to networked computing
  services.
• Security problems (eavesdropping, forging
  identities, and so on) made it clear that a
  security solution was needed Kerberos was the
  solution, based on Needham and Schroeders secret
  key protocol, with DES to handle encryption and
  decryption.
• Since then, Kerberos has been used to provide
  secure access for various networked file systems
  and computing environments.
• There are two commonly available versions of
  Kerberos, version 4 and version 5.

23
Kerberos A KDC in Practice

• At the heart of Kerberos is its own version of a
  Key Distribution Centre.
• Each Kerberos KDC is responsible for what is
  called a realm, the set of systems, servers and
  users the KDC knows about.
• In Kerberos version 5, facilities are provided to
  allow for multiple KDCs (in the same or different
  realms) to work together for authentication.
• Each KDC is logically comprised of two services
• Authentication Service (AS) authenticates user
  clients and provides access to the TGS, below.
• Ticket Granting Service (TGS) provides tickets
  and session keys to allow users to access
  particular services within the Kerberos realm.

24
Kerberos
KDC
Server
Client
25
Kerberos
KDC
Server id.
Authenticator
TGT
SK
SK
(ticket)
Server
Client
26
Kerberos
KDC
Server
SK
Client
Authenticator
27
Kerberos Keys and Tickets

• All communication in Kerberos is protected
  through symmetric key cryptography.
• Each client (user) and server in Kerberos has a
  secret key known only by the individual and the
  Kerberos Authentication Service. (To facilitate
  the process, users have passwords that are
  transformed to their secret key when needed.)
• For communication between everything else,
  session keys are used that generated by the
  Authentication Service or the Ticket Granting
  Service.
• Tickets are tokens issued to clients to present
  to a particular server to verify that the client
  was recently authenticated by Kerberos.
• Each ticket contains an expiry time and a session
  key for use by the client and the particular
  server.
• There are two kinds of tickets ticket-granting
  tickets (TGTs) for talking with the Ticket
  Granting Service and service tickets (STKs) for
  talking with individual servers.

28
Simple shared-secret based cryptographic
authentication
29
Add mutual authentication
30
Problems with this scheme

• Poor scaling properties
• Generalizing the model for m users and n
  services, requires a priori distribution of m x n
  shared keys
• Possible improvement
• Use trusted 3rd party, with which each user and
  service shares a secret key m n keys
• Also has important security advantages

31
Mediated Authentication

• A trusted third party mediates the authentication
  process
• Called the Key Distribution Center (KDC)
• Each user and service shares a secret key with
  the KDC
• KDC generates a session key, and securely
  distributes it to communicating parties
• Communicating parties prove to each other that
  they know the session key

32
(No Transcript)
33
Mediated Authentication
34
Mediated Authentication
35
(No Transcript)
36
The Kerberos Protocol

• Suppose a client C wants to communicate with a
  server S in a Kerberos version 5 realm.
• Step 1
• The first step is for the client to authenticate
  itself with the Kerberos Authentication Service
  and request a Ticket Granting Ticket.
• This requests a ticket for client (C) for the
  Ticket Granting Service (TGS), with N1 as a
  timestamp nonce.

C
AS
C, KC-AS(TGS, N1)
37
The Kerberos Protocol

• Step 2
• When the Authentication Service receives the
  request, it decrypts the request and verifies the
  clients identity. It then generates a session
  key for the client and Ticket Granting Service to
  use, as well as a ticket. It sends
  backwhere TGT (C, TGS, T1, L1,
  KC-TGS) T1, L1 are the tickets timestamp and
  lifespan
• Since this is encrypted with Cs secret key, only
  the client can make use of it, and only the
  Authentication Service could have sent it.

C
AS
KC-AS(KC-TGS, KAS-TGS(TGT),N1)
38
The Kerberos Protocol

• Step 3
• With the client authenticated, it decrypts the
  response to get a session key for the Ticket
  Granting Service and a ticket-granting ticket.
• When the client needs to contact the server S, it
  creates a fresh authenticator (AUTH) and requests
  a ticket from the Ticket Granting
  Servicewhere AUTH(C, ADc, N3)

C
TGS
KC-TGS(AUTH), KAS-TGS(TGT), S, N2
39
The Kerberos Protocol

• Step 4
• The Ticket Granting Service decrypts the
  ticket-granting ticket and obtains the session
  key within it.
• The service decrypts the authenticator and
  compares client identifiers in the authenticator
  and ticket.
• The service generates a new session key for the
  client and server, as well as a service ticket,
  and sendswhere STK (C, S, T2, L2,
  KC-S) T2, L2 are the tickets timestamp and
  lifespan
• Since this is encrypted with the session key,
  only the client can make use of it, and only the
  Ticket Granting Service could have sent it.

C
TGS
KC-TGS(KC-S, KS-AS(STK),N2)
40
The Kerberos Protocol

• Step 5
• The client decrypts the response from the Ticket
  Granting Service to get the session key for the
  server and a service ticket to use with it.
• When the client needs to contact the server S, it
  creates a fresh authenticator (AUTH) and sends
  this, along with the service ticket, and its
  request Rwhere AUTH(C, N5)

C
S
KC-S(AUTH), KS-AS(STK), R, N4
41
The Kerberos Protocol

• Step 6
• The server decrypts the service ticket and
  obtains the session key within it.
• The server decrypts the authenticator and
  compares client identifiers in the authenticator
  and ticket.
• The server executes request R and replies with
  answer A, and the nonce in the clients
  request.
• Since this is encrypted with the session key,
  only the client can make use of it, and only
  server could have sent it. The session key can
  be used for additional requests in this session,
  and then destroyed.

C
S
KC-S(A, N4)
42
The Kerberos Protocol
C
AS
TGS
S
C, KC-AS(TGS, N1)
KC-AS(KC-TGS, KAS-TGS(TGT),N1)
KC-TGS(AUTH), KAS-TGS(TGT), S, N2
KC-TGS(KC-S, KS-AS(STK),N2)
KC-S(AUTH), KS-AS(STK), R, N4
KC-S(A, N4)
43
Kerberos Wrap-Up

• Through its ticket-granting capabilities, one can
  achieve scalability by having one KDC grant a
  ticket permitting a client to contact a KDC in
  another realm.
• But, we still have issues of setting up secret
  keys in the first place, and the potential for
  interruption attacks on the KDC itself.
• Furthermore, Kerberos depends on a good network
  time service to synchronize system times for
  accepting timestamps.
• This makes the time service a good target for
  interruption attacks too!

44
Multiple Realms

• KDCA KDCB must have registered with each other
• Chains longer than two KDCs not allowed (v.4)

Alice, KDCB
KDCA
ticket to KDCB
Alice
Alice, Bob
KDCB
ticket to Bob
Bob
AP_REQ