"Limitations of the Kerberos Authentication System" search above paper for more "The Evolution of the Kerberos Authentication Service" ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS Q: -- * WHY HAVING TGS? What happens if there is no TGS? Why just let's kerberos server provide every Tc-s? + Well, if there is no TGS, then every time a client request a ticket to a service the user need to type a password, because that is the only way that Kerberos verify the user identity. + Having TGS, a client only need to enter password once when request Tc-tgs. - From Mike: How a client know the identity of a server? Say print123... the client relies on DSN to learn that, but DSN may lie. The problem is how to get the server name and verify that the name is actually authentic. * Why TGS does not issue tickets for KDBM servers (i.e. servers allow user to change their password)? Instead, user need to obtain the tickets by directly contact Kerberos? - the reason is: this requires users to enter their password every time - otherwise, malicious users can use an unattended work station to change the real user's password. * How does Kerberos securely propagate update? - the master is dumped every hour - the master send the entire database to all the slaves - the master also send the checksum of the database, which is ENCRYPTED using Kerberos master database key - The slave calculate the checksum, if match, apply the update * How to choose ticket lifetime? - tradeoff between security and convenience - too long, tickets and the session key may be stolen and reused - too short, when the ticket expires, user need to enter the password # 1. Introduction *Question*: how one can take access control in network of computer: - Alternative 1: do nothing ==> work in *closed* environment, strictly managed - Alternative 2: require host identity, but trust the host's word as to who the user is ==> more open, trust only host under organization control - Alternative 3: require user (not computer) to prove identity for required service ==> used when receive requested from hosts outside organization controls This paper is about Alternative 3: *Requirement* - secure - reliable - scalable - transparent (user login using password, and he prove his identity to service in a logging in session transparently) *Problem of Authentication* - How a server authenticate user identity when he asks for a service? - How a user knows the server he asking for service trusted? # 2. What is kerberos? # 2.1 Basic thing - third-party authentication service - clients believe Kerberos judgement - keep private keys of principal, these keys are generated at registration time (Question: how to generate private key securely? We will see) - session keys for each session of communication (i.e. CK in the other papers) ==> Hence Kerberos uses traditional model (secret key model) - provide 3 levels of protection: + at initial connection only, does not care about subsequent message > like authenticated network file system + safe messages: i.e each message is authenticated but not encrypted + private message: each message is both authenticated and encrypted # 2.1 Software component - use database to keep a record for each principal + keep sensitive info (e.g password) and insensitive info separately - administration server: read-write to database (used by administrator) - authentication server: used by client, read-only - database is replicated: one master, many slaves Question: how to keep these up-to-date? How to propagate update? (Kerberos: propagate update every amount of time) Why replicated? For scalability # 3. Kerberos name Include three parts: - primary name: name of user (thanh), or service (rlogin) - instance: + for user, it is *group* that indicate some privileges (root, admin) + for server, it is the machine running that service - realm: name of authentication server # 4. Important: How does Kerberos work? Notation: s --> server c --> client addr --> client's network address life --> lifetime of ticket tgs, TGS --> ticket granting server Kerberos --> authentication server KDBM --> administration server Kx --> x's private key Kx,y {abc}Kx --> session key for x and y Tx,y --> x's ticket to use y Ax --> authenticator for x WS --> workstation # 4.1 Credentials: 2 types: ticket and authenticator - Ticket: {s,c, addr, timestamp, life, Ks,c} (Ks) + can be used multiple time during life time + presented to server a client want to use a service + must be obtained somewhere, of course! + why need Ks,c in the ticket? Because later on, client will use this ticket to contact server s, server s decrypt the message, and learn about common session key (Ks,c) + good for a single server and a single client ==> cannot be used as capabilities, because Question: can client modify ticket? No, because it is encrypted with Ks (server's key) - Authenticator: {c, addr, timestamp} Ks,c + can be used once, how? + new one must be generated each time clients want to use a service + client is able to build the authenticator itself, because it knows (the session key) # 4.2 Getting Ticket From ticket granting service When user login, type the user name Client sends to the authentication server: (1) C --> Kerberos: C, tgs C: login name tgs: ticket-granting service Kerberos generate the session key between client and tgs (2) Kerberos --> C: {Kc,tgs , {Tc,tgs}(Ktgs)}(Kc) Question: where does Kc come from? Answer: from the password, hence Kerberos must know user password before. and at client side, user is asked to enter password, which will generate Kc to decrypt M(2) ==> Kerberos: keeps all Kc and Ktgs, but not other Ks Question: where to store Kc,tgs (any any Kc,s)? Need a secure place OK, now how the client use a service other than tgs? ==> it needs to obtain that ticket from TGS. # 4.3 Before requesting a service other than TGS, get necessary ticket Say now client want to get access to server s... (3) C --> TGS: s, {Tc-tgs}(Ktgs), {Ac}Kc,tgs Ac: authenticator Why Ac? defeat intruder to stand between and alter the message (say replace s with s prime), or intruder can make client use old session key, or it can replace the ticket with old one (because it has time stamp) SO the TGS generate the common session key between c and s, put it in the ticket and send both the key and the ticket back to client. TGS needs to put Kc,s in the ticket because later on server s will learn about that when talking with client c (4) TGS --> C : {{Tc-s}(Ks), Kc-s}Kc-tgs TGS doesn't know Kc, but Know Ks # 4.4 Show time: using a real service (5) C --> S : {Ac}Kc,s, {Tc-s}(Ks) Remember, always send Authenticator, it contains timestamp, so that can defeat replaying... Server s decrypts Tc,s, learn about the Kc,s, use Kc,s to decrypt Ac, from that learn about the client identity and the timestamp (6) S --> C : {timestamp + 1} Kc,s M(6) is to avoid message replaying From now on, can use Kc,s to send request and receive reply # 5. Kerberos Database: - Single master - Multiple slaves - Propagate update: + every hours + master sends entire database to slave + encrypted checksum is sent too How to revoke a # 6. Transparency: - For user, ticket is obtained at login, without user notice - For programmer, easy to integrate authenticating service by API - For admin, easy too # 7. Multi-realm: like multi authentication server in previous paper - a secret key need to be shared between realms - Kerberos supports multiple administrative domain - services are usually registered in a single realm, and will only accept credentials issued by an authentication server for that realm - user is usually registered in a single realm (the local realm), but it is possible for him to obtain credentials issued by another realm - credentials valid in a remote realm indicate the realm in which the user was originally authenticated. - services in the remote realm can choose whether to honor those credentials, depending on the degree of security required and the level of trust in the realm that initially authenticated the user. Example: say we have 2 realm, A and B, each has corresponding TGS: TGS-A, TGS-B - this too realm must share the same secret key (set up by administrator) - say a client want to access some service in realm B Step 1: C --> Kerberos in local domain (i.e. realm A): C, TGS-B Step 2: Kerberos A --> C: {Kc-tgsB, Tc-tgsB}(Kc) Step 3: C --> TGS-B: S, {Ac}Kc-tgsB, Tc-tgsB Step 4: TGS-B, using the SHARED KEY, decript the ticket, learn about Kc-tgsB, Issue ticket at normal, but the realm field for the client will contains the name of the realm in which the client was originally authenticated # 8. ISSUES - Ticket life time: + trade off between security and convenience + too long: ticket and session key can be misplaced or stolen (how can this happens?) + too short: requires to enter password again - Proxy problem: (not clear about this) + How an authenticated user allow a server A work on his behalf to acquire service from server B? + authentication forwarding: user login to host A, and from host A, logs in to host B, and want to use service at host B (but user want to authenticate those services) ==> difficulty is: user might not trust the remote host + software integrity: a malicious login program # Interesting Problem: Kerberos application to NFS - Kerberos and NFS * In NFS, credentials are UID and GID * Hence, NFS's credentials must be changed to full-blown Kerberos's credential * hence, performance penalty: credentials are exchanged every NFS operation including all disk read and write * Hence a hybrid approach, basic idea is mapping map credentials received from client workstations, to a valid credential on the server system * Mapping can be built on every "mount" QUESTION: 1) Why they separate Kerberos, and TGS (Figure 9)? Because TGS seems very powerful, it keeps the information about other servers and access control of a client to any service. Why not just combine Kerberos and TGS? Possible reason is: Kerberos: keeps detailed information about clients (more sensitive information) TGS: keeps information about servers --> chance to separate thing, make kerberos highly secure Ask Swift? To answer the qual question in Fall2010, may be need to read 6.3 There should be the database contains server and client info (and keys) Kerberos and TGS. QUAL FALL 10: A. B. Revocations: 1) change the database, but it is limit by ticket expire times, and update propagation 2) change the server itself (to include ...)