The design of a tutorial to illustrate the Kerberos protocol

1
The design of a tutorial to illustrate the
Kerberos protocol

• Lindy Carter
• Supervisors Prof Wentworth
• John Ebden

2
Objectives

• To design a teaching approach and tutorial to
  teach complex protocols
• Kerberos as the chosen example

3
Introduction

• Authentication protocol used to identify
  principals on a network using only a single
  sign-on
• Uses authentication based on cryptography and was
  developed by MIT to replace authentication based
  on assertion
• Chosen by Microsoft to replace NTLM as the method
  for authentication in Window 2000
• Name come from the 3 headed dog in Greek
  mythology Cerberus who used to guard the gates
  of Hades

4
The problem with teaching Kerberos

• Not easy to conceptualize
• Formal definitions use a once over type of
  approach and are very technical
• Important concepts are presented in the same step
• Formal definitions use complicated notation

5
What we have done to solve the problem

• We have divided our explanation into 2 passes
• The first pass uses a concrete metaphor to
  explain the 3 message exchanges in the protocol
• The second pass is broken down into 3 phases and
  uses another metaphor to explain the message
  exchanges, encryption and key sharing
• We want start with concrete explanations and move
  towards more abstract ideas

6
Pass 1

• Uses a club membership example
• The process of joining a club and using its
  affiliated facilities is similar in Kerberos to
  authenticating yourself and asking to use a
  resource.

7
Pass 2

• Uses a coloured envelope metaphor
• We chose the envelope metaphor because it
  illustrates the 2 level structure of tickets.
• The coloured envelopes show encryption key pairs

8

• Pass is divided into 3 phases
• Phase 1 describes the 3 message exchanges in a
  trusted environment
• Phase 2 introduces long term key sharing
• Phase 3 introduces sessions and session key
  generation

9
Pass 1 Club membership
Club Membership metaphor Kerberos
1 A person wants a membership card to the umbrella body in order for him to use affiliated facilities. The user presents his ID book or student card to prove his identity, pays for certain facilities, and he is then issued with a membership card containing his membership rights. The user requests a ticket granting ticket to use the ticket granting service. The user is authenticated and the ticket granting ticket containing his access rights is issued to him.
2 When the member wants to use an affiliated facility, he presents his membership card to the facility office. The office checks to see if the member is allowed to use the facility by looking at the members membership rights. If the member is allowed to use the facility he is requesting, the office issues him with a facility ticket. The user wishes to use a resource. He presents his ticket granting ticket to the ticket granting service to ask for a resource ticket. The ticket granting service checks the access rights in the ticket granting ticket and if the user has rights to the resource that he as requested, a resource ticket it issued to the user.
3 To use the facility, the members presents the facility ticket to the gatekeeper of the facility he is wanting to use. To use the resource, the user presents the resource ticket to the resource server.
10
Phase 1
Authentication Server Exchange
11
Phase 1
Ticket Granting Service Exchange
12
Phase 1
Resource Server Exchange
13
Some Observations

• There is no direct communication between the
  Authentication Server, Ticket Granting Service of
  the Resource Server
• Tickets are reusable

14
Problems with Phase 1

• Principals that receive tickets do not actually
  know who sent the ticket.
• The access rights in the tickets are in plain
  text and the user is able to change them

15
Phase 2

• First problem is easy to solve - each time the
  user sends a ticket to a principal, he sends his
  name along with the ticket
• Second problem a little more involved

16
Phase 2

• The user needs to authenticate himself to the
  Authentication Server and the Authentication
  Server needs to pass information securely back to
  the user
• The user and AS need to share a long term key
  (users password (black key)
• The Authentication Server needs to pass
  information securely to the Ticket Granting
  Service
• AS and TGS need to share a long term key (red
  key)

17
Phase 2

• The Ticket Granting Service needs to pass
  information securely to the Resource Server
• TGS and RS need to share a long term key (blue
  key)

18
Long term key sharing
Authentication Server
Ticket Granting Service
Resource Server
19
Problems with Phase 2

• Some one listening on the network can intercept
  the message containing the ticket and the users
  name.
• They will be able to change the name and use the
  resource

20
Phase 3

• The user should encrypt his name before he sends
  it to the TGS or RS (this is called an
  authenticator)
• The user needs a communication channel to
  communicate with the TGS and RS
• Sessions keys are generated via a third party.
• A copy of the key is given to the user in his
  reply message for a ticket.
• Another copy is embedded in the ticket that the
  user is receiving back

21
Phase 3

• When the TGS or RS receive the ticket and
  authenticator, it is able to decrypt the ticket
  and retrieve the session key
• TGS or RS is then able to decrypt the
  authenticator and see who is requesting service.

22
Key Sharing
Authentication Server
Ticket Granting Service
Resource Server
Generates session key
Generates session key
Long term Key
Session Key
23
Finally

1. AS exchange
2. TGS exchange
3. RS exchange

Authentication Server
Ticket Granting Service
1
2
Resource Server
3
24
Questions