Presentation on theme: "Authentication Applications The Kerberos Protocol Standard"— Presentation transcript:
1Authentication Applications The Kerberos Protocol Standard Rabie A. RamadanLecture 7
2Outline I. Introduction II. Introduction to Kerberos v4 III. Details of Kerberos v4IV. Kerberos v5V. Realms and Inter-Realm Authentication
3IntroductionNote: some of the slides and figures are taken from Dr. Jean-Anne presnetation
4Introduction Open distributed environment WorkstationIntroductionOpen distributed environmentUsers at workstations wish to access servers distributed throughout the networkServers must restrict access to authorized usersServers must authenticate request for service
5IntroductionWorkstation (your computer) can not be trusted to authenticate its user correctly to network services:Three threats exist:User pretends to be another user.User alters the network address of a workstation.User eavesdrops on exchanges and use a replay attack.
6Solutions AS knows all the passwords of all users Server (V)AuthenticationServer (AS)Client (C)AS knows all the passwords of all usersAS shares unique secret Keys with each server
7A Simple Authentication Dialogue Server (V)AuthenticationServer (AS)Client (C)Security holes?Password sent as plain ASCIINo time limits for ticketsMan-in-the middle can steal the ticket and fake IDC ( simple, because it is sent as clear text).
8More Secure Dialogue Idea: Introducing a Ticket Granting Server (TGS) Kc’ : A key that is derived from the user password
9Problems with the Previous Protocol 1. Lifetime associated with the ticket-granting ticket:If too short → the user is repeatedly asked for the passwordIf too long → a greater opportunity to replay exists.The threat is that an opponent will steal the ticket and use it before it expires.2. There may be a requirement for servers to authenticate themselves to users.The false server would then be in a position to act as a real server and capture any information from the user and deny the true service to the user.An opponent could eavesdrop on the network and capture a copy of the ticket-granting ticket and then wait for the legitimate user to log out. Then the opponent could forge the legitimate user's network address and send the message of step (3) to the TGS. This would give the opponent unlimited access to the resources and files available to the legitimate user.Therefore, a network service (the TGS or an application service) must be able to prove that the person using a ticket is the same person to whom that ticket was issued.
10What is Kerberos? Network authentication protocol Developed at MIT in the mid 1980sRelies on conventional encryption, making no use of public-key encryption.Available as open source or in supported commercial softwareTwo versions: version 4 (passing slowly away) and 5 coexist.
11Kerberos 4 OverviewStallings Fig Discuss in relation to Table 14.1 which details message exchanges.
19Kerberos Realms A Kerberos environment consists of: a Kerberos servera number of clients, all registered with serverapplication servers, sharing keys with serverThis is termed a realmtypically a single administrative domain
20Request for Service in Another Realm V.4 Users on one realm may need access to servers in other realmsPlease consult the bookfor more details
21Difference Between Version 4 and 5 Encryption system dependence (v.4 DES)Message byte ordering (v.4 arbitrary; v.5 defined by ASN1 Standard)Ticket lifetime (v.4 21h max; v.5 arbitrary)Authentication forwarding to other hosts (v.4 no; v.5 yes),A client accesses a server. The server can not act on another server on behalf of the client)Inter-realm authentication: v.4 (v5. simpler)
22Kerberos Version 5 Developed in mid 1990’s Provides improvements over v4addresses environmental shortcomingsencryption algoithms, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm authenticationSpecified as Internet standard RFC 1510
23New Fields in V5 Realm: Indicates realm of user Options: Used to request that certain flags be set in the returned ticketTimes: Used by the client to request the following time settings in the ticket:from: the desired start time for the requested tickettill: the requested expiration time for the requested ticketrtime: requested renew-till timeNonce: A random value to be repeated in message (2) to assure that the response is fresh and has not been replayed by an opponent
24New Fields in V5Subkey: The client's choice for an encryption key to be used to protect this specific application session. If this field is omitted, the session key from the ticket (Kc,v) is used.Sequence number: An optional field that specifies the starting sequence number to be used by the server for messages sent to the client during this session. Messages may be sequence numbered to detect replays.
25Kerberos LimitationsEvery network service must be individually modified for use with KerberosDoesn’t work well in time sharing environmentRequires a secure Kerberos ServerRequires a continuously available Kerberos ServerStores all passwords encrypted with a single keyAssumes workstations are secureScalability