Kerberos Authentication Systems

Embed Size (px)

DESCRIPTION

Kerberos Authentication Systems. KERBEROS. In Greek mythology, a many headed dog, the guardian of the entrance of Hades (Hell). Outline. Authentication in Campus Kerberos 4 Realms (Domains) under Kerberos 4. Authentication in Campus. Workstations, Servers are distributed - PowerPoint PPT Presentation

Text of Kerberos Authentication Systems

  • Winter 2006Prof. R. Aviv: Kerberos*KerberosAuthentication Systems

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*KERBEROS In Greek mythology, a many headed dog, the guardian of the entrance of Hades (Hell)

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*OutlineAuthentication in CampusKerberos 4Realms (Domains) under Kerberos 4

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Authentication in CampusWorkstations, Servers are distributedUsers/Clients: anyone, log in at any WstnServers software: need to authenticate and authorize usersCan we trust Workstation software to authenticate users on behalf of serversWhat are the threats?

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Authentication in CampusThreats: actions enabling unauthorized users to gain access to services and dataUser pretend to be another user.User alter the network address of a workstation.User listens to exchanges and use a replay attack.How Users and Servers authenticate each other?

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Approaches to AuthenticationNeed Mutual AuthenticationWorkstation cannot hold policy for all servers all users why not?Use a trusted Authentication Server - KERBEROS ServerKerberos Server holds policy which users can access which servers, and keys for all principalsShould we use Symmetric or A-symmetric keys

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*KERBEROSCentralized Authentication Server authenticating users to servers and v,vRelies on conventional encryption no use of public-key encryption unlike PKILong term shared secrets between Kerberos and Servers and Users (not with client wstn) What are the requirements from the Kerberos Protocol?

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Kerberos Protocol RequirementsPartners are authenticated continuouslyPartners: Client, K Servers, ServerMessages between Kerberos Server and others encrypted by secret short lived keysLittle user involvement

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Kerberos Protocol: 3 phasesAssume user wants to print

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Kerberos Version 4: Items/NotationC = Kerberos Client module (on the workstation)AS = Kerberos Authentication ServerTGS = Ticket Granting Servertgt= Ticket Granting TicketV = server (e.g. mail server, ftp server, print server)IDU = identifier of user on C (e.g. name, email address)IDv = identifier of server V (e.g. Server IP address+port)PU = password of user, known to ASADc = network address of Client (users workstation) Kv = secret encryption key shared by TGS and VTS = timestamp

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Basic Kerberos Protocol1.K Client sends (User ID: IDU) and PU ?2. PU is known to AS. AS sends back a packet with tgt encrypted (DES); key derived from PUKerberos Client requests password from userK Client decrypts packet, finding Users ID and its own address (ADc) inside, in correct format ensuring user knows PU; user authenticated What will be the usage of tgt ?

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Basic Kerberos Protocoltgt: User authenticated, allowed to get ticket3. K client sends tgt to the Ticket Granting Server, (TGS) is it now encrypted?4. K. client receives a Service Ticket, ticketv5. ticketv (client credentials) sent to server Vticketv encrypted by secret known to V and TGStgt, ticketv have some lifetime

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Authenticating Phase: Once per logontgt is sealed cannot be read by anyone but TGS (not even by User or Client); Why?Could the ticket sent directly to TGS?Timestamp - against replay(1) C AS: IDU || Idtgs (2) AS C: EKc [tgt|| IDU] tgt = EKtgs[IDU || ADc || IDtgs ||TS1 || Lifetime1]Whats the meaning of the tgt

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Client request and get ticketv: Once per serviceIDU appears twice where? ADc appears twice whereWhy? Problem?C TGS: IDV ||tgt ||IDU can attacker forge IDU? can attacker impersonate the User? (4) TGS C: ticketv ticketv = EKv[IDU || ADc || IDv ||TS2 || Lifetime2]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Client getting Service: Once per service sessionServer V sees its own ID ticketv is genuineV compares client address in IP header & ticketvV compares user ID in packet and ticketvProblem?(5) C V: ticketV || IDU ticketV = EKv[IDU|| ADC || IDV ||TS2 || Lifetime2]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*The Lifetime of tgtIf too short user will repeatedly enter password. If too long, an attacker might reuse message 3 (with forged IDU, ADc) before tgt expires Hence: TGS must authenticate Client againClient adds secret authenticator to message 3For this Client and TGS Need a shared secretHow would they get it?AS to send a shared secret to both in message 2

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*New Message 2: AS sends to client a tgt, AND a shared TGS-session key to be used in message 3TGS session keytgt:login name (IDU)TGS namenet address (ADc)TGS session keyEncrypted with user keyEncrypted with TGS keyWho knows the session key?

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*New Message 3: Client authenticates itself to TGS, requests ticket3 parts messagetgt (previously obtained from AS), Encrypted by key known only to TGS (and AS)authenticator: encrypted with TGS session keyServer (V) IDtgtauthenticatorServer V Nameencrypted withTGS keyencrypted withTGS session key

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*The Lifetime of ticketvIf lifetime is long, attacker might reuse it How?V must authenticate the Client againSolution: AS gives in message 4 to both V and the K client a one time, shared session key, Kc,vClient attach authenticator to its message 5

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*New Message 4: TGS sends to client a ticketv AND a shared V session key to be used in message 5

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*3 parts messageticketv (previously obtained from TGS), Encrypted by key known only to Vauthenticator: encrypted with V session keyServer (V) IDNew Message 5: Client authenticates itself to V, requests service

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Phase 1: User gets ticket granting ticket, and Client Authenticates the User Authentication Service Exchange:

    1. C AS: IDU || IDtgs ||TS1

    2. AS C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || tgt]Shared Session key

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Phase 2: TGS authenticates User, User gets ticketvAuthenticator: Info about the Client (User name, IP Address, Timestamp) encrypted with shared secret. Expires immediately3. C TGS: IDv || tgt || authenticatorc4. TGS C: EKc [Kc,v|| IDv || TS4 || ticketv]tgt = EKtgs[Kc,tgs || IDU|| ADC || IDtgs || TS2 || Lifetime2]ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4]authenticatorc = EKc,tgs[IDU || ADc || TS3]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Phase 3: V Server, User authenticate each other, User gets service6. Client Authenticate the Server:Server reply: TS5+1, encrypted by the shared session key (Kc,v)5. C V: ticketv || authenticatorcV C: EKc,v[TS5 +1]

    ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4] authenticatorc = EKc,v[IDU || ADC || TS3]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Summary of Kerberos 4 Protocol

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Realm (Domain)Organization is organized in Realms (Domains) A Realm (e.g. faculty) under a single adminIncludes: AS, TGS, Clients, service ServersThe TGS must share a secret key with each Server in its RealmAll Servers in a Realm register with the TGS

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*Inter-operating RealmsUsers in one realm might need access to Servers in another, interoperating realm example?TGS in realms register with all other ASAS in a realm trust other AS to authenticate its usersServers in one realm trust TGS of the other realm

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*User access Server RV in a remote RealmClient applies to local AS for a Tickettgs for local TGS1. CAS: IDU || IDtgs || TS1

    2. AS C: EKc[Kc,tgs || IDtgs || TS2 ||LT2||tgt]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*User access Server RV in a remote RealmClient applies to local TGS for a tgtr for (remote) R-TGS3. C TGS: IDR-TGS || tgt || authenticatorc

    4. TGS C: EKc,tgs[Kc,r-tgs || IDR-TGS || TS4 || tgtr]

    Prof. R. Aviv: Kerberos

  • Winter 2006Prof. R. Aviv: Kerberos*User access Server RV in a remote RealmClient applies to RTGS for a ticketrv for RV Server5. C R-TGS: IDRV || tgtr || authenticatorc

    6. R-TGSC: EKc,rtgs[Kc,rv || IDrv || TS6 ||