WIDE Technical-Report in 2006

Kerberos based AAA framework formobile networks
wide-tr-nautilus6-krb-in-nemo-00.pdf

WIDE Project : http://www.wide.ad.jp/

If you have any comments on this document, please contact to ad@wide.ad.jp

Kerberos based AAA framework for mobile networks
Saber Zrelli and Yoichi Shinoda
Japan Advanced Institute of Science and Technology
Ishikawa, JAPANe-mail: zrelli,shinoda@jaist.ac.jp
January 5, 2006

Abstract

several type of usage, the PANA [3] protocol, usedin the front-end of the AAA framework, can not
perform AAA operations for services other than network access service. Therefore, there is need to deploy a second AAA framework for application services. In such case, the operator would need to
manage two sets of credentials and assure the synchronization between the two AAA systems. The
users on the other side, would need to interact with
two AAA systems which can be inconvenient.
In environments such as mobile networks, thisconstraint might have more impact since users canbe using a variety of mobile devices with low computational capabilities that can not implement too
many AAA protocols neither support more than one
kind of credentials.
Our paper addresses this issue, and provides a
generic AAA framework that can handle network
access service as well as application services.
The AAA framework that we propose in this paper adapts the widely used Kerberos authentication
protocol, generally deployed in Intranets, and extends its functionalities for use in commercial mobile network environments. The system offers single
sign-on access to the environment while maintaining authorization granularity allowing the operator
to control access to each service independently.
The remainder of this paper is organized as follows : In section 2, we introduce the NEMO technology used by mobile networks to provide seamless Internet connectivity service. Then, in section
3, we describe the current practices on the matterof AAA and network access while stating the motivations behind our work. In section 5, we describea case study scenario of commercial services using
mobile networks. We will use to this case study toillustrate the AAA framework proposed in this paper. The requirements of an AAA framework are

Network operators and service providers are interested in mobile networks due to the number of newservices that can be deployed using the infrastructure of the embedded network. Probably, the most
attractive service is the seamless Internet connectivity offered by NEMO, the NEtwork MObility protocol. Such service would allow passengers to benefit
from a seamless Internet connectivity while they areon board of a vehicle. However, in order to deploy
these kind of commercial services, an AAA systemthat responds to the requirements and constraintsof mobile networks must be designed beforehand. In
this paper, we describe a single sign-on AAA framework based on Kerberos that takes in consideration
the specificity of mobile networks.

keywords
AAA, Mobile networks, NEMO.

1

Introduction

Commercial Mobile networks are commercial networks embedded in a moving infrastructure, suchnetworks can be deployed in public transportations
such as airplanes, trains or buses. Several services
can be offered to subscribers, Internet connectivity and application services are distinct categories
of services that the AAA framework of the mobile
network must manage.
The IETF AAA and PANA working groups, focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. While the back-end AAA
protocols such as Diameter [1] and RADIUS [2] aregeneric purpose protocols that can be adapted for1then listed in section 4. We introduce, then, in section 6, the Kerberos and the ASP protocols which
are the basis of our proposal. Finally, in section 7,
we go into the details of the proposed AAA framework by describing its components and the different
operations.

such as Diameter and RADIUS are generic purpose
protocols that can be adapted for several type ofusage, the PANA protocol, used in the front-end of
the AAA framework, can not perform AAA operations for services other than network access service.
Therefore, there is need to deploy a second frontend system in additional to PANA, for handelingthe access control and authentication to application
2 NEtwork MObility support
services that can be deployed in a conventional acA typical commercial deployment of services based cess network or within a NEMO network.
on mobile network technologies would provide InterThe use of Kerberos as a generic AAA framework
net connectivity service for its customers. NEtwork would allow the centralization of the AAA operaMObility (NEMO) support mechanisms [4] have re- tions. AAA operations for Network access and forcently been specified by the IETF to allow a mobile application services can be centralized and managed
network referred to as a NEMO network, to mi- by the same system. Several advantages can result
grate in the IP topology while maintaining contin- from this choice. First, the users can use the sameues IP connectivity for the internal nodes. NEMO credentials for all the provided services. Second, thenetworks use mobile routers (MR) [5] to connect generic AAA framework is more convenient for theto the Internet. The the mobile network nodes user since if different authentication system where(MNNs) located inside the mobile network bene- deployed (one for network access and the other for
fit from a seamless Internet connectivity while the application servers) the users would need to permobile router changes its location from a network form authentication and prove his/her identity atlink to another.
least two times. Whereas when using a generic KerThe mobile router maintains a tunnel with a beros based authentication system, the user needs
Home Agent (HA) [5] located in the home network. to prove his/her identity only once (where the sinWhile the MR changes its link location, it obtains gle sign-on feature of Kerberos). After users obtain
new IP addresses from the visited links. To main- Kerberos credentials that prove their identity, theytain the tunnel with the HA, the MR sends bind- can obtain authorization for accessing different sering updates to tell the HA about the new IP ad- vices (including Internet connectivity) without needdress (Care of Address). All the traffic generated for re-authentication. Furthermore, the administraby nodes located inside the NEMO network is for- tive burden of managing two AAA systems would
warded by the MR to the HA through the tunnel. be avoided. Deploying more than a single AAA sysFrom there, the HA forwards the packets to the tem, may cause scalability problems and increase
Internet. Packets coming from the Internet in des- the probability of human mistakes. For these reatination to the NEMO network are tunneled by the sons, we thought about the generic AAA system
HA to the MR and then forwarded to the final des- based on Kerberos that can be used, but not limtination located inside the NEMO network.
ited, for environments where the network access serIn the remaining of this paper, we consider that vice is as important as any other application service.
the mobile networks are NEMO networks equipped
The contribution of this work consists on the dewith MRs in order to provide seamless Internet con- sign of an authentication and authorization framenectivity for the internal nodes. The mobile net- work based on Kerberos. The designed framework
work also, deploys several other services other than reuses the intra-realm Kerberos authentication andthe Internet connectivity service.
a modified version of Kerberos cross-realm proto-

3

col. The reason of the imported modifications arethat the actual cross-realm operations specified by
the Kerberos protocol does not allow a client to obtain credentials in a realm different than his homerealm unless the client has already obtained Internet connectivity in the visited realm. This is a typical pre-authentication problem which makes Ker-

Motivations and related work

The IETF AAA and PANA working groups, focusedon the development of requirements for Authentication, Authorization and Accounting as applied to
network access. While the back-end AAA protocols
2beros not usable for network access control. Furthermore, the cross-realm operations in Kerberos
are client-centric, and assume that the user’s device
have the required capabilities for processing several cross-realm messages exchanged with the homerealm and other intermediary realms.
In our study, we assume that the devices used as
mobile network nodes can have low computational
performances and thus might not afford processingof multiple cross-realm exchanges without inflicting
unacceptable delays. Hence, the modification that
we designed, with the goal to deliver Kerberos credentials to users before granting them full network
access and which have the advantage of delegating
the cross-realm operations to the AAA server of thevisited realm instead of being handled by the user’s
mobile device.

• Authorization : In order to access services offered inside the mobile network, the users must
be authorized by the AAA system. During theauthorization process, the AAA system decides
if a user is allowed or not to access a certain
service according to the user’s privileges.
• Avoid abuse of credentials : The AAA system must take into consideration that the business model might impose some constraints onuser’s credentials such as exclusivity and limitation on space and time ; purchased credentials must be used exclusively by one client at
the time, and only on the designated location
for the designated period of time.

4.2

4

AAA framework requirements

The following requirements comes from the natureof mobile networks, mainly the facts that mobile
networks can be off-line sporadically for short orlong periods of time when no access network isreachable. And the fact that the mobile devices
computational capabilities as well as the available
bandwidth requires optimization of the AAA operations.

In this section we describe the requirements for the
AAA system that we need for the deployment ofcommercial services in mobile networks. Some of
the requirements listed below are not specific to mobile network environment, whereas others are specific requirements coming from the constraints introduced by mobile networks.

4.1

Requirements specific to mobile networks

Generic requirements• Optimity of authentication and authorization process : Mobile networks generally use wireless media to connect to fixed access networks. The optimity of AAA operations should allow efficient use of the limited
bandwidth on one hand, and provide acceptable delays for performing AAA operations before granting service access to the MNNs. Furthermore, mobile devices used as MNNs might
have limited computational capacities. The
AAA system must take these constraints into
account and perform AAA operations accordingly in order to provide acceptable delays.

These requirements apply to any commercial deployment of network based services. Since in thispaper we consider commercial deployments of services in mobile networks, the AAA system mustobey to the same requirements.
• Security : The AAA system must be safe andsecure. This requirement is essential considering the fact that mobile networks are deployedin open environments and are exposed to many
threats. Session keys and credentials must be
protected to avoid their exploitation by malicious users.
• Authentication : Mutual authenticationmust be performed between the different entities. Users must be authenticated to provethat they are who they are claiming to be. On
the other hand, services must be authenticatedby users to avoid man in the middle attacks.

• Robustness against Internet connectivity outage : Since mobile networks can often
be subject to lost of Internet connectivity, theAAA system must attenuate the impact of Internet outage on the global operations inside
the mobile network.
3

5

Case study: NEMO-Bus

are some examples of such services. The passengers
connect to the Intranet of the NEMO-Bus (which
advertises the MR’s home network prefix) in orderto acquire an IP address, then access the services
by communicating with the application servers or
by using the MR to communicate with the Internet.

In this section, we describe a case study of deployment of commercial services based on NEMO. The
goal of such deployment is to provide Internet connectivity as well as other services to the customers
inside a mobile network. We will use the NEMOBus as an example to explain the architecture andthe operations of the proposed AAA framework.
The NEMO-Bus is a bus equipped with a mobile 6 Backgroundrouter that provides Internet connectivity to the inIn this section we introduce the background on
frastructure located inside the bus. The NEMOwhich our proposal is based. It is essential to underBus is owned by a bus company wishing to offer
stand the Kerberos protocol in order to be able toseveral services for its passengers during their trip.
understand the general operations of our proposal.
Furthermore, we designed an inter-realm protocol
for Kerberos (ASP) that we will use in the proInternet
posed AAA architecture. This section will explain
the operations of Kerberos and the ASP protocols.
AR

6.1

HA
MR
HA

Svcs
Internet
Access

Kerberos

Kerberos [7] is a widely deployed authentication system that offers three-party scheme for session key
distribution between services and clients [8]. The
Kerberos protocol involves Kerberos servers or Key
Distribution Centers (KDC) and principals.
The principals correspond to the users and servicesof the realm and they share long-term keys with the
KDC.
Fig. 2 shows the Kerberos protocol components
and operations.
The KDC have two components ; an Authentication Server (AS) and a special principal (service) called Ticket Granting Service (TGS).
The AS delivers the credentials required for sharing
a session key and performing authentication with
the TGS, while the TGS delivers credentials required for sharing a session key and authentication
with the application servers.

HA
Home network

Accessapplication
services

Passenger(MNN)
NEMO-Bus

Figure 1: The NEMO-Bus service deployment
In order to deploy a service such as NEMO-Bus,the bus company must deploy the NEMO protocolcomponents by installing NEMO mobile routers oneach bus (“MR” in Fig. 1) and setup home agentsin the home network (“HA” in Fig. 1). Furthermore, there must be agreements with access operators that owns the access routers along the bus’ s
itinerary (“AR” in Fig. 1). After proceeding to theagreements, the bus company must setup the required AAA infrastructure needed to authenticate
the MRs and bootstrap the NEMO protocol 1 .
Inside the NEMO-Bus, several services are offeredto the passengers (“svcs” in Fig. 1). Internet connectivity, Web proxy2 and multimedia streaming• (1,2) : To share a session key with the TGS,
the user obtains from the AS a session key encrypted using the long-term key shared with
the KDC. We will refer to this session key as
TGS session key. The user also receives a
Ticket Granting Ticket (TGT) which is amessage that contains the same TGS session

1

The mobile router of the NEMO-bus uses access routers
located along the road to reach the Internet. The mobilerouter must perform authentication with the access routers,[6] describes an AAA architecture for the authentication of
Mobile Networks by the access network operators.
2
Such service requires Internet connectivity, the web proxycan use the MR to connect to the Internet. Such kind ofservices can be used to create application services based on
Internet without providing full Internet connectivity to theclients4

vided service. The authenticator here, is encrypted using the service session key and acts
as a proof that the client has successfully obtained the service session key after decrypting
it using the TGS session key shared with the
TGS.

KDC
TGS

AS

(4) (3)(2) (1)• (6) : On reception of a client request, the application server decrypts the service ticket using
its own secret key and obtains the service session key shared with the client. Using this session key, the application server authenticatesthe client by decrypting and validating the authenticator.

(5)

Client(6)Service

1 : [ UserName ]2 : [ TGT ] TGS Key [ TGS Session Key ] User Key
3 : [ TGT] TGS Key[ SvcName ] [ Authenticator ] TGS session key

The tickets (TGT and ST) have a lifetime after
which they expire and must be renewed. Timestamps included in the tickets indicate to the servers
if the ticket has expired or not.

4 : [ ST ] Service key [ Service session key ] TGS session key
5 : [ ST ] Service key [ Authenticator ] Service session key

Figure 2: The Kerberos authentication protocol

6.2

key and encrypted using the TGS’s key shared
between the TGS and the KDC.

ASP : The inter Authentication
Servers Protocol

The AAA system proposed in this paper is basedon Kerberos. It extends the functionalities of thisprotocol by adding a protocol between two Kerberos key distribution centers. The inter-KDC protocol is called Authentication Servers Protocol(ASP). Its role is to allow Authentication servers(AS) of visited realms to provide a TGT and a TGS
session key for roaming users so they can be authenticated by the local TGS.

• (3) : The client sends the TGT to the TGS,
along with an authenticator in a request asking for credentials required for authentication
with certain service. The authenticator is amessage encrypted using the TGS session key
and acts as a proof that the client has successfully obtained the TGS session key after decrypting it using the long-term key shared with
the KDC.

AS@V

(2)

ASP-REQ

AS@H• (4) : After decrypting the TGT (which was(3)
ASP-REP
encrypted by the AS using the long term key
Users DB
shared between the TGS and the KDC), theHome realm
TGS extracts the TGS session key. Using that
AS-REPsession key, it authenticates the user by de(1)(4)
AS-REQ
crypting and validating the authenticator. Finally, The TGS sends back to the user a newly
generated session key encrypted using the TGS
Client@H
Visitted realm
session key. We will refer to this session key as
Service Session Key. The user also receives
a service ticket (ST) from the TGS, which is Figure 3: The Inter Authentication Servers Protoa message that contains the same service ses- col (ASP)sion key and encrypted using the key shared
between the application server and the KDC.
• (5) : The client sends the service ticket to theapplication server, along with an authenticator in a request asking for accessing the pro5

6.2.1

Protocol overview

from AS@H to AS@V then intercept the TGT delivered by AS@V to the user. With these two informations in hand, he can perform a replay attack
that would allow him to impersonate the real user
and obtain credentials to access services in the visited realm.
In order to avoid tits threat, the TGS session
key must be secured and encrypted in the ASPREP message sent from AS@H to AS@V. For tits
purpose, the ASP protocol uses public-key cryptography (in conjunction with an established Public
Key Infrastructure) to perform mutual authentication between ASs and to secure sensible data transported by the ASP protocol.
In the ASP-REQ message, AS@V includes its
public key and a signature that would allow AS@H
to authenticate the identity of AS@V. AS@H checks
the validity of the public key based on the PKI
infrastructure and then checks the authenticity of
AS@V by verifying the signature. After issuing the
TGS session key, AS@H encrypts it using the public
key of AS@V then sends it in the ASP-REP message. In the reply message AS@H includes its own
public key and a signature that will allow him toprove its identity to AS@V.

Fig. 3 shows the use of the ASP protocol between
two authentication servers.
1. The roaming user starts by asking the AS ofthe visited realm (AS@V) for credentials to authenticate with the TGS of the visited realm(TGS@V). In the client request (AS-REQ), theuser specifies his name and his home realm.
2. Based on the informations on the information
AS@V knows that it is dealing with a roaminguser. As a result, AS@V sends an ASP request(ASP-REQ) to the AS of the user’s home realm(AS@H), this request contains the user’s name,the visited realm’s name and the public key of
AS@V along with a signature.
3. On reception of the ASP request, AS@H authenticates AS@V using the public key and thesignature from the ASP-REQ message. Then,
AS@H creates a TGS session key and encrypts
it using the user’s key. The reply to AS@V
(ASP-REP) will contain the same TGS session
key encrypted using the public key of AS@V.
AS@H also includes in the reply message its
own public key and a signature that will be
used to prove its identity to AS@V. The ASPREP message can also transport authorization
data that implements the policy of AS@H fordelivering credentials to its roaming users, thisauthorization data must be encrypted using the
public key of AS@V.

7

The AAA framework proposed in this paper offers
authentication and authorization facilities for delivering services inside a mobile network. We will use
the case study (NEMO-Bus) described in Sect. 5
as an example to illustrate the different parts andoperations of our proposal.

4. When AS@V receives the ASP-REP message
from AS@H, it authenticates the remote peer
(AS@H) based on the public key and signature
received in the reply message, then it decrypts
the TGS session key using its own private key.
Finally AS@V creates a TGT that includes
the TGS session key received from AS@H andsends the credentials to the user in the AS-REP
message which consists on the TGT along with
the TGS session key encrypted using the user’s
key as received from AS@H.
6.2.2

The proposed AAA framework

7.1

Components of the AAA framework

Fig. 4 shows that the AAA framework is composedof two parts. The first component consists on the
AAA servers (a central AAA server and embedded
AAA servers on the NEMO-Buses) that will provide Kerberos credentials to the clients. The second
component consists on the access control framework
which role is to restrict the access to the services deployed within the NEMO-Bus.

Securing the ASP protocol

7.1.1

AAA servers

We assume that the cross-realm exchanges between The AAA framework deploys a central AAA server
AS@V and AS@H are subject to sniffing. A mali- which is a Kerberos Authentication Server (AS)cious user can intercept the TGS session key sent that participates in ASP exchanges for providing
6

ARInternet
MR
Central AAA srv
AS

Svcs

EP

ASP

Embedded AAA srv
TGSInteretAccessST

HA
buscompany.com

AS

TGT

Accessapplicaiton servers

Register new user

Passenger(MNN)

Vending system

NEMO-Bus (bus-234.buscompany.com)

Figure 4: Single sign-on AAA framework for mobile networks
Access control for the application servers
Each application server implements the Kerberos
authentication method, which means that it cancheck user’s service ticket and decide whether togrant access or not according to the authentication
phase.

credentials (TGTs) to users located in the NEMOBuses. The central AAA server keeps information
about the users in a database, these information include the user’s ID, the user’s password, the bus
where the user is supposed to be, and authorizationdata.
On each NEMO-Bus, an AAA server is deployed(“embedded AAA srv” in Fig. 4). This server iscomposed of an AS and a TGS. It keeps information
about the services offered by the NEMO-Bus anddelivers service tickets to the users that have a valid
TGT.
The NEMO-Bus is considered as an independent
realm. And the realm name of the central AAA
server must be different from the realm name ofthe embedded AAA servers. Each NEMO-Bus has
thus its own realm name. For example, we can have“buscompany.com” for the realm name of the central AAA server, and “bus-143.buscompany.com” asa realm name for a NEMO-Bus owned by the bus
company.

Access control to the MR (Internet connectivity service) The Internet connectivity serviceis handled in a different way than the other application services. The access to the MR can not be
controlled by the MR its self since there is no way
to perform the authentication of users (based on
Kerberos credentials) before forwarding their traffic
to the Internet. For this reason, the access control
framework deploys an enforcement point (“EP” in
Fig. 4) which role is to control the access to the
MR. The EP consists on an IP firewall and a firewall controller service (FCS). The EP is the only
access point to the MR, the authorized user traffic
is sent to the EP before being forwarded to the MR 3 .
The FCS service implements the Kerberos authen7.1.2 Access control frameworktication method. Users with valid service tickets
The role of the access control framework is to au- can authenticate to the FCS and have their traffic
thenticate users who have obtained valid service forwarded trough the MR.
tickets from the embedded AAA server. These services tickets are used by the clients to authenticate
3
The communication between the EP and the MR uses anwith the application servers before accessing the ac- IPSec tunnel that provides security against any threat thattual services.
might come from malicious users in the NEMO-Bus
7

7.2

System operations

application services to decide about the service parameters and quality for the current user.
The Kerberos protocol in its self does not support authorization. In this paper , we only describeof an authorization mechanism that could be integrated with the authentication process. However,The details related to the storage and transport of
the authorization data are not in the scope of thisdocument.
In order to avoid abuse of credentials, the central
AS verifies that the realm name of the bus issuing
the ASP request matches the realm name of the busthat the user registered for. This allows the AAA
system to avoid the use of the same credentials in
multiple buses or in a different bus than the one
chosen initially by the passenger. The central AS
verifies also that the user have not issued a TGT yet,or that the lifetime of the issued TGT has expired.
This allow the AAA framework to avoid the useof the same credentials in the same time by morethan one passenger. The acquisition of a TGT fromthe embedded AS is illustrated by the arrow labeled“TGT” in Fig. 4.
The user needs a TGT and a TGS session key
only once. However, the operator can impose a lifetime for the TGT, this would oblige the user to obtain a new TGT with a new TGS session key when
the current TGT expires.

In the following section, we describe the AAA operations that will allow the clients to obtain and use
credentials for accessing the services provided in the
NEMO-Bus.
7.2.1

Registration of users

When a passenger is planning to access service offered in the NEMO-Bus, he/she have to pay thecorresponding fees when issuing the bus ticket. The
passenger can choose which services he/she would
like to use and optionally a class of users. Afterpaying the services and the transportation fees, an
ID and a secret key are provided to the customer.
The central DB accessible to the central AS is thenupdated with the following information : The userID, the associated password, the bus that the customer is going to take, the services that the customer bought and the class to which the user belongs. The registration process is illustrated by thearrow labeled “register new user” in Fig. 4.
7.2.2

Acquisition of a TGT and a TGS session key

When the customer is in the NEMO-Bus, he/shewould like to use the services offered on board. For
that, the passenger uses his device to communicate
with the embedded AS in order to obtain a TGT
and a TGS session key that will be used to authenticate with the embedded TGS and share a key with
it.
The request sent to the embedded AS contains
the client’s name and the client’s home realm name(which corresponds to “buscompany.com” since theclient is registered as a Kerberos principal in thecentral AS’s database).
On reception of a client request, the embedded
AS initiates an ASP exchange with the central AS(Arrow “ASP” in Fig. 4). The result of the ASP
will allow the embedded AS to provide a TGT anda TGS session key to the passenger (as explained
in section ). The TGT (which is encrypted using
the TGS’s secret key) will contain the authorization
data received from the central AAA server. Theseauthorization data will be used in the next steps
by the TGS first, to check if the user is authorized
to access the requested services. And later by the

7.2.3

Acquisition of a service ticket and aservice session key

After obtaining the TGT and the TGS session key
from the embedded AS, the user can ask for credentials to access the services offered by the NEMOBus. This phase corresponds to the steps 3 and 4 of
the Kerberos protocol described in the section 6.1.
The client sends the TGT along with an authenticator to the embedded TGS. The request also contains the service name that the user wishes to access. The service name could be “FCS” if the user
wishes to obtain a service ticket for accessing the
MR or different service names for accessing otherapplication services.
As mentioned in the beginning of this section,
when the user buys the services, authorization datais created and stored in the central AS’s database.
The authorization data is included in the TGT and
used by the TGS to decide if the user is allowed or
not to access the requested service. When creating
a service ticket, authorization data ,interpretable by8the application servers, can be included. This would
provide a second authorization level controlled by
the application service (see section 7.2.5 for moredetails).
The acquisition of service tickets from the embedded TGS is illustrated by the arrow labeled “ST”
in Fig. 4.

ticket for the service name “WEB” for using the
web-proxy service in the NEMO-Bus). The user
then sends a request message directly to the application server which implements the Kerberos authentication method. Based on the user credentials, theapplication server authenticates the user and provides the service.
The application service and the client can use theKerberos credentials, for setting up IPSec [9] secu7.2.4 Accessing services
rity at IP level using the KINK [10]. Or, simply
After obtaining a service ticket from the embedded use the shared secret key resulting upon successful
AAA server, the user must perform authentication authentication, to perform symmetric-cryptography
with the access control framework (described in sec- based security at application level.
tion 7.1.2). The access phase depends on the service. In the following paragraphs, we describe the7.2.5 Service parameters and authorization
access phases for the Internet connectivity service
granularityand for the application services.
In order to provide differentiated classes of serAccessing the Internet Before getting to the vices, the AAA framework supports a second authoInternet access phase, the user must have already rization level additionally to the first authorization
obtained a service ticket for the service named phase performed by the embedded TGS for deliver“FCS”. The user sends an AP-REQ message to the ing service tickets to the users (Section 7.2.3).
The second level of authorization is be performed
FCS service running on the EP. The request message contains the service ticket as well as an au- by the application servers and is based on the authenticator. The FCS authenticates the user then thorization data included in the service ticket. This
set-up the local security policy (by adding a new information is used by the application server to derule to the IP firewall deployed on the EP) to allow cide which class the clients belongs to, and sets theservice parameters accordingly. As an example, For
the traffic of the client to reach the MR.
If the credentials provided by the client are valid, the Internet connectivity service, the service paramthe FCS replies to the client with a message that eters could correspond to different bandwidth allonotifies the user about the success of the authen- cation. This allows users to choose the speed of theirtication and the authorization process. After this, connection when they buy the Internet connectivity
the user can benefit from the Internet connectivity service.
service offered by the MR.
The authentication of the user by the FCS service
corresponds to the steps 5 and 6 of the Kerberos
protocol described in section 6.1 and is illustrated
by the arrow “Internet access” in Fig. 4.
In order to protect the user traffic between the EP
and the client’s device, the Kerberos credentials canbe used for setting up IPSec [9] security associations
as described by the KINK [10] protocol. The IPSec
protocol would then be used to protect the traffic
against malicious users located inside the NEMOBus.

8

Conclusion

In this paper, we described an AAA framework that
performs Authentication and Authorization of users
inside mobile networks. The authorization granularity, allowing independent authorization for eachservice, is performed using authorization data included in the credentials. Furthermore, the single
sign-on feature of the AAA framework allows theoperations inside the mobile network to be less dependent from a central AAA server. The embedded AAA server needs to contact the central AAA
server only one time for each user. For this purpose,
the ASP protocol was designed to provide a mean
for the embedded AAA server to deliver Kerberos
credentials for the users inside the mobile network.

Accessing application services For accessing
services other than the Internet connectivity service. The user need to have the service ticket that
corresponds to the application service (e.g. service
9Our proposal responds to the requirements listed [8] Mihir Bellare and Phillip Rogaway, “Provably
in section 4 by designing authorization support andsecure session key distribution: the three party
suitable cross-realm authentication mechanism forcase,” in STOC ’95: Proceedings of the twentythe Kerberos protocol, which is in its self secure
seventh annual ACM symposium on Theory ofand designed for open system environments.
computing, New York, NY, USA, 1995, pp. 57–
The AAA standards define specialized protocols
66, ACM Press.
for controlling network access, while other application services are assumed to perform authentication [9] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” Tech. Rep.,and authorization based on a separate framework.
November1998.
Our solution, instead, defines a generic AAA framework offering integrated authentication and autho- [10] S. Sakane, K. Kamada, M. Thomas, and J. Vilrization functionalities for any type of service.
huber, “Kerberized Internet Negotiation ofKeys (kink),” Internet draft, IETF, July 2005,
Work in progress.
Copyright Notice
Copyright (C) WIDE Project (2006). All Rights
Reserved.

References[1] P. Calhoun, J. Arrko, E. Guttman, G. Zorn,
and J. Loughney, “Diameter Base Protocol,”Tech. Rep., IETF, September 2003.
[2] C. Rigney and A. Rubens, W. Simpson, S. Willens, Remote Authentication Dial In User Service (RADIUS), January 1997, RFC 2058.
[3] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig,
and A. Yegin, “Protocol for Carrying Authentication for Network Access,” Internet draft,
IETF, January 2005, Work in progress.
[4] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert, “Network
Mobility (NEMO) Basic Support Protocol,”Request For Comments 3963, IETF, January
2005.
[5] J. Manner and M. Kojo, “Mobility Related
Terminology,” Request For Comments 3753,
IETF, June 2004.
[6] Zrelli Saber, Ernst Thierry, Bournelle Julien,
Valadon Guillaume, and Binet David, “AccessControl Architecture for Nested Mobile Environments in IPv6 ,” Tech. Rep., SAR 2005 (4thConference on Security and Network Architectures), June 2005.
[7] J. Kohl and C. Neuman, “The Kerberos Network Authentication Service (V5),” Request
For Comments 1510, IETF, September 1993.
10