Kerberos5 with Mobile Agent Service Authenticator (MASA)

1. Kerberos5 with Mobile Agent Service Authenticator (MASA) By: Poonam Gupta Sowmya Sugumaran

2. Problem Statement • Our goal is to ensure that authenticated mobile users receive the services without interruption and with less overhead and delay

3. Mobility Services • Network Layer Mobility • ensures connection for mobile users • Service Layer Mobility • ensures services for mobile users

4. Modification to Our Proposal Proactively acquiring TGT and service tickets in realms to be visited

5. Motivation and Example • Realms - consists of clients, KDC, Server application • Clients can get the service from different realm in cross-realm authentication without having an account to different realm

6. Motivation and example continued • Student wants to print a file from dept a to dept b • Without cross-realm mechanism user will have to an account in each realm and transfer file between each realms to print a file • With our scheme service ticket to print a file can be achieved proactively by exploiting the use of cross-realm mechanism and knowledge of mobility

7. No-Cross-Realm(NCR) Message Exchange for Realm1 for Mobile Users 1) Client ---C, TGT--------------------------------> AS1 2) Client <------{TC ,tgs , Kc,tgs}Kc----------------AS1 3) Client -------Tc,tgs , S-------------------------> TGS1 4) Client <---------{Tc,s , Kc,s , }Kc,tgs ------------TGS1 5) Client-----------{Tc,s } Kcs, Ac ------------->Server1

8. NCR Message Exchange for mobile users for Realm2 1) Client ---C, TGT--------------------------------> AS2 2) Client <------{TC ,tgs , Kc,tgs}Kc----------------AS2 3) Client -------Tc,tgs , S-------------------------> TGS2 4) Client <---------{Tc,s , Kc,s , }Kc,tgs ------------TGS2 5) Client-----------{Tc,s } Kcs, Ac ------------->Server2

9. Message Exchange Steps for different realms service for mobile users with cross-realm 1) Client ---C, TGT or RTGT --------------------> AS 2) Client <------send TGT or RTGT-----------AS 3) Client -------send TGTorRTGT,Service----->TGS 4) Client <---------Service Ticket ------------TGS 5) Client---Service Ticket------------ ->Server

10. Difference With cross-realm mechanism combining cross-realm mechanism and our scheme Exchange of messages are same Get the service ticket proactively • Exchange of messages are same • Get the service ticket when you need it

11. Ticket Flow Kerberos V4 Cross-Realm Authentication Tutorial Slide from Jourge Cuellar

12. Kerberos 5 • Allows for trusted path • Hierarchical Realm • Non-hierarchical (shortcuts)

13. Our Scheme: MASA • Mobile Agent Service Authenticator (MASA): A software agent on the mobile client to assist with proactively acquiring authentication (TGTs) from to-be-visited realms. • User App -> MASA -> Kerberos(AS, TGS) • MASA knows mobile user’s: • profile (preferences) • mobility pattern

14. Comparison (Handling Mobile Users) • No Cross-Realm Scheme (NCRS): • Requires user account in each visited realm • User needs to be authenticated in each realm • Reactive Cross-Realm Scheme (RCRS): • User can acquire TGT for to-be-visited realm from registered Realm • Reactive: acquires service ticket at the time of service • MASA: • Uses Cross realm mechanism • Reduces number of messages (overhead) • Proactive: acquires TGT and service ticket before the service request • Reduces latency

15. MASA Implementation: Basic Idea • Event based • Assume network layer mobility events can be mapped to Realm layer mobility events • Service Table: services needed by user in each Realm he visits • Upon Move_to_Realm_Warning(Rnext) • get TGT for Rnext using cross-realm mechanism in Rhome • Get service ticket from TGT from Rnext for each service needed from Rnext

16. MASA Implementation: Detail Rhome MASA Server Cross-Realm Rnext Rcurrent Initial log on Get ticket from home TGT_next Servicenext Mobile User MASA Client MobileUser MASA Client Move to R_next

17. MASA Implementation: Comments • Client-Server Architecture • MASA – client is light weight • MASA – Server maintains user profile and maintain mobility data • Reduce message generated by Mobile client • Saves wireless bandwidth • Saves mobile energy

18. MASA Cost Analysis • fc: frequency service (call) request • fm: frequency of moves (change of realm) • CMR (Call-to-Mobility Ratio): • Cost: Either Number of Messages or Latency • Normalized Cost = fc(cost of each service request) + fm (cost incurred on each move) • Find CMRs for which CostMASA < Costold_scheme

19. MASA Cost Analysis Continued • Consider Only message generated by mobile • a: cost of long distance message compared to local message • Costncrs = 2fm + 3*fc • Costmasa = 2afm + a*fc • MASA is better if Costmasa < Costncrs • i.e. CMR > 2(a-1)/(3-a) • If a == 1 then for CMR >0 MASA better than NCRS • If a==2 then for CMR > 2 MASA better than NCRS

20. Installing OpenAFS for Windows • Select the 64-bit EXE installer for Windows • Select a location to install OpenAFS • In CellServdB, delete all other contents except that of the required domains(eg:asu.edu) • In the Client cell name configuration window, set the AFS cell name to asu.edu

21. After Installation • Ticket manager will start upon login and display a ticket initialization window • Initialize the ticket using the Network ID • If successful, the ticket and tokens can be viewed by clicking on the Kerberos icon.

25. MASA Emulation Using Java Kerberos 1.1 User used TGT to get Service Ticket For Realm2 Successfully authenticated By Realm2 Running Java Kerberos to Acquire Service Ticket Realm2:PNM2.PG Running Java Kerberos to Acquire Service Ticket Realm1: PNM.PG

37. Many thanks to • Dr.DijiangHuang • Our classmates • Wenzhe Jiao

38. References: • ftp://ftp.cis.upenn.edu/pub/papers/scedrov/k5cr.pdf • http://www2.imm.dtu.dk/courses/02345/Lab4/krb5-UserGuide-1.1.pdf • http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf • http://kickjava.com/src/javax/security/auth/kerberos/KerberosPrincipal.java.html

39. Thank You…!!!