Kerberos
========

Kerberos is covered in the text in Chapter 23, Section 23.1

Protocol A
----------

Client -> AS      ID_c || P_c || ID_v

   ID_c: ID of the client (username)
   P_c : Password of the client
   ID_v: ID of the serVice the client wishes to use.

    AS -> Client  Ticket

   Ticket: E_{Kv}[ID_c || AD_c || ID_v]

Client -> V       ID_c || Ticket

   Problem 1: The password is sent in the clear.
   Problem 2: A different ticket is needed for each service.


Protocol B
----------

Introduces a Ticket-Granting-Service.

Once per logon session:
  Client -> AS      ID_c || ID_{tgs}
      AS -> Client  E_{Kc}[Ticket_{tgs}]   Kc is derived from the client's password.

  Ticket_{tgs} = E_{Ktgs}[ID_c || AD_c || ID_tgs || TS_1 || Lifetime_1]

Once per each type of service:
  Client -> TGS     ID_c || ID_v || Ticket_{tgs}
     TGS -> Client  Ticket_v

  Ticket_v = E_{Kv}[ID_c || AD_c || ID_v || TS_2 || Lifetime_2]

Once per each session with a service:
  Client -> V       ID_c || Ticket_v

    Problem 1: With any reasonable lifetime an attacker might be able to use a captured ticket.
    Problem 2: Clients might want to authenticate servers.

Note that to take advantage of Problem #1, the attacker would need to use the same workstation
(the same AD_c) as the original user. This isn't unrealistic; the original user might finish
what she is doing and walk away while the ticket previously captured by the attacker is still
valid. Another possibility would be for the attacker to spoof AD_c from a different workstation.
However, spoofing can be difficult. Server replies will go to the address being spoofed and not
to the attacker's machine. This makes it complicated to engage in a non-trivial protocol using a
spoofed address.

Kerberos v4
-----------

  Client -> AS      ID_c || ID_{tgs} || TS_1
      AS -> Client  E_{Kc}[ K_{c,tgs} || ID_tgs || TS_2 || Lifetime_2 || Ticket_{tgs}]

  Ticket_{tgs} = E_{Ktgs}[ K_{c,tgs} || ID_c || AD_c || ID_{tgs} || TS_2 || Lifetime_2 ]

The Ticket_{tgs} is the "ticket granting ticket."

  Client -> TGS     ID_v || Ticket_{tgs} || Authenticator_c
     TGS -> Client  E_{Kc,tgs}[K_{c,v} || KD_v || TS_4 || Ticket_v]

  Ticket_v = E_{Kv}[ K_{c,v} || ID_c || AD_c || ID_v || TS_4 || Lifetime_4]
  Authenticator_c = E_{Kc,tgs}[ID_c | AD_c || TS_3]

  Client -> V       Ticket_v || Authenticator_v
       V -> C       E_{Kc,v}[TS_5 + 1]

  Authenticator_v = E_{Kc,v}[ID_c || AD_c || TS_5]

The Authenticator is encrypted using a key that is inside the ticket (thus a D-Y attacker can't
get at it). This effecitively links the ticket and the authenticator. The recipient checks that
the time in the authenticator is close to the current time (requiring time synchronization on
the network) to verify that the message is not a replay. A D-Y attacker can't create a valid
authenticator on an attempted reply because he can't encrypt it properly.