Kerberos ======== high-level picture: - users on workstations - servers providing mail, printing, file storage, remote login, .. - users (or attackers) assumed to control their workstations - central Kerberos server trusted by everyone - keeps track of everyone's symmetric keys - two ways to get at the database: via password or via TGT frontends are called the Kerberos service and TGS (in paper) - services have shared keys with Kerberos - goal: mutual authentication between user and service interesting aspects of the protocol: - principal naming: user, instance, realm - what's a principal in this model? and how do you name it? users are principals: username (and instances for special privs) services are principals: instance is server name, if many TGS is a principal like any other service (krbtgt) - what do names get used for? access control on a server, to identify principal clients deciding what principal to expect when talking to service - when can you reuse names? for user names, requires sweeping all possible ACLs for services, relatively soon change the key associated with service to ensure keys not the same users have to be aware of the semantic change, if any - how does the Kerberos server authenticate the user? doesn't need to! - how does the user authenticate the Kerberos server? decrypts the ticket and checks if the ticket looks OK password is shared secret between user (his workstation) and Kerberos - weakness: assumes encryption provides integrity/authentication attacks on krb4 have taken advantage of this to splice messages DES (which kerberos uses) encrypts 8 bytes at a time attacker can take first 8 bytes of one block, splice with other blocks - fixed cryptosystem DES is rather deeply engrained in krb4 - why does the Kerberos server include the key twice? once in the response itself, and once in the ticket this proves to the next guy (TGS, in this case) that client is legit only client could have decrypted the first copy of the key but client could not have forged or opened up the ticket - how does the TGS authenticate the user's request for a service ticket? shared key between TGS and Kerberos server user's TGT ticket encrypted with TGS shared key safe to accept ticket from client: could not have been tampered with (modulo that authentication vs encryption problem..) TGT contains client's name, which originally came from Kerberos server TGT ticket contains a session key known to client request encrypted with client's session key, so came from client - how does a service authenticate a user? same process as with TGS (infact, TGS just a special kind of service) - what happens then? all usual network traffic encrypted with session key e.g. POP commands to fetch mail, documents sent to printer shell commands or other user input for remote login - replay attacks why authenticator? try to ensure message is fresh have to be careful in krb4: attacker can splice fresh A + old message problem: same session key! krb5 uses fresh session key each time client chooses session key, sends it in the authenticator - mutual authentication what's the problem? when would you care? example: file server, want to make sure you're getting good files server encrypts something it could've only known if it had its key - reflection attacks krb4: direction flag included in packets krb5: separate C->S, S->C keys - why does a ticket contain c? s? - why is the IP address in the ticket? prevent tickets from being used on another machine bad idea with NATs - why does a ticket contain timestamp & life? expiration - what does Kerberos use time for? what goes wrong if time is off? expired tickets reused by attackers replay attacks - can an attacker get the user's password from the network? - offline password-guessing attacks how would you prevent it? krb5 preauth: client includes current time, encrypted with user pw still vulnerable to attacker watching the encrypted ticket on network much better protocols are available (but some are patented) eg SRP (http://srp.stanford.edu), PAKE (password-auth key exchange) another good technique to know: Unix salting - authenticating to local workstation does it matter? implicit rights based on kerberos username (eg unix systems) how about auth to remote login server? - password changing protocol special flags to indicate "initial" tickets why? requires an extra level of authentication to change pw individual services could request the same, in theory - what can attacker do with a stolen TGT? stolen service tickets? if user changes pw, kvno prevents getting new service tickets from TGT - what if attacker knows user's password? can decrypt the user's initial ticket for the password-change service can use that to decrypt user's request to change password can get a copy of the new password that way! - what happens if an attacker gets a copy of your old password later on? if attacker has a copy of all past packets, can decrypt everything use password to decrypt attacker can do this just by logging all of your packets! - cross-realm support naming scheme is insufficient - how could you do forwarding better? current scheme: request a new TGT with new IP addr, send to remote host better scheme: remote site can ask your workstation to get svc tickets what does it prevent? what kinds of vulnerabilities still exist? - no public/private crypto at all! public-key crypto was relatively new at the time public-key crypto was also expensive even DES was export-restricted can view tickets as certificates, but using shared-key crypto (thus ticket is for a specific service, while cert is for any service) - what does SSL lack in comparison with Kerberos? using user password to authenticate servers timely revocation - what could you do better with public-key crypto support? avoid having a centralized server in critical path for all operations basically a certificate scheme, something like SSL Kerberos server becomes a certificate distribution server doesn't have the same revocation properties as centralized Kerberos could use similar schemes (OCSP) to revoke potentially makes it easier for users to join in kerberos model, cannot talk about users not in Kerberos server in a public-key model, could allow public keys as usernames or public keys as realm names, so no need for pre-shared realm keys with a key-exchange protocol like DH, can achieve forward secrecy attacker cannot decrypt past communications because key not in pkts can safely change password after your password has been compromised diffie-hellman key exchange protocol both parties agree on a large prime number (p) and generator mod p (g) g is often something small like 2 both parties choose a random, secret exponent (a and b) parties send (g^a mod p) and (g^b mod p) to each other each party can compute (g^(ab) mod p): ((g^a mod p)^b mod p) ((g^b mod p)^a mod p) parties can then use (g^(ab) mod p) as a shared secret (can use as key) assumption: discrete-log problem is hard hard to find b, given (g^b mod p), g, and p note: authentication is crucial! but kerberos (or other protocols) can provide that don't need forward secrecy for authentication MITM attack: attacker runs a separate DH protocol with each party gets a shared key with each one decrypts and re-encrypts any messages between them gets to keep a copy (or change contents) what doesn't kerberos address? access control, groups (among many other things) microsoft's version of Kerberos (in AD) includes signed group info in ticket can think of it as ticket containing not only principal name, but also groups that principal belongs to, and special rights principal has single-sign-on protocols on the web: OpenID user IDs are special URLs that respond to OpenID requests no pre-defined Kerberos server; infact, server name is part of user ID how does a web application authenticate a user? want a statement from the user's URL saying user is who he claims one approach: web app talks to user's URL gets shared key wants to get back a msg signed/MACed with that key (probably should include user's name, timestamp, etc) hands some token to user user redirected to user's URL to log in with token server can transform this token into the relevant key on successful login, uses key to sign/MAC the right msg another approach: web app will verify signed/MACed message later redirects user to user's URL right away when it gets msg, talks to user's URL to check it requires direct communication between services and Kerberos server kerberos avoids this because everyone trusts the same TGS principles for avoiding protocol disaster - authentication/signing/MAC vs encryption - be explicit: think of how your message can be mis-interpreted one example is a reflection attack: assumes context (insecure) make sure every signed message can be understood in isolation does it matter for encrypted msgs? probably not should not rely on their meaning/authenticity anyway but a good idea to use authenticated encryption - freshness/replay attacks - forward secrecy: do not reuse session keys