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

• Network Layer Mobility– ensures connection for mobile users

• Service Layer Mobility– ensures services for mobile users

Modification to Our Proposal

Proactively acquiring TGT and service tickets in realms to be visited

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

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

No-Cross-Realm(NCR) Message Exchange for Realm1 for Mobile Users

1) Client ---C, TGS--------------------------------> AS2) 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

NCR Message Exchange for mobile users for Realm2

1) Client ---C, TGS--------------------------------> AS2) Client <------TGT-------------------------------AS3) Client -------TGT,Service,authenticator--->TGS4) Client <---------Service Ticket ------------TGS5) Client---Service Ticket, Authenticator ->Server

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

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

Brisbane, Sep 2003

Kerberos V4 Cross-Realm Authentication

Client's Realm

Server's Realm

TGTRequest/

Reply

ClientServer

ServiceTicket

Request/Reply

ServiceRequest/Reply

lKDC

rKDCCross-Realm Ticket

Request/Reply

Rep

ly:

{Tic

ket}

k(lt

gs)

Rep

ly:

{Tic

ket}

k(rt

gs)

Reply: {Ticket}k

(s)

inter-realm key

Request: {Ticket}k(s)

Ticket Flow

Tutorial Slide from Jourge Cuellar

Kerberos 5

• Allows for trusted path• Hierarchical Realm• Non-hierarchical (shortcuts)

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

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

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

MASA Implementation: Detail

Rhome

MASA Server

Mobile User

MASAClient

Initial log onGet ticket from home

RcurrentRnext

Cross-Realm

MobileUser

MASAClient

TGT_nextServicenext

Move toR_next

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

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

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

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

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.

Many thanks to

• Prof. Dijiang Huang• Wenzhe Jiao

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

Thank You…!!!