1 / 25

Kerberos5 with Mobile Agent Service Authenticator (MASA)

Kerberos5 with Mobile Agent Service Authenticator (MASA). By: Poonam Gupta Sowmya Sugumaran. Problem Statement. Our goal is to ensure that authenticated mobile users receive the services without interruption and with less overhead and delay. Mobility Services.

fitzgerald-gardner
Download Presentation

Kerberos5 with Mobile Agent Service Authenticator (MASA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 <------{TC ,tgs , Kc,tgs}Kc----------------AS 3) Client -------Tc,tgs , Ac,tgs , S------------------> TGS 4) Client <---------{Tc,s , Kc,s , }Kc,tgs ------------TGS 5) Client-----------Tc,s , Ac,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 -------Ac,itgs, RTGS---------------------->ITGS 2) Client <---------{Kc,rtgs ,Tc,rtgs, }Kc,itgs -----------ITGS 3) Client---------Tc,rtgs, S------------------->RTGS 4) Client<----------{Tc,s-}Kc,s --- -----------RTGS 5)Client----------Tc,s , Ac,s ---------------->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.

  22. Many thanks to • Prof. Dijiang Huang • Wenzhe Jiao

  23. References: • ftp://ftp.cis.upenn.edu/pub/papers/scedrov/k5cr.pdf • http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf • http://kickjava.com/src/javax/security/auth/kerberos/KerberosPrincipal.java.html

  24. Thank You…!!!

More Related