DOC PREVIEW
WUSTL CSE 571S - Kerberos V4

This preview shows page 1-2-21-22 out of 22 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

10-1©2009 Raj JainCSE571SWashington University in St. LouisKerberos V4Kerberos V4Raj Jain Washington University in Saint LouisSaint Louis, MO [email protected]/Video recordings of this lecture are available at:http://www.cse.wustl.edu/~jain/cse571-09/10-2©2009 Raj JainCSE571SWashington University in St. LouisOverviewOverview! What is Kerberos?! Kerberos V4 Concepts and Design Principles! Replicated KDCs! Multiple Realms! Other details10-3©2009 Raj JainCSE571SWashington University in St. LouisOverview of KerberosOverview of Kerberos! Allows two users (or client and server)to authenticate each other over an insecure network! Named after the Greek mythological character Kerberos (or Cerberus), known in Greek mythology as being the monstrous three-headed guard dog of Hades! Designed originally for Project Athena at M.I.T.! Implementation freely available from M.I.T.! V5 is proposed as an Internet Standard (RFC 4120)! Windows 2000/XP/Server 2003/Vista use Kerberos as their default authentication mechanism! Apple's Mac OS X clients and servers also use Kerberos! Apache HTTP Server, Eudora, NFS, OpenSSH, rcp (remote copy), rsh, X window system allow using Kerberos for authentication.10-4©2009 Raj JainCSE571SWashington University in St. LouisOverview (Cont)Overview (Cont)! Protects against eavesdropping and replay attacks! Uses a trusted third party (Key Distribution Center) and symmetric key cryptography! First 3 versions are no longer in use.! V5 is a generalization of V4 with several problems fixed and additional features.! It is easier to understand V5 if you know V4! Learn V4's features and mistakes10-5©2009 Raj JainCSE571SWashington University in St. LouisSample Kerberos ExchangeSample Kerberos ExchangeHi! Jain@cse would like to communicate with PrintServer. Attached is his day pass.Hi! Jain@cse would like to use the network todayHere is a day pass for jain@cseHi jain@cse wants to communicate with you.. Here is his ticket.Perfect. Let us use the session key that was in your ticket.Here is the ticket for jain@cse to communicatewith PrintServer. It includes a session key. 123456AuthenticationServer (KDC)Ticket GrantingServer (TGS)Service ServerClient10-6©2009 Raj JainCSE571SWashington University in St. LouisKerberos V4 ConceptsKerberos V4 Concepts! Key Distribution Center (KDC): Physically secure node with complete authentication database! Principal: Authentication Server A, Ticket Granting Server G, Client (Computer) C, User (Human) U, Server S! Ticket Granting Server (TGS)! Keys: Kcg, Kcs, Kag, Ku, Kgs! Ticket: Encrypted information. All current V4 implementations use DES.! Ticket Granting Ticket (TGT): Allows user to get tickets from TGS10-7©2009 Raj JainCSE571SWashington University in St. LouisConcepts (Cont)Concepts (Cont)! Authenticator: Name and time encrypted with a session key. Sent from client to server with the ticket and from server to client.! Credentials: Session key + Ticket! Session: One user login/logout session! User enters a name and password. Client converts the password to a key Ku.! TGT and the session key are good for a limited time (21 hours).10-8©2009 Raj JainCSE571SWashington University in St. LouisKey Design PrinciplesKey Design Principles1. The network is open ⇒ Need a proper secret key to understand the messages received (except message 1, which is in clear)2. Every client and server has a pre-shared secret with the KDC.3. KDC and Ticket Granting Server (TGS) are logically separate but share a secret key4. Both KDC and TGS are stateless and do not need to remember the permissions granted. All the state is in the tickets. (Day pass is just a longer term ticket)5. Longer term secrets are used less frequently. Short term secrets are created and destroyed after a limited use.10-9©2009 Raj JainCSE571SWashington University in St. LouisInformation ExchangedInformation ExchangedService, SvcNonce4, {User, Client, TGS, Kcg, SesSartTime1, SesEndTime1}Kag, {Client, SesTime1}KcgUser, TGSUser, {User, Client, TGS, Kcg, SesStartTime1, SesEndTime1}Kag, {TGS, Kcg, SesStartTime1, SesEndTime2}Ku{User, Client, Service, Kcs, SvcStartTime2, SvcEndTime2}Kgs, {Client, SvcTime2}Kcs{SvcTime2}Kcs.User, {User, Client, Service, Kcs, SvcStartTime2, SvcEndTime2}Kgs, {Service, Kcs, SvcStartTime2, SvcEndTime2, SvcNonce4}Kcg123456Service ServerClientKDCTGS10-10©2009 Raj JainCSE571SWashington University in St. LouisKerberous ProtectionsKerberous Protections! Kerberos protects against eavesdropping:" If someone else sends TGT, they get back a ticket, and can't decrypt the service key unless they know the client's secret key.! Kerberos protects against replay attacks:" If someone sends TGT or ticket later, it is rejected.! All clients, servers should have time synchronized within a specified limit.10-11©2009 Raj JainCSE571SWashington University in St. LouisReplicated KDCsReplicated KDCs! KDC is a single point of failure.! Multiple KDCs with database replication are allowed.! One KDC keeps a master copy to which all changes are made.! Changes propagated to other copies. All keys are already encrypted. An integrity check is added during transfers.! Most KDC operations are read-only.10-12©2009 Raj JainCSE571SWashington University in St. LouisRealmsRealms! Realm = One organization or one trust domain! Each realm has its own set of principles including KDC/TGT! Each Principal's name = Name + Instance + Realm! 40 characters each. Null terminated.! Instance = Particular Server or Human role (administrator, game player)! In V4, both realms should have a direct trust relationship. Chaining prohibited.10-13©2009 Raj JainCSE571SWashington University in St. LouisInterInter--Realm AuthenticationRealm AuthenticationRequest ticket for local TGSTicket for local TGSRequest ticket for Remote TGSTicket for Remote TGSRequest ticket for Remote ServerTicket for Remote ServerRequestRemoteServiceLocalAS+TGSRemoteAS+TGS10-14©2009 Raj JainCSE571SWashington University in St. LouisKey Version NumberKey Version Number! All clients and servers remember their previous keys for a short time.! Users have to wait after changing their password.10-15©2009 Raj JainCSE571SWashington University in St. LouisPrivacy and IntegrityPrivacy and Integrity! With CBC, only two blocks are affected by a change.! Plaintext Cipher Block Chaining (PCBC) causes all blocks to change.! Recognizable data is put at the end.10-16©2009 Raj JainCSE571SWashington University in St. LouisIntegrity OnlyIntegrity Only! DES too


View Full Document

WUSTL CSE 571S - Kerberos V4

Documents in this Course
IP sec

IP sec

28 pages

Load more
Download Kerberos V4
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Kerberos V4 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Kerberos V4 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?