1. James Johnson

2. What is it?  A system of authenticating securely over open networks  Developed by MIT in 1983  Based on Needham-Schroeder Extended to fix vulnerabilities in Needham- Schroeder  Currently widely used in industry ActiveDirectory

3. Why do I care?  Managing users across a huge network of computers is a pain Individual users configured on each computer? LOL  Much easier to have a single authentication source  Kerberos provides this single source of authentication

4. How Does It Work?  Clients authenticated using username and password  Single sign on  User authenticates username-password once per session  From then on, permissions granted using cryptographic “tickets”

5. Cast of Characters  Principal (you)  Ticket Granting Service (TGS)  Key Distribution Center (KDC) TGS and KDC separate entities on same host  Service Server (SS)

6. Kerberos Authentication

7. Messages (User Auth)  User -> Client: User, Pass Key user = Hash(Password)  Client -> AS: User ID  AS->Client Session key: {Sess} Key user TGT: {Client ID, Client addr, validity period, Sess} Key server

8. Messages (Service Auth)  Client -> TGS {Client ID, Client addr, validity period, Sess} Key server, RequestedServiceID Authenticator: {Client ID, Timestamp} Sess  TGS -> Client Client-Server Ticket: {ClientID,Client addr, validitiy period, Session Client-Server } Key service {Session Client-Server } Sess

9. Messages (Service Request)  Client->Service Client-Server Ticket Authenticator: {Client ID,TimestampA} Session Client-Server  Service->Client {TimestampA+1} Session Client-Server

10. Domains/Realms  Kerberos designed to work across organizational boundaries  Each TGS constitutes a realm  Organizations can share “inter-realm keys”  Local AS issues TGT for remote TGS Encrypted with inter-realm key “Referral Ticket”

11. Transitive Domain Referral

12. Hierarchical Domains/Realms  Each realm shares a key with parent  Different key for each child  If no shared key between two realms, authentication path can be constructed

13. Typical Implementations  MIT  Heimdal Adds some functionality  Java  Microsoft Active Directory Kerberos + LDAP + RPC Does not use MIT software

14. Security/Implementation Concerns  Synchronize clocks NTP server  DO NOT USE KERBEROS 4  Single point of failure Harden servers  Consider redundancy of KDCs One primary master, many secondary slaves No automatic failover

15. Kerberos + OpenLDAP  Kerberos can use LDAP backend instead of DB file  Eases DB replication and user management  Easy to do – Ubuntu packages, howtos

16. Cross-Platform Integration  UNIX-only Kerberos networks are fairly straightforward All use MIT software  Windows screws everything up  Tools for integrating Linux/BSD into AD SAMBA Likewise Open Aspirin  SAMBA cannot act as a AD domain controller

17. Conclusions  Kerberos greatly eases user management in Enterprise  Allows for fine-grained control  Inter-platform operation can be taxing

18. Resources  http://technet.microsoft.com/en- us/library/bb742516.aspx http://technet.microsoft.com/en- us/library/bb742516.aspx  http://cryptnet.net/fdp/admin/kerby- infra/en/kerby-infra.html#overview http://cryptnet.net/fdp/admin/kerby- infra/en/kerby-infra.html#overview  http://tools.ietf.org/html/rfc4120 http://tools.ietf.org/html/rfc4120  http://www.kerberos.org/events/2010con f/2010slides/2010kerberos_panel2.pdf