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, TGS--------------------------------> AS 2) Client <------{T C,tgs, K c,tgs }K c ----------------AS 3) Client -------T c,tgs, A c,tgs, S------------------> TGS 4) Client <---------{T c,s, K c,s, }K c,tgs ------------TGS 5) Client-----------T c,s, A c,s- -------------------->Server

8. NCR Message Exchange for mobile users for Realm2 1) Client ---C, TGS--------------------------------> AS 2) Client <------TGT-------------------------------AS 3) Client -------TGT,Service,authenticator--->TGS 4) Client <---------Service Ticket ------------TGS 5) Client---Service Ticket, Authenticator ->Server

9. Message Exchange Steps for different realms service for mobile users with cross-realm 1) Client -------A c,itgs, RTGS---------------------->ITGS 2) Client <---------{K c,rtgs, T c,rtgs, }K c,itgs -----------ITGS 3) Client---------T c,rtgs, S------------------->RTGS 4) Client<----------{T c,s- }K c,s --- -----------RTGS 5)Client----------T c,s, A c,s ---------------->Server

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

11. Brisbane, Sep 2003 Kerberos V4 Cross-Realm Authentication Ticket Flow 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(R next ) – get TGT for R next using cross-realm mechanism in R home – Get service ticket from TGT from R next for each service needed from R next

16. MASA Implementation: Detail R home MASA Server Mobile User MASA Client Initial log on Get ticket from home R current R next Cross-Realm Mobile User MASA Client TGT_next Servicenext 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 f c : frequency service (call) request f m : frequency of moves (change of realm) CMR (Call-to-Mobility Ratio): Cost: Either Number of Messages or Latency Normalized Cost = f c (cost of each service request) + f m (cost incurred on each move) Find CMRs for which Cost MASA < Cost old_scheme

19. MASA Cost Analysis Continued Consider Only message generated by mobile a: cost of long distance message compared to local message Cost ncrs = 2f m + 3*f c Cost masa = 2af m + a*f c MASA is better if Costmasa < Cost ncrs – 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.

23. Many thanks to Prof. Dijiang Huang Wenzhe Jiao

24. References: ftp://ftp.cis.upenn.edu/pub/papers/scedrov/k 5cr.pdf ftp://ftp.cis.upenn.edu/pub/papers/scedrov/k 5cr.pdf http://www.isoc.org/isoc/conferences/ndss/9 9/proceedings/papers/wu.pdf http://www.isoc.org/isoc/conferences/ndss/9 9/proceedings/papers/wu.pdf http://kickjava.com/src/javax/security/auth/k erberos/KerberosPrincipal.java.html

25. Thank You…!!!