Kerberos OLC Training

What is it? ● A three-headed dog that guards the entrance to Hades. ● A network authentication protocol that also provides encryption. ● Provides an API that can used to “kerberize”any application

Why? ● Duh. Because of ● Replace "authentication-by-assertion" (c.f. rlogin). ● Provides trusted authentication, and encryption. ● One password for every service (single sign-on)

v4 vs v5 ● v4 is considered dead - no further MIT development. ● v5 supports new features including: ● key salt uses the principal name (as opposed to nothing in v4) - eliminates cross-realm exploits ● tickets can be forwardable, renewable, postdatable, and proxiable ● algorithms other than DES can be used

v4 Services at MIT ● POP3 ● OLx services ● Moira ● Zephyr ● KNFS ● discuss ● IMAP

v5 Services at MIT ● telnet (also v4) ● ftp (also v4) ● ssh ● LPRng ● AFS ● Techtime ● Jabber

Components ● KDC (Key Dsitribution Center) ● Stores copies of pre-shared secrets ● Credentials Cache (v4: Ticket File) ● where Kerberos stores its shared secrets for the session. ● Keytab (v4: Srvtab) ● Pre-shared secrets for services ● Principal ● A user or service in a realm ● Realm ● Does not have to be related to DNS, but typically is. A realm includes all principals controlled by a master KDC

Components, cont. ● TGT - ticket granting ticket ● TGS - ticket granting service ● AS - Authenticator Service ● we'll talk more about how those differ

Instances ● An optional qualifier for the principal. For example, you need a principal for the "imap" service, but there are different pop servers. The hostname is the instance. ● v4: v5: ● v4:

How it works (abstraction) ● User requests negotiation with service. ● KDC makes up session key, uses known shared secrets to encrypt 2 copies, sends back to user. ● User sends service's copy of key to service, service decrypts it, now they have a shared secret to negotiate encryption; service also decrypts timestamp.

More Detail ● Actually, what happens is the first time you get tickets, you request a TGT from the TGS (using the method in the previous slide) using the AS. ● Then, for future services, you request a ticket from the TGS. The reply is encrypted not with your password, but the with session key provided in the TGT.

Why all the fuss about time? ● Remember, this goes over the network. If you didn't make sure the clock skew was < 5 min, I could steal the authenticator, save it for later, and then become you.

Potential Weaknesses ● Assumes that only the network is vulnerable - attacker could insert self between user and application (ie: keystroke monitoring) ● Relies on filesystem security or physical security for keeping srvtab/keytab safe ● Assumes users will not pick stupid passwords (our implementation actually does do a dictionary check)

Encryption ● Kerberos != encryption; Kerberos := authentication. ● Authentication only: kpop, olx, discuss, moira, zephyr, eos, AFS* ● Auth + Encryption: ktelnet, kftp, klogin... ● AFS has encryption, but that’s unrelated.

Special Tickets ● Renewable: Ticket stores not only expiration date, but max lifetime. ● Proxiable: Specified IP addresses are allowed to present a TGT on to another service, but the recipient service can’t get a new TGT. ● Forwardable: Like proxiable, but the TGT can be used get other TGTs (ie: logging into the dialups via ssh)

Getting tickets ● kinit ● get tickets ● kinit -l 21h ● Get tickets for 21 hours ● kinit -r 2d ● Get tickets renewable for up to 2 days ● kinit -R to renew tickets ● kinit -f ● kinit -p ● forwardable and proxiable tickets, respectively

Other operations ● kinit -5 ● Only get version 5 tickets (or -4 for v4) ● klist ● Show your tickets ● kdestroy ● destroy your tickets ● kvno ● Check version number; check if principal exists

Further Reading ● comp.protocols.kerberos FAQ ●