ISA 662 Internet Security Protocols Kerberos Prof. Ravi Sandhu

2 © Ravi Sandhu SYSTEM MODEL NETWORK WORK- STATIONS SERVERS WS NFS GOPHER LIBRARY KERBEROS

3 © Ravi Sandhu PHYSICAL SECURITY CLIENT WORKSTATIONS None, so cannot be trusted SERVERS Moderately secure rooms, with moderately diligent system administration KERBEROS Highly secure room, with extremely diligent system administration

4 © Ravi Sandhu KERBEROS OBJECTIVES provide authentication between any pair of entities primarily used to authenticate user-at- workstation to server in general, can be used to authenticate two or more secure hosts to each other on an insecure network servers can build authorization and access control services on top of Kerberos

5 © Ravi Sandhu TRUST: BILATERAL RHOSTS MODEL A B C E G F AB A trusts B A will allow users logged onto B to log onto A without a password

6 © Ravi Sandhu TRUST: CONSOLIDATED KERBEROS MODEL ABCDEF KERBEROS

7 © Ravi Sandhu TRUST: CONSOLIDATED KERBEROS MODEL breaking into one host provides a cracker no advantage in breaking into other hosts authentication systems can be viewed as trust propagation systems the Kerberos model is a centralized star model the rhosts model is a tangled web model

8 © Ravi Sandhu WHAT KERBEROS DOES NOT DO makes no sense on an isolated system does not mean that host security can be allowed to slip does not protect against Trojan horses does not protect against viruses/worms

9 © Ravi Sandhu KERBEROS DESIGN GOALS IMPECCABILITY no cleartext passwords on the network no client passwords on servers (server must store secret server key) minimum exposure of client key on workstation (smartcard solution would eliminate this need) CONTAINMENT compromise affects only one client (or server) limited authentication lifetime (8 hours, 24 hours, more) TRANSPARENCY password required only at login minimum modification to existing applications

10 © Ravi Sandhu KERBEROS DESIGN DECISIONS Uses timestamps to avoid replay. Requires time synchronized within a small window (5 minutes) Uses DES-based symmetric key cryptography stateless

11 © Ravi Sandhu KERBEROS VERSIONS We describe Kerberos version 4 as the base version Kerberos version 5 fixes many shortcomings of version 4, and is described here by explaining major differences with respect to version 4

12 © Ravi Sandhu NOTATION cclient principal sserver principal K x secret key of x (known to x and Kerberos) K c,s session key for c and s (generated by Kerberos and distributed to c and s) {P}K q P encrypted with K q T c,s ticket for c to use s(given by Kerberos to c and verified by s) A c,s authenticator for c to use s (generated by c and verified by s)

13 © Ravi Sandhu TICKETS AND AUTHENTICATORS T c,s ={s, c, addr, time o, life, K c,s }K s A c,s ={c, addr, time a }K c,s addris the IP address, adds little removed in version 5

14 © Ravi Sandhu SESSION KEY DISTRIBUTION Kerberos ClientServer c, s {T c,s, K c,s } K c T c,s, A c,s 1 2 3

15 © Ravi Sandhu USER AUTHENTICATION for user to server authentication, client key is the users password (converted to a DES key via a publicly known algorithm)

16 © Ravi Sandhu TRUST IN WORKSTATION untrusted client workstation has K c is expected to delete it after decrypting message in step 2 compromised workstation can compromise one user compromise does not propagate to other users

17 © Ravi Sandhu AUTHENTICATION FAILURES Ticket decryption by server yields garbage Ticket timed out Wrong source IP address Replay attempt

18 © Ravi Sandhu KERBEROS IMPERSONATION active intruder on the network can cause denial of service by impersonation of Kerberos IP address network monitoring at multiple points can help detect such an attack by observing IP impersonation

19 © Ravi Sandhu KERBEROS RELIABILITY availability enhanced by keeping slave Kerberos servers with replicas of the Kerberos database slave databases are read only simple propagation of updates from master to slaves

20 © Ravi Sandhu USE OF THE SESSION KEY Kerberos establishes a session key K c,s session key can be used by the applications for client to server authentication (no additional step required in the protocol) mutual authentication (requires fourth message from server to client {f(A c,s )}K c,s, where f is some publicly known function) message confidentiality using K c,s message integrity using K c,s

21 © Ravi Sandhu TICKET-GRANTING SERVICE Problem: Transparency user should provide password once upon initial login, and should not be asked for it on every service request workstation should not store the password, except for the brief initial login Solution: Ticket-Granting Service (TGS) store session key on workstation in lieu of password TGS runs on same host as Kerberos (needs access to K c and K s keys)

22 © Ravi Sandhu TICKET-GRANTING SERVICE Kerberos Client c, tgs {T c,tgs, K c,tgs } K c 1 2 deleted from workstation after this exchange (have to trust the workstation) retained on the workstation

23 © Ravi Sandhu TICKET-GRANTING SERVICE TGS ClientServer {T c,s, K c,s } K c,tgs T c,tgs, A c,tgs, s T c,s, A c,s

24 © Ravi Sandhu TICKET LIFETIME Life time is minimum of: requested life time max lifetime for requesting principal max lifetime for requesting service max lifetime of ticket granting ticket Max lifetime is 21.5 hours

25 © Ravi Sandhu NAMING Users and servers have same name format: Example: Mapping of Kerberos authentication names to local system names is left up to service provider

26 © Ravi Sandhu KERBEROS V5 ENHANCEMENTS Naming Kerberos V5 supports V4 names, but also provides for other naming structures such as X.500 and DCE Timestamps V4 timestamps are Unix timestamps (seconds since 1/1/1970). V5 timestamps are in OSI ASN.1 format. Ticket lifetime V4 tickets valid from time of issue to expiry time, and limited to 21.5 hours. V5 tickets have start and end timestamps. Maximum lifetime can be set by realm.

27 © Ravi Sandhu KERBEROS V5 ENHANCEMENTS Kerberos V5 tickets are renewable, so service can be maintained beyond maximum ticket lifetime. Ticket can be renewed until min of: requested end time start time + requesting principals max renewable lifetime start time + requested servers max renewable lifetime start time + max renewable lifetime of realm

28 © Ravi Sandhu KERBEROS INTER-REALM AUTHENTICATION Kerberos Realm 1 Kerberos Realm 2 shared secret key clientserver

29 © Ravi Sandhu KERBEROS INTER-REALM AUTHENTICATION Kerberos V4 limits inter-realm interaction to realms which have established a shared secret key Kerberos V5 allows longer paths For scalability one may need public- key technology for inter-realm interaction

30 © Ravi Sandhu KERBEROS DICTIONARY ATTACK First two messages reveal known- plaintext for dictionary attack first message can be sent by anyone Kerberos v5 has pre-authentication option to prevent this attack