Kerberos Mark Sidnam What does it do

Kerberos Mark Sidnam

What does it do? Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos acts as an extra layer of security for any application which utilizes Kerberos Contains its own database of users and passwords Transparently authenticates its users to save time from redundant password entries Limits accessibility to ‘kerberised’ programs

what can it do? Kerberos is mostly used in application-level protocols such as TELNET or FTP, to provide user to host security. It is also used, though less frequently, as the implicit authentication system of data stream (such as SOCK_STREAM) or RPC mechanisms. It could also be used at a lower level for host to host security, in protocols like IP, UDP, or TCP (ISO model levels 3 and 4), although such implementations are currently rare, if they exist at all. contains utility to recompile programs to run utilizing the kerberos authentication scheme effectively kerberizing them. comes with programs with already built in kerberization ksu, ksh, telnet, etc…

Why does it do it? Typically a firewall is put in place to prevent malicious actions wrought against a network, this though, disregards the threats from within a network Protects programs that send unencrypted passwords over a network Reduces the risk from servers that expect clients to be ‘honest’ about their identity proves the identity of both the client and the server prevents replay attacks by utilizing clock synchronization(not foolproof)

how does it do it? the ticket system user requests an initial ticket from KDC used as basis for all remote access requests

the ticket system A ticket is a sequence of a few hundred bytes. These tickets can then be embedded in virtually any other network protocol, thereby allowing the processes implementing that protocol to be sure about the identity of the principals involved. has a Key Distribution Center (KDC), containing a database of: principles (customers and services) encryption keys based off the key distribution method by Needham and Schroeder

steps in the ticket system 1. user sends request to the authentication server to use a particular program 2. the server generates a session key and proceeds to send to the user two encrypted replies the first is encrypted with the users key and contains the session key the second(ticket) is encrypted with the service's key and contains the same session key and the users information 3. the user extracts the session key from the first reply and sends two messages to the service the ticket obtained from the server(which the user is unable to unencrypt) and the authenticator encrypted with the session key and containing a time-stamp

the TGT if that sounded in any way insecure there is an extra step of security involved which Needham and Schroeder called the KDC in the first step rather then obtaining the ticket from the authentication server, the user obtains a ticket granting ticket(TGT) the ticket granting server and authentication server are collectively referred to as the KDC steps involved: user rather then using his secret key to decrypt the first reply from the AS for each ticket, he/she does so once for the TGT. After this, whenever a user wishes to use a service, he/she requests a new ticket with the TGT now encrypted with the session key

The importance of time synchronization To prevent replay attacks, Kerberos utilizes timestamp policies all machines desiring to be a part of the kerberos network must be synced by within five minutes of each other any time stamp differing from the clock on the computer by more then 5 minutes causes the service to disregard the ticket as false in step 3 of the ticket process a time stamp was created, this was to block others from using this ticket at another time the TGT only lasts for a time set in one of the kerberos config files

Extra things to do Cross realm authentication a principal belonging to one realm(can be referred to as the domain name) may be authenticated within a different realm, kerberos can do this one of two well known ways cross realm secret key thus in N realms, 2 * ((N - 1) ** 2) secrets will need to be exchanged in order to cover all possible crossrealm authentication paths. transitive cross realm authentication you can define a path of realms connected via crossrealm secrets and use this path to "hop" between realms until you get credentials in the desired realm

more extra things it is possible to completely kerberize your entire system adding kinit(command to gain a TGT) to all users login procedures and kdestroy(command to destroy all cached tickets) to all logout procedures assures that all users will have a TGT for the duration of login(assuming that this login period does not extend beyond the TGT lifetime) logins can be kerberized as well rather then the usual login command a kerberos login can be replaced and as the user logs in he does so using his kerberos password and gains his TGT for any services he wishes to use on his machine

more then just one type of ticket Initial Tickets Pre-Authenticated Tickets proves the occurrence of some form of authentication prior to step 1 in the ticket steps Invalid Tickets tickets received from the AS proving a password has been entered to gain access to it a ticket with a use date not yet reached. useful for batch jobs that the administrator wishes to occur without his presence (Potentially) Postdated Tickets allows for requests for postdated tickets(only tickets, no postdated TGT may be issued this way)

more tickets Renewable Tickets Proxy Tickets rather then have long ticket lifespans(allows higher opportunity to attacks) or the constant requests for more TGTs(which also create more opportunity due to constant password entry) RT request a new TGT depending on an extra field that tells how much longer the ticket can be renewed for when you trust a privileged service to act on your behalf the service requests a proxy ticket(TGT) which allows the service to act on another service in the name of the user Forwarded Tickets Forwarded tickets are just like proxy tickets, except that they can authorize issuance of TGTs

Security issues and info Kerberos assumes trusted hosts and an untrusted network a compromised host is compromised as far as kerberos is if an attacker obtains the tickets in transit, he now has to contend with many other hurtles, one of which is the replay cache which keeps track of the authenticators used and blocks its reuse. so if the KDC is compromised, then the whole of the realm is compromised the 'key salt' when you enter your pass in for the TGT rather then enter the 56 -bit DES key, a program called string 2 key() hashes your pass with your principal name to create unique keys for the same password(improvement over 4)

more security info the ip address of the machine granted the ticket is contained within the ticket adding protection from stolen tickets user to user authentication for users hosting services on their workstations such as nfs and ftp in the user-to-user protocol, one user acts as a server, and the other user acts as a client. at the client-user's request, the server-user sends his TGT (but not his session key) to the client-user, who then gets credentials from the KDC, encrypted with the session keys of both TGTs. Both users can decrypt the new session-key and use it to verify each other's identity Kerberos 5 does not offer an API that hides the difference between desktop servers and physically-secure servers. For this reason, very few services currently support the user-touser protocol

guess what, more security info Kerberos vs SSL If a Verisign certificate issued to a user is compromised and must be revoked all servers who that user interacts with must now either have that revocation certificate cached to compare to, or compare to a third party 'revocation server' the certificate sits on the hard disk allowing for ample opportunity for cracking as opposed to the password system in Kerberos is free open source, open standards allows room for growth and evolution

. conf files krb 5. conf designates realm name and mapping information if it differs from your domain name logging information basic ticket information kdc. conf very similar in nature to krb. conf file contains base realm information list of all key/salt combinations

other information windows has (in many opinions faulted) implementation of kerberos on server 2000 that can work with GNU/linux clients an MIT creation(isn't everything. . . ? ) uses Data Encryption Standard(DES) . conf file stuff kdc. conf can contain an option to block certain passwords from a particular dict_file from being used can block/allow hosts in the hosts config file for added protection the kerberos database stores keys, not passwords most services only check for ticket status upon initializing, not afterwards. AFS(similar to NFS) on the other hand will block all access to files when the ticket runs out

sources http: //www. faqs. org/faqs/kerberos-faq/user/ http: //cryptnet. net/fdp/admin/kerby-infra/en/kerby-infra. html http: //www. isi. edu/gost/brian/security/kerberos. html http: //www. cmf. nrl. navy. mil/CCS/people/kenh/kerberos-faq. html http: //docs. hp. com/en/T 1417 -90001/ch 05 s 04. html http: //www. itl. nist. gov/fipspubs/fip 46 -2. htm http: //web. mit. edu/kerberos/www/dialogue. html http: //www. microsoft. com/windows 2000/techinfo/planning/security/k erbsteps. asp http: //web. mit. edu/kerberos/www/