1. Kerberos 1

2. Design Goal
Allow the sharing of a secret key between any two users who only share a password with a trusted server. 2

3. Needham-Schroeder protocol
Alice
Server
Bob
Alice, Bob, NA
{NA, KAB, Bob, {KAB,Alice}KBS}KAS
Kas and Kbs are derived from Alice’s and Bob’s password.
Problems: if Kab is revealed, an adversary can replay the first message from Alice to Bob and hope Bob doesn’t find it is a replay.
Also, Alice needs to keep her password (permanent) in memory, or ask password every time open a new session.
Better to use password at startup only because less (possibly malicious) software running on computer. Better also not to keep password in memory in case an attacker takes control of the computer.
{KAB,Alice}KBS
{NB}KAB
{NB-1}KAB 3

4. Needham-Shroeder protocol is susceptible to a replay attack
An adversary only has to record the message Alice sends to Bob to cause the same session key to be used again.

5. Kerberos 4 Obtaining session key and TGT
Alice
Server (AS)
[AS_REQ] Alice needs TGT
[AS_REP] {SA || IDTGS || TS1 || Lifetime1 || TGT}KA
In Kerberos doc, AS_REQ is called KER_AS_REQ for Kerberos Authentication Server Request
AS_REP = Authentication Server Reply
Note: slightly inefficient: the TGT is doubly encrypted
SA: session key that Alice will share with the TGS
IDTGS: name of the TGS
IDA : name of Alice
ADA : IP address of Alice
TS1 : Timestamp
TGT is called a ticket-granting ticket
TGT = {SA || IDA || ADA || IDTGS || TS1 || Lifetime1}KTGS

6. Kerberos 4 Talking to remote node
Alice
Server (TGS)
[TGS_REQ] Bob, TGT, {IDA || ADA || TS2}SA
[TGS_REP] {KAB || IDB || TS3 || Ticket }SA
TGS_REQ = Ticket Granting Server Request
TGS_REP = Ticket Granting Server Reply
KAB : session key that Alice will share with Bob
Ticket = {KAB || IDA || ADA || IDB || TS3 || Lifetime3}KB 6

7. Kerberos 4 Talking to remote node
Alice
Bob
[AP_REQ] Ticket || {timestamp}KAB
[AP_REP] {timestamp + 1}KAB
{timestamp}Ka is called an authenticator, is serves to prove that Alice knows the session key. It is not really necessary here since the TGS reply is useless to someone who doesn’t know the session key.
The authenticator actually contains a few other fields that will be described later.
In practice, the AS and TGS are usually the same - different names probably come from time when TGS only gave key to a server, not any other user, in order to keep the user database, and the server database separate. It is common to call the combined server a KDC (Key Distribution Center) 7

8. Duplicate KDCs and Realms
Multiple KDCs to avoid single point of failure and bottleneck
Consistency maintained by having a single master and multiple ‘read-only slaves’
KDCs are split in different realms
All KDCs in a given reals have same master key
KDCs of different realms have different master keys and different user database.
A ‘name’ in Kerberos 4 consists of Name, Instance and Realm
Realms are used to reduce the impact of compromised KDCs + not everyone may be willing to trust a single entity

9. Interrealm communication
For to communicate with Realm2 has to be a ‘user’ in Realm1
Alice
[TGS_REQ]
[TGS_REP] (Session key to R2)
No longer chains of KDCs are allowed, to prevent rogue KDC from impersonating anybody by pretending to be second to last KDC in chain.
[TGS_REQ] in new session key
[TGS_REP] (Session key to 9

10. Privacy and Integrity in Kerberos 4
Many Kerberos message need to be private and correct (all messages containing keys for example)
Most common method to ensure both privacy and integrity is to first encrypt then mac, but this tends to require two passes on the message.
To avoid this, the designers of Kerberos invented their own block cipher mode of operation: Plaintext (or Propagating) Cipher Block Chaining
It’s actually pretty easy to break integrity 10

11. Privacy and Integrity in Kerberos 4m1 m2 m3 m4 IV
DES
DES
DES
DES c1 c2 c3 c4
CBC 11

12. Privacy and Integrity in Kerberos 4m1 m2 m3 m4 IV
DES
DES
DES
DES
Modify any ciphertext block and you modify all the subsequent message blocks. Kerberos puts some recognizable info at the end.
However, swap two adjacent blocks and only those two blocks will not decrypt correctly.
As a result, as long as you only swap the blocks in the middle, but keep the last block at the end, the last block will decrypt correctly. While this does not necessarily imply that an attacker could modify the message at will, it is a break of usual definitions of integrity. c1 c2 c3 c4
PCBC 12

13. Integrity Only
Use a modified Jueneman checksum appended at the end of the message
Never broken, but never proven secure either. 13

14. Network Address in Ticket
Prevent theft of authenticator and ticket within 5 minutes (and unencrypted session to Bob)
Prevent delegation…but might be desirable
Delegation can be interesting if, for example, you want a different computer to run a batch job for you, but that job requires a service provided by a server that requires Kerberos authentication. 14

15. Why Bob name/instance
If many services at the same location, immediately know which key to use
No confusion if many services use the same key
There’s a silly example in the textbook about the president of the United States and one of his generals simultaneously considering launching nuclear missiles at a target, and playing a game. If then the president tells the general “Nuke them all!” without saying which application he’s talking about, the general won’t know if he’s supposed to kill an enemy in game, or launch the missile (quite an example, eh?) 15

16. Attacks on Kerberos 4
Offline dictionary attack simply by requesting a TGT
Integrity not guaranteed for encrypted messages
Many implementations have buffer overflow vulnerabilities
Since Alice’s password is not required to send an AS_REQ, anybody can pretend to be Alice and obtain a ticket encrypted using Alice’s permanent key. It is a simple matter then to run a dictionary attack – the correct password is the one that correctly decrypts the ticket.
Many suggest not to even support Kerberos 4, mostly because of the buffer overflows.

17. Other Limitations of Kerberos 4
Name and Instance fields are limited to 40 bytes
Lifetime of ticket is a 1 byte (intervals of 5 minutes) → maximum lifetime of ~21 hours
Double encryption in AS_REP and TGT_REP

18. Kerberos 5 Fixes some design flaws in Kerberos 4
Adds new functionalities, allows greater flexibility
spec now 133 pages long

19. Kerberos 5 Use ANS.1 syntax
Allows optional fields, fields of variable length
Adds overhead (4 byte address in ver.4 becomes 11 bytes in ver.5)
Name no longer limited to 40 characters, no longer need for Instance field.
Instead of using Name=Alice and Instance=Firefox, Kerberos 5 would use Name=Alice.Firefox

20. Cleanups Ticket no longer doubly-encrypted
More flexible cryptographic algorithms
Fix integrity protection (not PCBC or Jueneman)
The cryptographic algorithms were included in the implementation of Kerberos 4, which make it impossible to export it out of the USA (because 40+ bit crypto was classified as ammunition). Kerberos 5 is more modular, and the actual implementation of crypto is not included. The user has to add modules with crypto algorithms.

21. Preventing Dictionary Attack
Requires an authenticator to obtain a TGT
Server (AS)
Alice
[AS_REQ] Opt || IDA || RealmA || IDtgs || Times || N1, {IDA || RealmA, TS}KA
Opt: Options
Times: begin and end time of validity
Flags: information about options passed to TGT
The other codes are the same as before.
[AS_REP] RealmA || IDA || Tickettgs || {KA,tgs || Times || N1 || Realmtgs || IDtgs}KA
Tickettgs = {Flags || KA,tgs || RealmA || IDA || ADA || Times]Ktgs
Note that this is still vulnerable to eavesdropper
(but this is unavoidable)

22. Preventing Dictionary Attack
A user could still get a ticket encrypted with another user’s key by making a TGS_REQ on that user
In Kerberos 5, KDC database contains flag to prevent issue of a ticket to users whose key is derived from a password
At the time the password are set, the user can ask the server never to encrypt tickets using the key derived from his password. This technically goes against the goal of Kerberos (which is to enable any two parties communicate). Kerberos 5 just leaves it up to users to decide what they want to do.
It is possible to get a ticket to Bob without using his permanent key by using Double Ticket Authentication (which will be explained later).

24. Delegation of Rights
In Kerberos 4, Alice could not give her session key and TGT to Bob since TGT contains network address
Had to either give your password or your TGT or session key (problem: tickets contain IP addresses)
In Kerberos 5, Alice can request a TGT with a network address other than her own
TGTs can also be proxiable, ie can be used to obtain tickets for a different address (but the TGT can only be used by Alice)

25. Ticket Lifetime
In Kerberos 4, 4 byte start time, 1 byte lifetime (~21 hours)
In Kerberos 5, tickets have start time, end time, authtime and renew-till (each 17 bytes)
Lifetime now just about unlimited, but time in seconds (added 5 byte for microseconds)
Allow renewable tickets and postdated tickets.
Renewable ticket as to be renewed at regular interval. Every time a ticket is renewed, a new ticket is sent with an update to the authtime (last authentication time). That way, the server only has to keep track of revoked tickets for the renewal interval.
For example, if Alice’s ticket has to be renewed every day, and the server decides to revoke her ticket, it only needs to keep Alice’s name on the revocation list for one day (and refuse Alice’s renewal requests for that day). After that, there is no longer need to keep Alice’s name on the revocation list since her ticket will be refused anyway because it has not been renewed every day. 25

26. Different Realm, Different Key
In Kerberos 4, the permanent key depended on password only
→ same password in different realms meant
same key
In Kerberos 5, the realm is name is part of function for key derivation
If a KDC is compromised and a permanent key is revealed, permanent keys in other realms (and password) are still safe – but vulnerable to dictionary attack

27. Cryptographic Algorithms
Integrity: Kerberos 5 abandoned the Jueneman checksum for better algorithms, but not yet ‘provably secure algorithms’
rsa-md5-des (r)
des-mac (r) des-mac-k (r)
rsa-md4-des (o) rsa-md4-des-k (o)

28. Interrealm Authentication
Authentication through a chain of KDC is allowed in Kerberos 5
Added a TRANSITED field that lists all the KDCs in the chain
Bob can decide on whether or not to accept a ticket according to that list
KDCs often organized in a tree – realms share keys with parent and children
Path through lowest common ancestor (finding path up to user)
Check that even if there is a malicious server in the chain of KDCs, there will be at least one of the malicious servers on the TRANSITED field. 28

29. Double TGT Authentication
When Alice makes a TGS_REQ, she sends both her TGT and Bob’s TGT, then the ticket to Bob in TGS_REP is encrypted with Bob’s session key
To avoid use of permanent key
In case Bob ‘forgets’ his master key but remembers his session key
Inspired by XWINDOWS.
In XWINDOWS, the display terminal acts as Bob and the application server acts like Alice. The display doesn’t want to keep Bob’s password in memory throughout the session. 29

30. Public Keys
If users had public keys, could use them to authenticate themselves to server instead of password
But if everyone has a public key with trusted certificate, what’s the use of Kerberos at all?
Even if Bob trusts Alice, he may not trust her hardware to produce sufficiently random keys, so he would prefer that the key be produced by a trusted server.

31. 2005: Overhaul of Kerberos 5 New crypto must be supported:
AES256-CTS-HMAC-SHA1-96
HMAC-SHA1-96-AES256