Distributed AAA: Proposals for Ad Hoc Networks

Transcription

1 Distributed AAA: Proposals for Ad Hoc Networks Pradip Lamsal Department of Computer Science University of Helsinki, Finland ABSTRACT AAA frameworks such as diameter protocol allows applications to define their own authentication and authorization mechanisms while the base protocol takes care of general accounting. This framework has been used by a couple of applications such as access application and mobile IP application. Both these applications have at least one thing in common: access to the fixed infrastructure. Networks with fixed infrastructure can afford to dedicate a element for AAA. Implementing AAA functionality in ad hoc s is a different challenge. The main reason is the lack of fixed infrastructure. In an ad hoc, the terminal devices themselves become the infrastructure and this infrastructure is not fixed. In this paper, we explore some options of using AAA in ad hoc s. The proposals presented here are still at conceptual level and require more work to make them feasible. KEYWORDS: ad hoc, AAA 1. INTRODUCTION For the most of the twentieth century the telecommunications technology was limited to wire line telephony systems. Since the start of the 90s mobile phones have become widespread and this started changing the telecommunications topology. In this new topology, the infrastructure remained fixed while the terminal devices became mobile. An ad hoc [3] is a different type of, where both the terminal devices and the infrastructure are mobile. All the devices in an ad hoc have to work both as a terminal device and a part of the infrastructure. The ad hoc can be formed randomly by two or more devices and any device can enter and leave the at their own will. With the advancement of telecommunications technology the issues associated with it have also advanced. One of the fundamental issues in the telecommunications domain is security: security of both the infrastructure (including terminal devices) and information it carries. With the potential merger of telecommunications and ing technologies the issue of security becomes even more important. The combined can now potentially carry from not-soimportant chat between friends to highly sensitive financial data and military secrets. The security issues that exist in wire line telecommunications are heightened in the wireless telecommunications (only terminal devices mobile) because of the vulnerability of wireless links between the terminal devices and the fixed infrastructure. In ad hoc s, this vulnerability of wireless links becomes more serious due to the very nature of ad hoc topology. Here, all devices are wirelessly linked to each other and each of them are equally prone to all the wireless security threats, including physical theft of the devices. There has been a lot of work done to solve different security problems. A lot of research has resulted in several security solutions, which address different security problems. One aspect of security is to make the perimeter of the too secure for outsiders to enter. In order to achieve this, it is essential to have a proper authentication mechanism and when authenticated, the user should be given an appropriate level of authorization in terms of what he can and cannot do in the. One of the solutions that has been used in s nowadays is Authentication, Authorization and Accounting (AAA) [2] framework. So far, the use of AAA is limited to s with fixed infrastructure, where a separate is dedicated to perform authentication and authorization tasks on behalf of the. Porting AAA in ad hoc s is still a challenge. In this paper, we present some ideas for using AAA in ad hoc s. The rest of the paper is organized as follows: Section 2 contains a short introduction to AAA, section 3 contains our proposals, section 4 contains protocol-related aspects and section 5 contains some other relevant areas of the models. 2. AAA OVERVIEW AAA is a framework that enables authentication and authorization of a user accessing a and also allows for collection of accounting information. When a user wants to access a, it sends a request for access to the AAA. The AAA protocol does not specify the protocol between the user and the AAA. Once the AAA receives such a request it sends an AAA request to the AAA on behalf of the user. The AAA authenticates 1

2 the user by evaluating the request and then responds the AAA with proper authorization. The AAA is also capable of querying the AAA for accounting information. The AAA framework consists of three fundamental components: AAA, Application Specific Modules (ASMs) and Repository. This is shown in figure 1. proposed models include a brief overview of the model, lifecycle of the devices inside the and trust relationship among the devices. 3.1 Definitions Before we start with our proposals we would like to define a few terms, which we will use to describe a device. From a different perspective, these terms can also mean different states of a device. This is illustrated in figure 2. user AAA Client AAA Server mobile device ASM Repository mobile device directory agent Server boundary Figure 1: AAA Architecture The generic AAA has rules to evaluate the request and to make decisions about authentication and authorization. However, this is generic and the requests are so application specific that the delegates these requests to the ASMs. All the events are logged in the policy and event repository. This repository can be used to evaluate further requests and to access accounting information for a specific user. An example of the AAA framework is the diameter [5] base protocol. This base protocol provides the basic framework and is supplemented by AAA Transport Profile [1] and AAA Applications [4, 6]. The transport profile addresses the transport issues whereas the applications address the applicationspecific issues. The base protocol, as it is, can only be used for accounting. For authentication and authorization the base protocol must be extended for a particular application. A diameter must support the base protocol and any one application-specific protocol whereas any diameter must support both the base protocol and all the application-specific protocols. Without supporting all the application-specific protocols the is unable to provide services for those applications. 3. AAA IN AD HOC NETWORKS In ad hoc s, the idea of a centralized does not fit into the paradigm. Any can come into the and leave the at any time. Even inside an ad hoc, s can move from one point to another, constantly making and breaking connections with different other s. The use of AAA in an ad hoc is still confined to research communities. In this section we attempt to propose our own ideas of how AAA can be used in ad hoc s. This is our first attempt and is therefore bound to have a lot of open issues. These proposals are made from the perspective of what can be done rather than how to do it. All the Figure 2: Device States 1 Mobile Device: This is a generic term used to refer to a device that is mobile. This could be a device outside a or a part of any. 2 Client: This is a, which is trying to access an ad hoc. When a tries to access an ad hoc, the becomes a during that duration when it is sending access requests and receiving access replies. A is not a part of the. 3 Network Mobile Device: When a gains access to an ad hoc the becomes a. A is a part of the. 4 Server: A is a, which the s contact to request access to the. A sees the as the interface to the. 5 Directory Agent: A directory agent is a which is capable of responding to a directory access request. 3.2 Elected Server Model Overview This model has the notion of centralized. It consists of a primary and a secondary. The secondary takes over when the primary is out of action. The s are elected by the s. The s can employ any mechanism to elect the s. One simple selection mechanism is to elect the oldest to be the primary and the second oldest to be the secondary. All s interact with the primary to request for access. 2

3 primary second ary Life-cycle A goes through different states during its lifetime in an ad hoc. As shown in 4, when a mobile device tries to access an ad hoc by sending a request it becomes a. It stays as a during the negotiation. Only s can request for access. If the request is accepted, the becomes a part of the and hence it changes its state from to mobile device. If the s request gets rejected by the or the itself abandons the request, it goes back to mobile device state. Figure 3: Elected Server Model: Conceptual View The conceptual view of the elected model is shown in 3. In this model, both the primary and the secondary must have full AAA functionality. When the primary leaves the gracefully, the primary informs the secondary that it is leaving. The secondary then takes over as the primary and holds an election to select a new secondary. If the secondary leaves gracefully, the primary holds an election to select a new secondary. The scenario is a bit different if one or both of the s disappear. A disappearing does not inform anyone else that it is leaving the. When this happens, one of the mobile devices has to act as a temporary and then call for an election to select the primary. This primary then selects a secondary by holding a new election. Therefore, all the s have to monitor the s continuously. There are two types of monitoring. i The primary and the secondary must monitor each other very closely. This means detecting each other s existence frequently so that a loss is detected immediately. This can be achieved by both s sending bi-directional (request - response) messages at a high rate. ii All the s must monitor the primary at a low frequency. This can be achieved by making the primary or both primary and secondary s send unidirectional alive message at a low rate. This will enable all the s to detect the loss of s. Once a detects that the has lost both s, it can claim itself as the temporary and send a request for approval. If other mobile devices approve the request, the requester can act as the temporary and hold an election to select the primary. If other s also detect the loss of s and they have not already received an approval request from another, they can also claim themselves as temporary s and ask the for approval. If a receives more than one approval request, it must approve the first one and reject the rest. If a leaves the, it becomes a again. After going back to the state, if it wants to rejoin the then it has to become a first and then perform the negotiation as earlier. If a gets elected by other mobile devices to act as the, its state changes to. Both primary and secondary s have the same state. If the, for some reason, decides to remove the from its responsibility then the goes back to state. Similarly, if the leaves the, it becomes a again. All the s should be able to respond to a directory access request thus making all the mobile devices directory agents. leave request for access request rejected or request abandoned withdrawn from role win election request accepted Figure 4: Elected Server Model: Life-cycle The same life-cycle can be viewed from a different perspective. Instead of looking at different states of the same mobile device, the life-cycle can be viewed as three distinct phases. Phase 1 is the access phase, where a becomes a and sends access requests to the. In phase 2, the is already inside the ad hoc. In other words, it is not longer a but a. The could also be a in this phase. In phase 3 the mobile device leaves the. It can either leave gracefully or simply disappear. Trust Model The trust model of an ad hoc is better illustrated by looking at individual s trust relationship with other s during its life-cycle. In phase 1, a is either a standalone or is a. If it is a, it is trying to get access to the. In this phase, it is trying to establish a trust 3

4 relationship with the. So, there is no proper trust relationship in phase 1. When the device is in phase 2, it has already become a. Once it gains access to the, it develops complete trust with all other s. This trust is non-hierarchical. When the is in phase 3, it is in the process of breaking all the trust it maintained with other s within the. When it goes back to being a, it no longer maintains any trust with the. 3.3 All Server Model Overview This model does not have the notion of a single working for the whole ad hoc. All the s become the when they become a part of the. The consists of only the s and each of them is working only on its own behalf. The scope of the access provided by a is limited to the itself. This is illustrated in figure 5. request for access request rejected or request abandoned mobile device = request accepted Figure 6: All Server Model: Life-cycle the becomes the and tries to access the. In phase 2, the is already inside the and is in or state. In phase 3, the leaves the and goes back to state. There is not much distinction between leaving gracefully or disappearing. In an all model, it is possible for a to act both as a and a at the same time. This is because of the fact that this is more like a peer-topeer connection. A becomes a when it has access to at least one. If that then tries to access another then that is acting as a for the second. Figure 5: All Server Model: Conceptual View In this model the AAA functionality must exist in all the s. A can request any and that should be able to handle such request appropriately. In essence, this model is more like a peer-to-peer model. Life-cycle A goes through different states during its lifecycle as shown in figure 6. When a tries to access the by sending a request, it becomes a. It stays as a during the negotiation. If the request gets accepted by the, the becomes a mobile device. However, if the request gets rejected or if the abandons its request then it goes back to state. In this model, all the s immediately become the and therefore this model does not require support for directory access requests. The s know that all the s are s. When the leaves the, it becomes a mobile device again. After going back to the state, if it wants to rejoin the, the has to do the negotiation again. Similar to the elected model, the life-cycle of a mobile device consists of three different phases. In phase 1, Trust Model Like in the elected model, the trust relationship within the ad hoc is different in different phases. In phase 1, the is trying to establish trust with the, so, there is no working trust relationship between the and the. In phase 2, the s have complete trust among each other. This trust is peer-topeer, meaning the trust relationship exists only between the devices who negotiated for the access earlier. When the is in phase 3, it is in the process of breaking the existing trust. When the trust is broken, the becomes a. 3.4 Group Server Model Overview In this model, any can become a and the makes the decision on behalf of the whole. The does not make the decision itself. Instead, it delegates the request to other mobile devices and collects the responses. Based on the responses from other s, the makes the decision whether it can accept the or not. For instance, out of M (=m+n) s the can delegate a request to any m s and collect the responses from all of them to make the decision. Alternatively, the can send the request to all M s but consider responses from m devices to make the decision. This is illustrated in figure 7. This approach is based on threshold cryptography [7]. 4

5 leaves the and the state changes to. Figure 7: Group Server Model: Conceptual View In theory, a can get several different requests from different s. These requests can come at the same time or separately. There is no specific AAA task allocated to specific s. Therefore, in order to handle any request at any time, all mobile devices should be equipped with full AAA functionality. Life-cycle A goes through different states during its lifecycle. When a tries to access the, it becomes a. If this request gets accepted, it becomes a. However, if the request gets rejected or the abandons the request, the goes back to the state. If a receives a request from a it changes its state to and when the negotiation finishes, it goes back to mobile device state. If the or the leaves the, its state changes back to. In terms of life-cycle and state change there is no distinction between leaving gracefully and disappearing from the. This is shown in figure 8. request for access request rejected or request abandoned no request request received request accepted Figure 8: Group Server Model: Life-cycle The life-cycle of this model also consists of three phases. In phase 1, a becomes a and it tries to access the by sending access requests. In phase 2, the becomes a part of the ad hoc and changes its state to. This phase also covers the transition from to state and vice versa. In phase 3, the Trust Model The trust relationship among s in this model is quite similar to the elected model. In phase 1, the is trying to establish trust with the. The negotiation is performed with the. In phase 2, the becomes a part of the and therefore has complete trust with the. The complete trust also exists between the newly accepted and those n s, which did not respond to the request delegated by the. This means that once a becomes a, it automatically has complete trust with all the s in the ad hoc. In phase 3, any existing trust is broken when the no longer becomes a part of the. 4. PROTOCOL 4.1 Connectivity Connectivity is essential for any protocol to work. In any of our models, we do not have any automatic connectivity among s. The characteristics of ad hoc come into play when we talk about connectivity. All the s, which are capable of being a part of ad hoc, must be able to send and receive signals for ad hoc connectivity. Our models assume that connectivity of the devices is not an issue here. We assume that any device is capable of detecting another device within the range. So, our work starts after the devices have detected each other s signals and about to do negotiation for access. 4.2 Formation of an Ad Hoc Network Let us take a very simple example of two s A and B setting up a new ad hoc. 1 A is at a certain location, capable of starting up an ad hoc. 2 B come to the area, scans to find out whether there is another device in the area with which B can set up an ad hoc. 3 B detects the presence of A. Since B is the one who is scanning for another device, B assumes that A is a. B then sends a access request by changing its state from to. 4 At this stage, A is also in state. It knows that it is not a part of any and since it received a access from another, it understands that it is starting up a new ad hoc. 5 A now sends a similar request to B. 6 B received the access request from the same it earlier sent the same access request. B now understands that it is setting up a new ad hoc. 7 Both A and B get access from each other and change their states to s. Here, both s are acting as a and a at the same time. This occurs only at the stage of starting up a new ad hoc. 5

6 8 Once a has been set up, a secret session key is distributed among the s as a token of trust. After this stage, a new can access the by following the protocol used by the model used in the. By model, we mean one of the models we have described earlier in this paper. 4.3 Use of Diameter The use of AAA in an ad hoc, as we have proposed in this paper, is considered as a separate application similar to [4] and [6]. We call this ab ad hoc access application and the protocol associated with this application ad hoc access application protocol (AHAAP). An ad hoc access application runs on top of a diameter base protocol and provides authentication and authorization services to the s. The accounting aspect of AAA is taken care of by the diameter base protocol. The implication of using the diameter base protocol is that AHAAP messages are embedded inside the diameter base AVPs. This new application requires a new application identifier. Specific details of an ad hoc access message are considered as a part of detailed protocol development and are currently not included in this paper. 4.4 Message Types The messages required to implement all these models are quite similar to each other with some differences. The messaging can be categorized into two groups: external messaging and internal messaging. External messaging consists of messages that a and a use to negotiate access. Internal messaging consists of messages that any two s use during access or at any other time. There are some messages which can be used in both external and internal messaging. All the messages these models require are listed in table 1. More messages will be required when the protocol is developed in detail. 5. MISCELLANEOUS 5.1 Trust Cache Earlier we briefly described a trust model for each of our proposed models. However, we did not mention how to establish trust and how to maintain it once it is established. In all our proposals, the trust model was quite simple. The s either had trust or they did not. When they had trust, it was complete trust among all the mobile devices. Both in the elected model and the group model, complete trust is with the whole, ie, with all other s. However, in the all model, complete trust is only with those s which authenticated and authorized the. It is essential for all the s to store trust locally. A can store trust as a triplet: trust{resource, access, trust value} per. The resource is a specific resource the is aiming to use, access is the type of access the wants for that resource (for instance, read access or write access or both) and the trust value is the s perceived value of trustworthiness of the. The trust value can be calculated in a variety of ways and can either be a quantified value or an abstract description. A simple quantification is to give it a value from 0 to 5, 0 indicating no trust at all and 5 indicating complete trust. When a wants to access a particular or all resources of a, the can refer to this trust value as a part of its acceptance policy. In the elected model, the maintains a view of the trust cache. This view of the trust cache is deducted from the trust cache of individual s. All the s can send their trust cache to the in the register response message. In the all model, individual devices use their own trust cache. In the group model, the s use their trust cache while responding to the s request. This trust cache can be sent to the in the evaluate access response message. 5.2 Storing Accounting Information The accounting information is stored locally on individual s. Only the has the up-to-date information of its resource usage. When accounting information is required, individual devices have to be contacted. This can be achieved using standard the diameter base protocol. So, in theory, accounting is not within the scope of AHAAP. 5.3 Acceptance Policy All the three models have the same acceptance policy at the conceptual level. The acceptance policy of any mobile device is a function of three variables, as shown in equation 1. acceptance policy : f(trust history, access request, device status) (1) Trust history is what the has in its trust cache. The access request is what the has requested in its net access request message for this session. The evaluates the s access request against the trust it has maintained in the trust cache. The device status is a term used to refer to how the feels at that time. All the mobile devices have the right to reject any access request at any time. For instance, the might reserve a particular resource for some urgent need in the future and therefore might not want anyone else to use it at the time of the request. The actual function used in this acceptance policy is open. Networks can use their own function to evaluate the situation and make acceptance policy as they require. 6. CONCLUDING REMARKS The models we have proposed in this paper provide a good base for further work in a number of areas. The next step would be to work on AHAAP and try to integrate it with the diameter base protocol. The mechanism for connectivity of the s to form an ad hoc should already be available in the manet working group of Internet Engineering Task Force (IETF). Some aspects of mobile 6

7 Messages Elected Server All Server Group Server Internal/External get request Y es No No External get response Y es No No External net access request Y es Y es Y es External net access response Y es Y es Y es External election request Y es No No Internal election response Y es No No Internal register request Y es No No Internal register response Y es No No Internal claim temp request Y es No No Internal claim temp response Y es No No Internal evaluate access request No No Y es Internal evaluate access response No No Y es Internal abandon last request Y es Y es Y es Both abandon last response Y es Y es Y es Both Table 1: AHAAP Message Types devices such as available memory, computational power requirements and battery life become issues in our case since we are making those s do more work. But, these are fundamental issues of s and are considered by other research organizations. Within the scope of this paper, some areas where we can do more work are: mechanisms for selecting a temporary in the event of a contention, dynamic trust model in phase 2 of the lifecycle, mechanisms for quantifying trust, proper definition of perimeter in case of the all model, robust acceptance policy etc. We will look at some of these issues in our next phase of work while we continue to refine some of the concepts introduced in this paper. This will be quite important in porting this conceptual proposal into a working solution. 7. REFERENCES [1] B. Aboba and J. Wood. AAA transport profile, RFC IETF Internet Working Group, June [2] L. G. J. R. v. Cees T.A.M. de Laat, George M. Gross and D. W. Spence. Generic AAA architecture, RFC IETF Internet Working Group, August [3] S. Corson and J. Macker. Mobile ad hoc ing (manet): Routing protocol performance issues and evaluation considerations, RFC IETF Internet Working Group, January [4] D. S. Pat R. Calhoun, Glen Zorn and D. Mitton. Diameter access application, IETF draft. IETF Internet Working Group, June [5] J. A. E. G. Pat R. Calhoun, John Loughney and G. Zorn. Diameter base protocol, RFC IETF Internet Working Group, September [6] T. J. Pat R. Calhoun and C. Perkins. Diameter mobile IP application, IETF draft. IETF Internet Working Group, April [7] L. Zhou and Z. J. Haas. Security ad hoc s. IEEE Networks, 13(6):24 30, November/December