Kerberos Anita Jones November, 2006 1

advertisement
Kerberos
Anita Jones
November, 2006
1
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
2
Kerberos : Objective

Provide authentication service
– Clients to servers
– Servers to clients
3
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 standalone 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
4
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
5
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
6
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
7
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
8
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
9
Protocol 1 – get ticket-granting ticket
simple illustration

Once per client logon session:
1 C  AS:
2 AS  C:
IDC , IDtgs
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
10
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
11
Prot’l 2 – get service-granting ticket
simple illustration

Get service-granting ticket – at first request for a
particular service
1 C  TGS: IDC , IDv , tickettgs
2 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
12
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
13
Protocol 3 – to obtain the service
simple illustration

Once per service session:
1 C  V: IDC , ticketV
Note: C gives user name & submits ticket for V’s service
14
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
15
Protocol 1 – more complete
get ticket-granting ticket

Once per client logon session:
1 C  AS:
2 AS  C:
IDC , IDtgs , Time1
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
16
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
17
Prot’l 2 – get service-granting ticket
fuller illustration

Get service-granting ticket – at first request for a
particular service
1 C  TGS: IDv , tickettgs , authC
2 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;
18
encrypted with KC,tgs
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
19
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
20
Protocol 3 – to gain service
fuller illustration

Once per service session:
1 C  V:
2 V  C:
ticketV , authC
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
21
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
22
Kerberos – End
23
Download