Kerberos

1. Kerberos Anita Jones November, 2006

2. Kerberos * : Objective • Assumed environment • Open distributed environment • Wireless and Ethernetted • Users wish to access services on servers • Need to restrict access to authorized users • Need to authenticate requests for service * Greek mythology – many headed dog who guards the entrance to Hades * Implemented at MIT as part of Project Athena

3. Kerberos : Objective • Provide authentication service • Clients to servers • Servers to clients

4. Kerberos: Strategy • What NOT to do: • Does not rely on workstation OS to assure identity of clients/users • Does not rely on server to provide stand-alone authentication service • Does not force clients to prove identity over and over • Does not rely on client to determine identity of each service invoked • Provide an authentication service

5. When is authentication useful? • Once per creation of new user • Once per user logon session • Once per type of service • Once per service session • Once per service request Kerberos provides the middle three services

6. Kerberos: Strategy • “Knows” about the existence of users and servers • Shares (different) symmetric key with each • More recent versions of Kerberos use public/private keys • We will not discuss key distribution here • Uses “capabilities” – calls them “tickets” • Key property – tickets are unforgeable • Passes out tickets on request • Key points – form of the tickets, when they are useful, and where they are useful

7. Kerberos: Strategy – more detail • Kerberos has a table of • Identity of users & servers • Net address of clients & servers • Current user password • Key/password distribution, i.e. initialization & update discussed earlier in course • Uses DES for encryption • Kerberos provides a “Ticket granting server” (tgs). Tickets that it creates must be • Unforgeable • Non-replayable • Authenticated

8. Assumption – key sharing • Kerberos composed of AS plus TGS • AS (authentication server) shares a secret key with each user • Typically called IDC – C is the client machine • TGS (ticket granting server) • TGS shares secret key with each known server • Server machine and server software notated as the same • Each user and service share a secret key

9. Three authentication services • Transactions: • Authenticate user – client machine talks to AS (authentication service) when user logs on • User receives authentication ticket (ticket-granting ticket) • Get ticket to use a server – client machine talks to TGS when user first wants to use a particular service • User receives a service-granting ticket • Service session – client workstation proffers ticket to server that is good for the session • User may require server to authenticate self to user

10. Protocol 1 – get ticket-granting ticket simple illustration • Once per client logon session: • C  AS: IDC , IDtgs • AS  C: EKC [ tickettgs ] Notes: “comma” indicates concatenation AS is authentication service of Kerberos IDC – name of the user on client C IDtgs – client C is asking for TGS service from Kerberos EKC is encryption with key derived from C’s password tickettgs – ticket C uses to get service from TGS

11. Ticket (ticket-granting ticket) from TGS tickettgs = EKtgs[ IDC , ADC , IDtgs , Time1 , Lifetime1 ] Notes: EKtgs – key known only to AS and TGS IDC – identity of client C ADC – network address of C Time1 – TGS-created time stamp Lifetime1 – ticket lifetime

12. Prot’l 2 – get service-granting ticketsimple illustration • Get service-granting ticket – at first request for a particular service • C  TGS: IDC , IDv , tickettgs • TGS  C: ticketv Notes: ticketV is ticket that server V will accept as valid TGS knows whether IDC is allowed to use service V ticketV has same form as tickettgs

13. Ticket (service V) from TGS ticketV = EKVTGS[ IDC , ADC , IDV , Time2 , Lifetime2 ] Notes: EKVtgs – key known only to TGS and V IDC – identity of user on client C ADC – network address of C Time2 – TGS created time stamp Lifetime2 – ticket lifetime

14. Protocol 3 – to obtain the servicesimple illustration • Once per service session: • C  V: IDC , ticketV Note: C gives user name & submits ticket for V’s service

15. It ain’t quite that simple • Tickets are a little more complex • Time stamps – limit replay of requests for tickets • Ensure clocks of various computers are sufficiently in synch • Tickets have a “lifetime” validity stamp • We have not dealt with users who rove among multiple workstations • Client/user and the client’s workstation OS are not the same thing

16. Protocol 1 – more complete get ticket-granting ticket • Once per client logon session: • C  AS: IDC , IDtgs , Time1 • AS  C: EKC [KC,tgs , IDtgs , Time2 , • Lifetime2 , tickettgs] Notes: Time1 is time from C’s clock; AS assures that clocks are sufficiently in synch EKC – encryption with key derived from IDC’s password KC,tgs – session key created by TGS; permits secure exchange for AS & IDC for the session

17. Full Ticket-granting ticket tickettgs = EKtgs[ KC,tgs , IDC , ADC , IDtgs , Time2 , Lifetime2] Notes: EKtgs – key known only to AS and TGS KC,tgs – session key available to user; permits secure exchange for TGS & C for the session IDC – identifier for user on machine C ADC – network address of machine C Time2 – time stamp created for this ticket Lifetime2 – ticket lifetime

18. Prot’l 2 – get service-granting ticketfuller illustration • Get service-granting ticket – at first request for a particular service • C  TGS: IDv , tickettgs , authC • TGS  C: EKC,tgs[KC,V , IDV , Time4 , • ticketV ] Note: ticketV – ticket that server will accept as valid and then deliver service KC,V – secure session key that C and server V use authC – generated by user to validate ticket; encrypted with KC,tgs

19. Full service-granting ticket ticketv = EKVtgs[ KC,V , IDC , ADC , IDV , Time4 , Lifetime4] Notes: EKVtgs – key derived from server’s password; known only to TGS and V; prevents tampering KC,V – session key available to user; permits secure exchange for V & IDC for the session IDC – identifier of user on C; ditto V ADC – network address of C Time4 – time stamp created for this ticket Lifetime4 – ticket lifetime

20. Authenticator (authC) authC = EKC,tgs[ IDC , ADC , Time3 ] Notes: Authenticator created by user to assure TGS that ticket presenter is same as user for whom ticket was issued; intended for one time use; timestamp limits replay KC,tgs – session key available to user; permits secure exchange for TGS &IDC for the session Time3 – time stamp created for this authenticator

21. Protocol 3 – to gain service fuller illustration • Once per service session: • C  V: ticketV , authC • V  C: EKc,v[Time5 + 1] Note: Step 2 is for server V to authenticate to client C authC is similar to that in protocol 2; includes Time5

22. Authenticator (authC) authC = EKC,V[ IDC , ADC , Time5 ] Notes: Authenticator created by user to assure V that ticket presenter is same as user for whom ticket was issued; intended for one time use; timestamp limits replay KC,V – session key available to user and V permits secure session exchange for V & IDC Time5 – time stamp created for this authenticator

23. Kerberos – End