Authentication, Authorization and Accounting in Ad Hoc networks

26th of May 2000
Sami Levijoki
Department of Computer Science
Helsinki University of Technology
slevijok@cc.hut.fi

Abstract

Authentication, Authorization and Accounting (AAA) functionality is needed frequently in many network services. Typically authentication, authorization, and accounting are more or less dependent on each other. However, separate protocols are used to achieve the AAA functionality. IETF AAA working group is trying to design one AAA protocol that could be used in a variety of applications. AAAARCH is also trying to build a general architecture for AAA systems. Mobile Ad Hoc networking (MANET) brings new challenges to providing the AAA functionality. Ad Hoc networks are by their nature rapidly changing and dynamic. There isn't necessarily any network infrastructure present. These and other features of Ad Hoc networks present many new requirements for the protocols that are to be used in Ad Hoc networks.


Contents

1 Introduction
2 AAA overview
    2.1 General description of AAA systems
    2.2 Generic AAA architecture
3 Requirements for AAA protocols
    3.1 Authentication requirements
    3.2 Authorization requirements
    3.3 Accounting requirements
    3.4 Scaling and reliability of accounting
4 Existing protocols
    4.1 RADIUS
    4.2 DIAMETER
    4.3 ISAKMP/IKE
    4.4 SASL
    4.5 PolicyMaker
    4.6 KeyNote2
5 AAA in combination with Mobile IP
    5.1 General
    5.2 Architecture
6 AAA in Ad Hoc networks
    6.1 Threat and problems
    6.2 Authentication
    6.3 Authorization
    6.4 Accounting
    6.5 AAA systems
7 Conclusions

References

1 Introduction

Today we live in a world where almost everything must be protected from misuse and where nothing is free. When providing commercial network services to public, there are three things that are commonly needed. These are authentication, authorization and accounting. Authentication is needed to make sure that the user of the service is who he claims to be. This is quite important, because you don't want that someone else is using the service you have paid for. Usually authentication is provided by using a shared secret or a trusted third party. Related to authentication is authorization. After the user has been authenticated we need a way to ensure that the user is authorized to do the things he is requesting. For example, if you are a normal user you don't have the permissions to access all the files in a file system. Usually authorization is provided by using access control lists or policies. Accounting is the process in which the network service provider collects information of the network usage for billing, capacity planning and other purposes. This is important for the service provider, because there is no such thing as a free lunch.

There is a growing need to transfer data between different kind of devices that are close to each other. There might not be any kind of wired networking service available to achieve this and even if there would be it is not always a very easy way to transfer the data. So it would be reasonable for the devices to be able to communicate with each others while they are within range. Ad hoc networking tries to solve this problem. An Ad hoc network is a dynamically changing network that is created by the mobile nodes when needed for their own communication purposes. The mobile nodes can act as routers between the entities in the network. In an ad hoc network mobile nodes can come and go as they wish, so the topology of the network is changing quite rapidly. This creates new challenges for the protocols that are to be used in the ad hoc networks. Most of the traditional protocols don't fit very well into the ad hoc networks. In ad hoc networks there is also a need to authenticate users and authorize their actions.

This paper tries to give an idea about techniques and approaches that are currently available to achieve the AAA functionality and what kind of AAA model could be used in ad hoc networks.  However, because both fields are quite new and rapidly changing, there are not any standardised methods available to achieve these goals. Also many of the ideas presented in this paper are only proposals and as such evolving all the time.

The rest of this paper is organized as follows:

Section 2 gives a general overview of AAA systems and their architecture. In section 3 Authentication, Authorization and Accounting requirements for the AAA protocols are discussed . Section 4 introduces some existing AAA protocols and some other approaches to achieve the same functionality. In section 5 the architecture of the AAA in combination with the Mobile IP protocol is presented and its purpose is defined. Section 6 describes the difficulties in using the existing AAA protocols in Ad Hoc networks and gives some proposals of other methods that could be applied. In section 7 ideas presented in this paper are tied together and summarised.

2 AAA overview

An overview of AAA systems is given in this section. Background information, basic concepts, and generic architecture are presented.

2.1 General description of AAA systems

AAA stands for Authentication, Authorization and Accounting. These are the three basic issues that are encountered frequently in many network services. Examples of these services are dial in access to Internet, electronic commerce, Internet printing, and Mobile IP.

But what do we mean by these terms Authentication, Authorization and Accounting? These are quite broadly used, but their meanings can be mixed up. The following list defines how they are used in this paper.

One thing worth noticing is that in this paper the term authentication is used to denote the act of verifying an identity. This is noteworthy since the term has also other meanings, for example, the act of proving the authenticity of any object or piece of information [24].

Proposals for the AAA protocols and systems are currently being developed in the AAA working group [1] of the IETF. There is also another group in the IETF called the AAA Architecture Research Group (AAAARCH) [2], which is responsible for developing a generic AAA architecture [14]. The ideas presented in this and the next section are picked up from the documents produced by those groups. Later in this paper we explore also other approaches to providing the AAA functionality.

The goal of the AAA working group is to define one protocol that implements authentication, authorization and accounting and is general enough to be used in a variety of applications [1]. Currently we need separate protocols to implement authentication, authorization and accounting functionality. This is not desirable, because there are a lot of applications where all of these are needed together.

Full AAA protocols provide authentication, authorization and accounting in one protocol. There are not very many full AAA protocols available currently, because development in this area is just in the beginning of its lifecycle. The only real AAA protocols available are RADIUS [31] and DIAMETER [13] including their extensions [7,11,12,31]. These protocols are presented in section 4.

Usually the user has some home organization, or home domain, with which he or she has a service agreement. This home organization provides the service in the place where the user normally is. There are typically several organizations which are providing the same kind of service to the users. When the user moves and wants to have access to the service, while within a foreign domain (organization that is not the users home domain), there is a need to authenticate the user and authorize the use of resources. [14]

An AAA infrastructure typically consists of a network of AAA servers that interact with each other using an AAA protocol. The AAA servers authenticate users, handle authorization requests, and collect accounting data. The infrastructure may also include brokers. Brokers are used to mediate trust between entities that don't trust each others directly, i.e., they act as trusted third parties. For example, AAA servers in different organizations can change information by using brokers as mediators. [14]

2.2 Generic AAA architecture

There is an attempt going on to define a generic AAA architecture. This generic architecture is described in [14]. The approach taken in this architecture is to divide AAA functionality into the two parts: a generic part and an application specific part. The generic part defines the functionality that is common to all applications and the application specific part defines application dependent functionality. [14]

The AAA server interacts with the Application Specific Module (ASM). The ASM manages resources and configures service equipment to provide the service requested. The ASM may also be needed in the authorization process, because it has application specific information. [14]

The event log stores the events that happen inside the AAA server. This event data can be used to decide whether certain action is allowed or not. For example, there might be rules that give authorization only if some event has happened in the past. The policy repository is a database that contains information about available services and resources and the policy rules that are needed to make the authorization decision. [14]

In this architecture authorization  request goes as follows: [14]

  1. A user makes a well formatted authorization request to a server. This request should be formatted so that the AAA server doesn't have to know how to interpret any Application Specific Information in order to be able to make the decision.
  2. The AAA server checks the request, determines what kind of authorization is requested, gets a policy from a repository and performs one of the following actions.
    1. Forwards the request to the Application Specific Module (ASM) for evaluation.
    2. Makes the decision based on the policy repository data and an event log.
    3. Forwards the authorization request to another AAA server.

Figure 1. Generic AAA server interactions [14]

Authentication and accounting functionality is not yet defined in the generic architecture.

3 Requirements for AAA protocols

There are certain common requirements for the AAA systems. These requirements are presented in this section. The information that is presented in this section is in accordance to the AAA working group documents.

3.1 Authentication requirements

Authentication usually means that there is some way to ensure that the entity to which you are talking to is who it claims to be. This is called authentication of the channel end point. Usually you also need to authenticate yourself to the service in order for the service to be sure that you are you, not someone else who is pretending to be you. This is the authentication of the message originator.

Authentication can be based on different kinds of methods. The most usual case is the use of a password, but it isn't really a good choice, because passwords are typically short and easy to break. The more secure methods include the use of public key cryptography, challenge-response schemes, symmetric encryption, etc.

Authentication in general has several security requirements. These include protection against replay attacks, confidentiality, resistance against man-in-the-middle attacks etc. All of these are common to any authentication scheme to be used. More information about authentication methods and threats that they may have can be found in basic text books about computer security [4,32].

3.2 Authorization requirements

Authorization process is concerned with the decision whether some user request is allowed or not. Normally authentication is first needed, before authorization can be done. There are typically some policy rules that define what actions this particular user is allowed to do. An example of authorization is the access to networked file resources.

The model that is presented in this section for authorization is a centralized one. It is the model that is developed by the AAA working group [1]. There are also other kind of models, which are decentralized and are better for the ad hoc networks. Two such models are presented in the section 4.

We can identify four entities in a usual authorization situation. [35]

  1. The user who is requesting some service and needs to be authorized to access it.
  2. The user home organization with which the user has an agreement and which is used to check whether the user has the permission to use the service requested. The user home organization may contain information that is not known by the service provider, for example the user's credit.
  3. The AAA server of the service provider, which authorizes the service based on an agreement with the user home organization.
  4. The service equipment of the service provider, which provides the service itself. This might be, for example, a NAS (Network Access Server) in a dial-in service.

Figure 2. The basic authorization entities [35]

Authorization requirements for the AAA systems are defined in [17]. Here is a short list of the main requirements from [34].

There are three different kind of authorization sequences available. They are agent, push and pull. [35]

In the agent sequence the AAA server acts as an agent between the user and the service equipment. Figure 3 illustrates the agent sequence. First the user sends the request for the service to the AAA server (1). The AAA server applies a policy associated with the user to the service request. The server sends the request to the service equipment (2) and the service equipment sets up the service. The service equipment replies to the AAA server (3), telling that the service is set up. The AAA server replies to the user (4), telling that the service is ready for use. [35]


Figure 3. Agent sequence [30]

Figure 4 illustrates the pull sequence. In the pull sequence the user sends a request to the service equipment (1), which forwards it to the AAA server (2) . The AAA server decides whether to allow the service and sends the response to the service equipment (3). The service equipment sets up the service, if allowed and replies to the user (4) telling that the service is ready for use. [35]


Figure 4. Pull sequence [35]

Figure 5 illustrates the push sequence. In the push sequence the user needs to get a ticket from the AAA server telling that it is OK for this user to access the service (1,2). After this the user sends the request and ticket to the service equipment (3) and the service equipment verifies the ticket. If the ticket verification was successful, the service equipment sets up the service and sends a reply to the user telling that the service is ready for use (4). [35]


Figure 5. Push sequence [35]

3.3 Accounting requirements

In accounting we collect resource consumption data for different kind of purposes. This data can be used, for example, in trend analysis, capacity planning, billing, auditing and cost allocation. All of these have different requirements. The requirements also depend on the fact whether it is intra domain accounting or inter domain accounting. In intra domain accounting the accounting information doesn't cross administrative boundaries. In inter domain accounting the accounting information crosses administrative boundaries and is therefore more susceptible to the security violations. [3]

An inter domain accounting needs to handle the higher packet loss ratio and the alternate security requirements. So there might be a need for replay protection, non-repudiation, data object integrity, and confidentiality in addition to authentication. [3]

Trend analysis and capacity planning

In trend analysis and capacity planning losing some packets isn't a problem, because they are used to estimate future resource usage. So robustness against moderate packet loss is required in the intra domain case and robustness against high packet loss in the inter domain case. This is because the reliability of data transfer in intra domain and in inter domain cases is different. Also integrity, authentication and replay protection are required as well as confidentiality in the inter domain case. [3]

Billing

Billing can be either non-usage sensitive or usage sensitive. In a non-usage sensitive case no accounting information is required for billing. So in this case there is no harm, even if all the session data would be lost. In a usage sensitive case, however, an archival accounting approach is needed. Usage sensitive billing has also some processing delay constraints, because it is desirable to minimize the financial risk. As always when money is concerned there is a need for the authentication, integrity, and also for confidentiality and non-repudiation. [3]

Auditing

Auditing, which is the act of verifying the correctness of a process, needs accounting data in the verification process. This data has to be at least as reliable and secure as the data that the entity being audited is using. [3]

Cost allocation

Cost allocation and bill-back methods provide a way to access the network services on the cost of the enterprise. The users are typically company employees. This application has as strict reliability and security requirements as the actual billing process. [3]

Detailed introduction to the accounting management can be found in [3] and a detailed description of the requirements in [6].

3.4 Scaling and reliability of accounting

When accounting is considered there are three areas which should be taken into account. They are fault tolerance, resource consumption and the data collection model. [3]

The fault tolerance requirements are due to the fact that there is money concerned in the case of accounting. If the system isn't working for some reason that will result in a revenue loss. Typical fault situations are packet loss, network failures, accounting server failures and device reboots. These can be handled in a number of ways. For example non-volatile memory can be used. More detailed information about fault tolerance can be found in [3].

Accounting needs resources to work thoroughly. The most important ones are network bandwidth, memory, non-volatile memory and CPU time. Each of these resources have some impact on the overall system functionality and they should be considered when designing accounting. The resource usage can be optimized in many cases by using appropriate techniques. For example, network bandwidth usage can be optimized by using batching. [3]

There are several data collection models in use today. These include polling, event driven no batching, event driven with batching and event driven with polling. [3]

In a polling model the accounting manager polls all the devices at regular intervals for the accounting data. In an event driven no batching model, the devices will contact the accounting manager when they have data to be sent. Most protocols using this model put only one account event to each packet. In an event driven with batching model devices can contact the accounting manager when a batch of a given size is ready, when some data of a given type is available or when the minimum time has elapsed. In an event driven with polling model the accounting manager will poll the device when it receives an event. The device can send an event when a batch of given size is ready, when some data of a given type is ready or when the minimum time has elapsed. [3]

4 Existing protocols

Existing protocols are presented in this section. RADIUS [31] and DIAMETER [13] are real AAA protocols including Authentication, Authorization and Accounting functionality. ISAKMP/IKE [19,22] and SASL [23] include only Authentication features. PolicyMaker [8] and KeyNote2 [9] are trust management systems, which include both Authentication and Authorization features. Their approach to provide the functionality is quite different from the other protocols.

4.1 RADIUS

RADIUS protocol has been designed to carry authentication, authorization and configuration information between a NAS (Network Access Server) and a RADIUS server. It is typically used in combination with modem pools, which are used to access some service from outside. RADIUS uses a single database, where all the user authentication and other information is stored. This helps in the administration of this data. The NAS acts as a client and passes the user information to the RADIUS server and then acts according to the response from the server. The RADIUS server is responsible for processing client requests, authenticating the user and configuring the client to provide the service to the user. [30]

RADIUS uses shared secrets to authenticate transactions between the NAS and the RADIUS server. It also uses encryption to secure user passwords between the NAS and the RADIUS server. RADIUS can support different kinds of user authentication techniques. For example, challenge-response, PAP (Password Authentication Protocol) and CHAP (Challenge Handshake Authentication Protocol) can be used. RADIUS protocol is extensible, because its transactions use Attribute-Length-Value 3-tuples. New 3-tuples can be easily added without disturbing the protocol behaviour. [30]

When a client is configured to use RADIUS, the users of the client are supposed to present authentication information to the client. After this the client may choose to authenticate the user by sending an access request to the RADIUS server. If the server is unavailable the client may access another server. This request includes user's name, password, client id and port id. When the RADIUS server receives the request, it first validates the client. After this it checks the database and looks for the information matching the user name. This information concludes under which conditions the user is allowed to access the service. The server checks these conditions and the password. If it uses challenge responses, it may send an Access Challenge response to the client. If all conditions are met, the server sends an Access-Accept response to the client. This response includes all the configuration values for the user. [30]

RADIUS servers can act as proxy clients. This means that if the RADIUS server doesn't have the information it needs, it can contact another RADIUS server. This is typically used in roaming situations, where one RADIUS server receives the request from a NAS client and forwards it to another RADIUS server. [30]

RADIUS protocol is described in [30] and its extensions in [29,31].

4.2 DIAMETER

DIAMETER protocol design is based on the RADIUS protocol. It is designed to be used as the AAA protocol between ISPs and corporate networks [13]. DIAMETER is backward compatible with RADIUS. It is based on the use of AVPs (Attribute Value Pairs). AVPs consist of three main fields. They are AVP code, AVP length and data. The AVP code identifies what data this pair includes, AVP length defines the data field length and the value field contains the actual data. All the data is transmitted in this form. [13]

DIAMETER base protocol is never used as such. It just offers the minimum requirements for AAA transport protocol. It requires always the use of extensions that are application specific. There are extensions defined for Mobile IP [25], NASREQ [12], accounting and strong security. DIAMETER is a peer-to-peer protocol in the sense that any node can initiate a request. [13]

DIAMETER communication starts with one peer sending a request to another peer. Typically message sequences are of the request/reply type. Sometimes just a request maybe used. DIAMETER base protocol is concerned with the capabilities negotiation, how messages are sent and resent and how peers may be abandoned. [13]

DIAMETER supports two types of message routing methods: proxying and brokering. In proxying, the proxy server just forwards the message further to be processed. In brokering, brokers interact with the DIAMETER servers enabling them to communicate with each others directly. [13]

DIAMETER base protocol is defined in [13] and its extensions in [7,11].

4.3 ISAKMP/IKE

ISAKMP (Internet Security Association and Key Management Protocol) is a key exchange independent framework for authentication, SA (Security Association) management and establishment. It doesn't define the actual protocols to be used. [22]

A SA (Security Association) is a relationship between two or more entities that defines what kind of security services these entities use to exchange data securely. It also contains the information that is needed to use those security services. [22]

ISAKMP uses a two phase approach in establishing SAs. In the first phase the ISAKMP SA is established between the entities to protect the further negotiation traffic. In the second phase the ISAKMP SA is used to establish other security protocol SAs like IPSec. So the second phase is the actual reason why we use this protocol, because many security protocols cannot be started by themselves. One ISAKMP SA can be used to set up many security protocol SAs. This minimizes the overhead of the process, because costly authentications need not be done so often and the second phase can be more simple. The negotiation parties can change their roles within a ISAKMP SA, i.e., either one of the parties can initiate the second phase SA establishment. [22]

ISAKMP is specified in [22].

IKE (Internet Key Exchange) is one implementation of ISAKMP. It is used to negotiate and exchange keying material between entities in the Internet. For example IKE can be used to establish the IPsec security association. In IKE the Diffie-Hellman algorithm is used for the key exchange. [19]

IKE uses the same kind of two phase SA establishing as ISAKMP. In the first phase IKE SA is created and in the second phase keying information is changed and non IKE SAs are established. The first phase may take place in one of the two modes. One of these protects the identity and the other doesn't. [19]

More information about IKE can be found in [19]

4.4 SASL

Simple Authentication and Security Layer (SASL) is a way to add authentication support to connection based protocols. In order to use SASL, the protocol must include a command for identifying and authenticating the user to a server. The protocol may also include optional negotiation of a security layer for the subsequent protocol interactions.  The command contains argument that identifies the SASL mechanism to be used. The SASL mechanism name must be registered to IANA. If the server supports this mechanism, it initiates the authentication protocol exchange. This typically consists of changing challenge response pairs between the client and the server. These are specific to each protocol used. [23]

During the authentication protocol exchange the mechanism performs authentication, transmits an authentication identity and negotiates the use of a mechanism specific security layer. If a security layer is to be used, it is taken into use immediately and all the subsequent data exchanges are encrypted. [23]

SASL specification itself defines four different mechanisms. These are Kerberos 4 [10] mechanism, GSS-API [21] mechanism, S/Key [18] mechanism and external mechanism. You can use IPSec or TLS [15] as an external mechanism. [23]

SASL method is defined in [23].

4.5 PolicyMaker

Trust management is an approach to specify and interpret security policies, credentials and relationships. A trust management system provides a way to specify application security policies and credentials. It differs from the traditional certificate based system, because it binds keys directly to the authorization to do a specific action. In the certificate based systems keys are bind to the names. [9]

A trust management systems consist of five basic components. [9]

The trust management based approach has numerous advantages, when a security policy is decentralized or otherwise distributed into the network. It unifies the notions of a security policy, credentials, access control and authorization into one easily manageable suite. An application that utilizes the trust management system can simply ask from the compliance checker whether the action should be allowed or not. [9]

PolicyMaker is a trust management system. It is concerned with defining policies, credentials and trust relationships. PolicyMaker uses a "safe" programming language to define the trust relationships, credentials and policies. It is designed to be flexible enough to be used in large network applications and to integrate easily with the existing protocols. Each component makes decisions about whether to accept or not a certificate locally, i.e., they have local control. The mechanisms are separated from the policy, so that the certificate verification process can be the same in different kinds of applications and it doesn't depend on the certificates themselves. [8]

PolicyMaker differs significantly from the certificate based approaches.  In Policymaker certificates are not used to bind keys to an identity as in the traditional system like X.509. Certificates are rather used to bind public keys to the predicates that describe what actions they are authorized to sign. This way keys can be used directly to show that the requester is authorized to do the secure action. This is quite a useful feature in the actions that require anonymity such as voting. [8]

Trust relationships in Policymaker are more powerful and general than in the existing systems. The trust relationships and the referral of trust are defined by using a simple programming language. This makes it possible to use different kinds of trust hierarchies quite easily. Because Policymaker implements the trust management in a distinct software, it makes the application developer work easier, because he or she doesn't have to take care of the security inside the application. [8]

Policymaker appears to the user as a simple query based database. It takes as input credentials, local policy information and a string describing the trusted action that is requested. It evaluates the request according to credentials and the policy information and gives a simple yes/no answer or the details that are needed to be filled in order to make the action acceptable. [8]

Security policies and credentials are defined in filters. Filters associate public keys with security policies and credentials. A filter allows or disallows the execution of an action based on the permissions the corresponding private key owner has.   Trust maybe deferred, if the needed information is not available locally. Typically this means contacting some trusted third party to obtain the needed information. The deferral extent can be decided locally, i.e. , a maximum can be set to the number of de-referrals. [8]

Policymaker can be used with any signature and authentication schemes and policy notions, because it doesn't understand the format of the action string and it doesn't do the actual signature verification. It is the responsibility of the application to verify the signature and make the action string. The decision whether to reject or accept the action is done by the filter. [8]

PolicyMaker is defined in [8].

4.6 KeyNote2

Keynote is a simple and flexible trust management system that is designed for small and large internet based applications. It is fast enough to be used even in real time applications. It uses one easily human readable language to specify the policies and credentials. In Keynote actions are defined as a key-value pairs. A key-value pair list is created by the application. A principal can be a physical entity, a process, a public key or any other convenient abstraction. The principals are identified by the principal identifiers. The principals can do two types of things. They can request a trusted action or they can create an assertion, which is a delegation of trust to another principal. Applications use the compliance checker by issuing queries that include the action and the principals that are requesting the action. The compliance checker returns a compliance value that specifies how the request should be handled by the application. In a simple case this is a boolean value, but it can also be any one of the possible values. [9]

Assertions are the basic building blocks of specifying policies and delegating trust. Each assertion includes information about the principal who made it, which principals it authorizes and what they are allowed to do. There exists a special principal called the "Policy", who is the root of the assertion hierarchy. The "Policy" principal is authorized to do anything. [9]

If a principal is identified by a public key, then it can use this key to sign assertions. This way we can delegate authorization through untrusted network to other Keynote compliance checkers. Signed assertions are called credentials and they are similar to the traditional certificates in other systems. [9]

KeyNote2 is defined in [9].

5 AAA in combination with Mobile IP

This section describes the use of AAA systems in combination with Mobile IP. General description of Mobile IP is given and architecture of the Mobile IP AAA system is discussed.

5.1 General

Mobile IP is a protocol that is used to manage the mobility of an IP host between IP networks. The problem Mobile IP is trying to solve is that when a host is moving around and accessing the network, its IP address changes. This represents a problem, if we need to reach the host.

Mobile IP system consists of several network components. These are MN (Mobile Node), FA (Foreign Agent) and HA (Home Agent). MN is a host that is moving from one network to another and accessing the service. This could be, for example, a laptop computer with WLAN (Wireless LAN) connectivity. FAs and HAs constitute the network part of the system. HA redirects the packets that arrive to the MN's home network to the MN, so that the MN's IP address need not be changed. The redirection from the HA to the MN is implemented by using tunnels. FA is a network component that is between the tunnels and takes care of delivering the data to the MN. Typically there are several FAs within one administrative domain. FAs also make it possible to update the path to the MN more locally, when the MN is moving.

There are currently some freeware implementations of Mobile IP available for the Linux operating system. One such implementation is Dynamics - HUT Mobile IP [16]. Mobile IP is specified in [25]. Good introductions to Mobile IP can be found in [27,28].

The AAA functionality is needed, because in the Internet there is quite often a need to access resources in another administrative domain. In this case the FA needs to authenticate the MN before it can give the service to MN. Typically it asks for credentials that are used to authenticate the user. FA is not able to make the decision itself, so it needs to contact the local AAA server, which may give the answer or contact another server.

The purpose of the Mobile IP AAA according to [34] is to provide the following improvements to the basic Mobile IP protocol.

  1. Better scaling of security associations.
  2. Mobility across administrative domain boundaries.
  3. Dynamic assignment of Home Agent
The current design of Mobile IP, works well when working inside one administrative domain. But there is a need to improve the mobility across multiple administrative domains. This change will affect the current trust model of Mobile IP. AAA tries to implement these changes and make the Mobile IP system such that it scales well to multiple administrative domains. AAA also enables administrative domains to charge mobile nodes for the use of the network capacity. [34]

Mobile IP AAA requirements are described in [20].

5.2 Architecture

Mobile IP with AAA contains following components. Mobile Nodes, Foreign Agents, Home Agents, Foreign AAAs, Home AAAs and optionally Brokers. Foreign and home agents are described above.

Figure 6 illustrates the new trust model of Mobile IP with AAA. Arrows indicate that there exists a security association between the entities.

Initially Mobility Agents i.e. Foreign Agents and Home Agents share a security association with their local AAA. A Mobile Node shares a security association with the home AAA. The AAAs in different administrative domains can share a security association or if the Broker component is present then the AAAs share a security association with it. Sharing a security association between the AAA servers doesn't scale well to multiple domains, because each AAA server has to build a trust relationship to every other AAA. This is clearly not possible. The use of Brokers tries to solve this problem. Brokers are components, which mediate trust between the AAAs. If brokers are used the AAAs doesn't have to trust each others directly, because broker can take care of the trust mediation. [34]


Figure 6. Mobile IP AAA trust model [34]

In AAA each MN has a unique NAI [4] (Network Access Identifier). The NAI consists of a user part and a realm part. The realm part is a subnet identifier of the user's home domain. The realm part is used, for example, to find the home domain of the MN. The NAI is used to identify the particular MN in different network components. [34]

Let's take a look at an example where a MN is in a foreign network and initiates the communication. It sends a registration to the FA and the FA forwards this message to the local AAA, because the FA doesn't share a security association with MN's HA. The MN can't send the request directly to the HA because it doesn't have a network connection yet (it is actually requesting one to be initialized) and because of that it doesn't have an IP address. When the local AAA receives the registration it checks the MN NAI realm part to see whether the MN belongs to its own network. If it doesn't the AAA forwards it to the MN's home AAA, if they share a security association or to the broker, if brokers are present in the system. The home AAA authenticates the user and start the authorization phase. In the authorization phase session keys are distributed to the mobility agents. After this the AAA sends the initial request and the authorization information to the HA which processes the registration request and sends a reply back to AAA. The AAA forwards the message back to the MN using the same path which the registration used. [34]

In the authorization phase three session keys are made. [34]

  1. One that is shared between the MN and the HA.
  2. One that is shared between the MN and the FA
  3. One that is shared between the FA and the HA

Figure 7. Mobile IP AAA [34]

One important thing in the Mobile IP AAA design is the connection establishment time. The AAA protocol shouldn't make the connection establishment slow. Most of the time overhead comes from the time that is needed to change information between the AAAF and the AAAH. The data transfer between these components typically involves traversing the Internet. So there is clearly a need to minimize the number of such messages. This can be achieved, for example, by integrating Mobile IP registration and AAA functions. [34]

6 AAA in Ad Hoc networks

An Ad Hoc network is a dynamically changing multi-hop network that is created by the mobile nodes when needed for their own communication purposes [27]. Typically this could mean that two hosts want to change some data. In an ad hoc network mobile nodes come and go as they wish, so the topology of the network is changing quite rapidly. This creates new challenges for the protocols that are to be used in ad hoc networks. Most of the traditional protocols don't fit very well into ad hoc networks. An ad Hoc network is quite a new concept, so there doesn't exist any approved protocols, for example, for routing purposes.

An ad hoc network can be created in a number of ways. One solution is to run routing protocols in the mobile nodes. This approach requires careful attention, because the rate of change in an ad hoc network is quite rapid compared to the Internet, to which most of the current routing protocols are designed. Another approach would be to treat the ad hoc network as an incompletely connected physical medium. [27]

6.1 Threats and problems

There are several threats in ad hoc networks. Ad hoc networks use wireless data transmission. This makes them susceptible to passive eavesdropping, message replaying, message distortion and active impersonation.  Mobile nodes have low physical security. They can be easily compromised , for example, in the battlefield. This means that attacks can come also from inside the ad hoc network. Therefore we cannot trust one centralized node, because if this node would be compromised the whole network would be useless. One problem is scalability. Ad hoc networks can have hundreds or even thousands of mobile nodes. This possesses challenges to security mechanisms. [36]

6.2 Authentication

Some kind of  authentication is needed in ad hoc networks. Because an ad hoc network is open in the way that mobile hosts can come and go, there is no way for us to know, which mobile hosts are present in the network. If we are sending some data, for example, we want to be sure that we are communicating with the host we assume, not someone else who just happens to be present in the network.

One way to deal with low physical security and availability constraints is the distribution of trust. We can distribute the trust to a collection of nodes. If we think that it is unlikely that all t+1 nodes will be compromised, we can think that a consensus of t+1 nodes is trustworthy. [36]

In [36] a distributed key management service is described. In this (n, t+1) model there is not one CA (Certificate Authority) but many. There are n special nodes which act as servers. As long as at most t servers are compromised the scheme works.

This key management approach is based on the threshold cryptography. An (n, t+1) threshold cryptography scheme allows n parties to share the ability to perform a cryptographic operation, so that any t+1 parties can perform this operation jointly whereas it is infeasible for t parties to do so, even by collusion. [36]

In this key management service n servers share the ability to sign certificates. A (n, t+1) threshold cryptography scheme is used to make the service tolerate t compromised nodes. Service private key is divided to n shares, which are distributed to all servers. To sign a certificate each server signs the certificate with its share and transmits the certificate to a combiner. Combiner is able to sign the certificate if it gets t+1 correct partial signatures. Compromised servers are not able to sign certificates, because there is at most t of them at any time. [36]

After having built this kind key management system we can use public key cryptography to do the authentication.

6.3 Authorization

Authorization is also needed, because we don't want some malicious host to be able to wreak havoc inside the network. This can be prevented by keeping control of what hosts are allowed to do inside the ad hoc network. Authorization also needs some sort of distributed structure, because we cannot rely on one point of failure. This is why the traditional way of using access control lists (ACL) in one central server isn't adequate in ad hoc networks.

6.4 Accounting

Accounting features are quite specialized in ad hoc networks. Because basically there is no network infrastructure that is providing the service, there isn't either the same kind of service provider concept as in traditional networks. In ad hoc networks individual mobile hosts are providing service to each others.  There can be two kind of situations in the charging point of view. One is the kind of a situation in which there is no need to use charging. In this situation all the hosts have decided together that they want to form an ad hoc network for their own need to communicate with each other. This could mean that they all belong to the same organization like in the case of military units or that they are in the same place and want to communicate like in the case of meetings. So we can consider this kind of ad hoc network as a kind of intranet.  In the other kind of situation individual mobile nodes are just participating in the network to communicate with some of the other nodes not all. In this situation, if some mobile node acts as a router in the network, providing connectivity between two nodes that are not within each others range, then it would be reasonable to charge some money for this service.

Accounting in ad hoc networks hasn't been studied very much yet. So there exists no protocols to do the actual charging if that is needed.  This area is however quite interesting, because it is faced with question like how individual mobile nodes can charge each others? Because we cannot assume connectivity to some central server that takes care of the charging there is a clear need for distributed charging protocols as well.

6.5 AAA systems

When we think about the ad hoc networks and general AAA systems, we can quite easily see that they don't fit well together. The biggest problem is related to the varying nature of the network. There are no home domains or foreign domains, because the networks come and go on demand. Also the term service provider will have a different meaning than before. This does affect the AAA systems, that the AAA working group is presenting, because some of the basic building blocks of their architecture are missing from the ad hoc networks.

The basic problem here is that the model provided by the AAA working group is a centralized trust model. This clearly doesn't  fit well into ad hoc networks, because the network structure is decentralized in those. We need some other kinds of methods to achieve the AAA functionality.

One approach to provide authentication and authorization functionality in ad hoc networks could be to use trust management based approaches like PolicyMaker or Keynote2. These are decentralized by nature and can provide the requested functionality in ad hoc networks quite easily. The use of trust management systems would have also other benefits, that are described in section 4.

Also other protocols like SASL or ISAKMP/IKE could be used to provide the authentication functionality.

7 Conclusions

Building a general purpose AAA framework is not an easy task as we have seen. There is still a lot of development needed, before we can see some general purpose AAA protocols approved. The only real AAA protocols RADIUS and DIAMETER that are currently available are made for specific purposes and provide the AAA functionality in their extensions. There exists however a number of separate protocols to achieve the separate functionality. The AAA working group approach is focused on developing centralized trust model, but there are also other kind of trust models available that should not be forgotten.

In ad hoc networks we are faced with completely different kind of service paradigm. This change affects the whole AAA concept, which is designed for traditional kind of networking. Authentication, authorization and accounting all have new problems to be solved in ad hoc networks.

In ad hoc networks we probably need decentralized models like Policymaker or Keynote2 or some other approaches to provide the AAA functionality. Ad hoc networks are quite new area, so there are no protocols available to achieve this functionality. However, in the near future there will have to be some solutions for these issues also, if ad hoc networks are really being used.

References

[1] IETF's AAA working group. 
< http://www.ietf.org/html.charters/aaa-charter.html >
[2] AAAARCH AAA architecture research group.
< http://www.phys.uu.nl/~wwwfi/aaaarch/charter.html  >
[3] Aboda, B. & Arkko, J. & Harrington, D., Introduction to Accounting Management, Internet draft (work in progress), January 2000. 
< http://www.ietf.org/internet-drafts/draft-ietf-aaa-acct-00.txt >
[4] Aboda, B. & al., The Network Access Identifier, RFC 2486, January 1999.
< http://www.ietf.org/rfc/rfc2486.txt >
[5] Amoroso, E., Fundamentals of Computer Security Technology, Prentice Hall, 1994.
[6] Arkko, J., Requirements for Internet-Scale Accounting Management, Internet draft (expired), August 1998. 
< http://www.ietf.org/internet-drafts/draft-arkko-acctreqlis-00.txt >
[7] Arkko, J. & Calhoun, P. R. & Patel, P. & Glen, Z., DIAMETER Accounting Extension, Internet draft (work in progress), December 1999. 
< http://www.ietf.org/internet-drafts/draft-calhoun-diameter-accounting-03.txt >
[8] Blaze, M. & Feigenbaum, J. & Lacy J. , Decentralized trust management, May 1996. 
[9] Blaze, M. & Feigenbaum, J. & Ioannidis, J. & Keromytis, A. ,The KeyNote Trust-Management System Version 2, RFC 2704, September 1999. 
< http://www.ietf.org/rfc/rfc2704.txt
[10] Borman, D., Telnet Authentication: Kerberos Version 4, January 1993. 
< http://www.ietf.org/rfc/rfc1460 >
[11] Calhoun, P. R. & Bulley, W., DIAMETER User Authentication Extensions, Internet draft (work in  progress), October 1999. 
< http://www.ietf.org/internet-drafts/draft-calhoun-diameter-authent-08.txt >
[12] Calhoun, P. & Bulley, W.,  DIAMETER NASREQ Extension, Internet draft (work in progress), December 1999. 
< http://www.ietf.org/internet-drafts/draft-calhoun-diameter-nasreq-00.txt
[13] Calhoun, P. R. & Rubens, A. C. & Akhtar, A. & Guttman, E., DIAMETER Base Protocol, Internet draft (work in progress),  December 1999. 
< http://www.ietf.org/internet-drafts/draft-calhoun-diameter-12.txt >
[14] de Laat, C. & Gross, G. & Gommans, L. & Vollbrecht, J. & Spence, C., Generic AAA architecture, Internet Draft (work in progress), January 2000. 
< http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-generic-00.txt
[15] Dierk, T. & Allen, C., The TLS Protocol Version 1.0, January 1999. 
< http://www.ietf.org/rfc/rfc2246.txt >
[16] Dynamics - HUT Mobile IP
< http://www.cs.hut.fi/Research/Dynamics/ >
[17] Farrell, S. & Vollbrecht, J. & Gommans, L. & Gross, G., AAA Authorization Requirements, Internet draft (work in progress), October 1999. 
< http://www.ietf.org/internet-drafts/draft-ietf-aaa-authorization-reqs-01.txt >
[18] Haller, N., The S/KEY One-Time Password System, RFC 1760, February 1995. 
< http://www.ietf.org/rfc/rfc1760.txt >
[19] Harkins, D. & Carrel, D., The Internet Key Exchange(IKE), RFC 2409, November 1998.
< http://www.ietf.org/rfc/rfc2409.txt >
[20] Glass, S. & Hiller, T. & Jacobs, S. & Perkins, C. , Mobile IP Authentication, Authorization, and Accounting Requirements, Internet draft (work in progress), 11.2.2000. 
< http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-reqs-01.txt 
[21] Linn, J., Generic Security Service Application Program Interface, RFC 1508, September 1993. 
< http://www.ietf.org/rfc/rfc1508.txt >
[22] Maughan, D. & Schertler, M. & Schneider,M. & Turner, J.,  Internet Security Association and Key Management Protocol (ISAKMP), RFC 2048, 
< http://www.ietf.org/rfc/rfc2408.txt >
[23] Myers, J., Simple Authentication and Security Layer (SASL), RFC 2222, October 1997. 
< http://www.ietf.org/rfc/rfc2222.txt >
[24] Nikander, P., An Architecture for Authorization and Delegation in Distributed Object-Oriented Agent Systems, Ph.D. Dissertation, Helsinki University of Technology, March 1999. 
< http://www.tcm.hut.fi/~pnr/publications/PhDThesis.pdf >
[25] Perkins, C. E., IP Mobility Support, RFC 2002, October 1996. 
< http://www.ietf.org/rfc/rfc2002.txt >
[26] Perkins, C. E., Mobile Ad Hoc Networking Terminology, Internet draft (expired), 17th of November 1998. 
<http://www.ctron.com/support/internet/Internet-Drafts/draft-ietf-manet-term-01.txt >
[27] Perkins, C. E., Mobile networking in the Internet, Mobile Networks and Applications, 1998. 
<http://www.baltzer.nl/monet/articlesfree/1998/3-4/mnt071.pdf >
[28] Perkins, C. E., Mobile networking through Mobile IP, IEEE Internet Computing, Jan.-Feb. 1998.
[29] Rigney, C., RADIUS Accounting,  Internet draft (work in progress),  February 2000. 
http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-04.txt >
[30] Rigney, C. & Rubens, A. & Simpson, W. & Willens, S., Remote Authentication Dial In User Service (RADIUS), Internet draft (work in progress), February 2000. 
http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-06.txt >
[31] Rigney, C., Willats, W., Calhoun, P., RADIUS Extensions,  Internet draft (work in progress), February 2000. 
< http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-06.txt >
[32] Schneier, B., Applied Cryptography, 2nd edition, 1996. 
[33] Stajano, F. & Anderson, R., The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks, May 20th 1999.
< http://www.cl.cam.ac.uk/~fms27/duckling/ >
[34] Vollbrecht, J. & Calhoun, P. & al., AAA Authorization Application Examples, Internet draft (work in progress), October 1999. 
< http://www.ietf.org/internet-drafts/draft-ietf-aaa-authz-samp-00.txt >
[35] Vollbrecht, J. & Calhoun, P. & al., AAA Authorization Framework, Internet draft (work in progress), October 1999. 
< http://www.ietf.org/internet-drafts/draft-ietf-aaa-authz-arch-00.txt >
[36] Zhou, L. & Haas, Z., Securing Ad Hoc Networks, 1998.
< http://www.ee.cornell.edu/~haas/Publications/network99.ps >