AAA and PKI in Ad Hoc Networks

Transcription

1 AAA and PKI in Ad Hoc Networks Pradip Lamsal Helsinki University of Technology Telecommunications Software and Multimedia Laboratory Abstract Both AAA and PKI are frameworks that address security concerns in a network. AAA provides a mechanism for authentication, authorization and accounting whereas PKI provides a mechanism for managing cryptographic keys. The use of these frameworks is limited mainly to networks with fixed infrastructure. Their use in networks with no fixed infrastructure (or ad hoc networks) is still a research topic. In this paper we propose some ideas for using these technologies in ad hoc networking environment. The ideas that we propose here are still at the conceptual level and require more work to make them feasible. KEYWORDS: ad hoc networks, PKI, AAA 1 Introduction For the most of the twentieth century the telcommunications technology was limited to wire line telephony system. Since the start of the 90s mobile phones have become widespread and this started changing the telecommunications network topology. In this mobile communications only the terminal devices are mobile, the infrastructure remains fixed. An ad hoc netwok [3] employs a different networking topology, where both the terminal devices and the infrastructure are mobile. In order words, all the devices involved in an ad hoc network have to work both as a terminal device and a part of the infrastructure. The ad hoc network can be formed randomly by two or more devices and any device can enter and leave the network at their own will. With the advancement of telecommunications technology the issues associated with it have also advanced. One of the fundamental issues in telecommunications domain is security: security of both the infrastructure (including terminal devices) and information it carries. With the potential merger of telecommunications and networking technologies the issue of security becomes even more important. The same network can now potentially carry notso-important chat between friends to highly sensitive financial data and military secrets, in some cases. The security issues that exist in wire line telecommunications are hightened 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 networks, this vulnerability of wireless links becomes more serious due to the nature of ad 1

2 hoc network topology. 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 have been a lot of work done to solve a wide variety of security problems. A lot of research have resulted in several security solutions, which address different security problems. There are two solutions that we would like to mention here: Authentication, Authorization and Accounting (AAA) [5] and Public Key Infrastructure (PKI) [4]. AAA is a framework which enables collection of authentication, authorization and accounting data to a centralized server. PKI, on the other hand is a framework, which allows proper management of cryptographic keys. At the moment the widespread use of these two security solutions is limited to networks with fixed infrastructure, where a centralized device is readily available or can be allocated to act as an AAA or a PKI server. It is still unsure whether these frameworks can be ported to ad hoc networks with no fixed infrastructure. In this paper, we present some design proposals to use AAA and PKI in ad hoc networks. The rest of the paper is organized as follows: Section 2 contains our perception of network topologies, seciton 3 contains a short introduction to AAA and PKI, section 4 and section 5 have short description of these technologies in different types of networks and in section 6 we propose our solution. 2 Network Topologies In order to understand why ad hoc networks pose difficulties in using AAA and PKI we need to understand the topology of ad hoc networks and how ad hoc networks differ from other networks. In this section we look at the network topologies. We divide networks into three different categories. 1 Fixed Infrastructure Network: In a fixed infrastructure network topology, the infrastructure is fixed and the terminal device can be either fixed or mobile. The wireline telephony system, mobile telecommunications such as GSM, UMTS, and mobile IP are some examples of fixed infrastructure networks. 2 Ad Hoc Network: In an ad hoc network, there is no fixed infrastructure at all. All the devices are mobile and they can all be terminal devices. A nework is formed when two or more devices form a connection. 3 Semi Ad Hoc Network: A semi ad hoc network consists of two subnetworks: an ad hoc subnetwork and a fixed subnetwork. The ad hoc subnetwork is connected to the edge of the fixed subnetwork. For instance, Wi-Fi [2] is an example of semi ad hoc network because it consists of an ad hoc subnetwork and a fixed subnetwork. The ad hoc subnetwork accessess the fixed subnetwork via an access point. 3 AAA and PKI In this section we describe the fundamental principles of AAA and PKI and explain how these technologies are used in conventional wireline communications. 2

3 3.1 AAA AAA is a framework that enables authentication and authorization of a user accessing a network and also allows for collection of accounting information. When a user wants to access a network, it sends a request for access to the AAA client. AAA protocol does not specify the protocol between the user and the AAA client. Once the AAA client receives such a request it sends an AAA request to the AAA server on behalf of the user. The AAA server authenticates the user by evaluating the request and responds the AAA client with proper authorization. The AAA server is also capable of querying the AAA client for accounting information. AAA framework consists of three fundamental compoments: AAA server, Application Specific Modules (ASMs) and Repository. This is shown in figure 1. Client AAA Server AAA server ASM Repository Figure 1: AAA Architecture The generic AAA server has rules to evaluate the request and to make decisions about authentication and authorization. However, this server is generic and the requests are so application specific that the server 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 specfic user. An exmaple of AAA framework is diameter [9] base protocol. This base protocol provides the basic framework and is supplemented by AAA Transport Profile [1] and AAA Applications [7, 8]. The transport profile addresses the transport issues whereas the applications address the application specific issues. The base protocol, as it is, can only be used for accounting whereas for authentication and authorization the base protocol must be extended for a particular application. A diameter client must support the base protocol and any one application specific protocol whereas any diameter server must support both the base protocol and all the application specific protocols. Without supporting all the application specific protocols the server is unable to provide services for those applications. 3.2 PKI PKI is a framework that is aimed at supporting the management of public keys. A public key and its corresponding private key are used to encrypt and decrypt messages. The public 3

4 key is generally available in public whereas the private key is owned (or at least assumed to be owned) only by the real owner. PKI uses certificates to distribute public keys. A certificate maps a person s identity to his public key. Trust is a very important aspect of PKI. When someone uses a public key they have to trust the Certificate Agency (CA) issuing that public key or the certificate containing that public key. There are two types of trust models used in PKI frameworks: hierarchical trust model and web-of-trust trust model. ITU s X.509 [4] is based on hierarchical trust model and Pretty Good Privacy (PGP) [11] is based on web-of-trust trust model. Detailed information on the PKI trust models can be found in [6]. 4 AAA and PKI in Fixed Infrastructure Networks Both in AAA and PKI, it is assumed that a centralized server handles the core functionality. In networks with fixed infrastructure it is feasible to dedicate a seperate server to handle this functionality. A lot of networks already have PKI framework in place. Adding AAA framework is not that technically challenging. 5 AAA and PKI in Semi Ad Hoc Networks From the perspective of AAA and PKI semi ad hoc networks are more or less very similar to the networks with fixed infrastructure. This is because both AAA and PKI functionality can be handled in the fixed subnetwork of the network. Both servers can reside at the access point and the nodes in the as hoc subnetwork can use their services via the access point. After being authenticated to the whole network the mobile nodes can be a part of the ad hoc subnetwork and enjoy the services. 6 AAA and PKI in Ad Hoc Networks In this section we look at how AAA and PKI can be used in ad hoc domain. 6.1 Issues with Centralized Server As mentioned earlier, there is no fixed infrastructure at all in an ad hoc network. Since any mobile terminal can come and go at any time, the idea of a teminal which is available all the time does not fit in the paradigm. Also, the terminals in the network are very mobile. In fact, they can be so mobile that they can easily go beyond the boundary of the network. For this reason the concept of a centralized server poses a major issue in ad hoc networks. 4

5 6.2 Proposals There have not been a lot of implementations of AAA and PKI in ad hoc networks. There are still a lot of research conducted on different aspects of ad hoc networks. Although PKI has been used in other networking topologies its use in ad hoc domain still raises several issues. In this section we consider a few options for porting AAA and PKI in ad hoc networks and some concerns about those technologies. These options are at the conceptual level and they do not describe any implementation level details. For each of the options we list its advantages and disadvantages. Elected Server Model This model borrows the concept of centralized server where the participants elect one of them to act as the main server for the session. The network also consists of a standby server and this standby server takes over if the main server suddenly disappears from the network. The participants can employ any mechanism to elect the main server. One simple mechanism is to elect the oldest participant to be the main server and the second oldest to be the stanby server. This is shown in figure 2. One request for the whole network Main Server New Participant Standby Server Ad Hoc Network Figure 2: Elected Server Model: Conceptual View In this model, both AAA and PKI functionality must exist in all the participants. The main server is responsible for authentication, authorization and also needs to collect and store the accounting information. It has to poll other participants for accounting information. The trust model employed in this proposal is two-level hierarchical model. The main server behaves as a gateway for trust meaning that if a participant is trusted by the main server then the network (all other participants included) automatically trusts that participant. Inside the network all participants have complete trust among each other. The lifecycle of a participant inside the network can be divided into three categories. First phase is when a participant enters the network. In this phase this new participant is authenticated by the main server. The main server authorizes this new participant to use the resources in the network. This authorization is based on the authorization rules of the main server, which in fact is the AAA server. In the second phase of the lifecycle, this participant become a part of the network. In this phase it has equal trust relationship with other participants in the network, meaning no further authentication is required. Of course, what 5

6 this new participant can do inside the network is determined by what it is authorized to do by the main server. The last phase is involves leaving the network. A participant can either leave gracefully when it informs the main server that it is leaving the network or quit accidently without informing the network (or without informing any other participant). When a participant leaves the network, its previous existance disappears. If it wants to rejoin the network, it has to start from the first phase. The lifecycle for the main and standby servers is a bit different because of the fact that they do a lot more than the other participants. When the main server leaves the network gracefully, it has to handover its reponsibility to the standby server. The standby server, in turn, organises an election to select a new standby server. However, if the main server quits accidently then the standby server needs to take over as the main server and the network can then elect a standby server. For this, the standby server has to constantly monitor the main server and be prepared to be the main server at any time. Protocol The protocol, which is used by the client to access the network, consists of request and response messages. This is shown in figure 3. Client Request Response Server Server2 Accept Session key Session key accepted Trust cache Broadcast client info Figure 3: Elected Server Model: Protocol Overview The client requests the main server for the access. The client specifies what resources it would like to access and what kind of access it would like. The main server does the evaluation and sends response to the client. This response indicates the client what kind of access the server can give to that client on behalf of the network. The client can either accept or reject the response. If the client decides to accept what ther main server offers then the client and the main server can exchange a session key. This session key then becomes a token of trust between the new participant and the network. This trust is then stored in the trust cache for further use, if necessary. The trust cache is local to all the participants. Once the client becomes is accepted in the network, the main server sends the client s information to all other participants so that those participants have the up to date information of the network. Next we discuss some advantages and disadvantages of this model. Advantages i Everything is centralized and accounting information can be easily obtained by 6

7 querying the main server. Disadvantages i Each mobile terminal node must act as an AAA and PKI server. This is quite demanding considering the fact that the mobile devices have limited computational power, limited memory, limited battery life etc. This makes all the terminals very bulky in terms of the extra functionality they are expected to support for the network. Most of the time and for most of the terminals this extra functionality is hardly used for a given session. ii From the trust point of view, this is a very dangerous model. Once a mobile terminal enters the network there is nothing stopping it to become the server at a later stage given that it enters the network at the right time. Once it becomes the server, it has equal authority and the rest of the participants are expected to trust it completely. Now, if this terminal happens to be an advarsary and somehow enters the network, the advarsary terminal can have the control of the entire network. iii The handover mechanism is very weak. All the participants have to constantly monitor if the server is still in the network or not. Not only that, they all have to be aware when standby server takes over and when that happens, they have to elect another participant as the new standby server. This makes all the participants a potential server. iv The exit from the network is very difficult to track. Since the main server cannot keep track of all the participants they should all have some kind of session specific information which expires once a participant loses connection with its last contact. All Server Model This model does not have the concept of "the server" but all the participants become a server of their own. Each of them is responsible of taking care of itself and they are all independent of each other. This is illustrated in figure 4. One request per mobile device New Participant Ad Hoc Network Figure 4: All Server Model: Conceptual View 7

8 In this model both AAA and PKI functionality must exist in all the participants. All the participants act as both the server and the client. When acting as the server, each participant must authenticate its clients, which are requesting access. The server gives adequate authorization indicating what each client is allowed to do. The server also records the accounting information for each of the clients. When acting as a client, each participant should request for authentication and authorization from the server. This model employes the web-of-trust trust model. The trust is per device and trust between any two participants does not extend beyond those participants. The access of a participant is limited only to those servers with which it has established trust. The lifecycle of a participant can be divided into three phases. The first phase is when the participant enters the network. Entering the network here refers to having connection to at least one of the participants of the network. In this phase, the new participant is authenticated by the server it is trying to access. The server authenticates this participant. After a successful authentication the participant is granted authorization and it can access the server. The second phase is after the participant enters the network. In this phase the participant can access the servers with which it established connection earlier. The last phase of the lifecycle involves leaving the network. It is not important whether a participant leaves the network gracefully or quits accidently. As soon as the the connection is cut off, rejoining the network requires starting from the first phase. Protocol The protocol, which is used by the client to access the network, consists of request and response messages. This is illustrated in figure 5. Client Server Request Response Accept Session key Session key accepted Trust cache Figure 5: All Server Model: Protocol Overview The client requests each of the servers for the access. The basic mechanism is quite similar to the electer server model. A session key is established for each server and that session key is valid only for that server. This trust is stored on each server for each client and can be used in the future, if required. Advantages i This model has a better security model than the previous one. This is because if a device is compromised, this does not compromise the whole network as access to a device does not give access to other devices automatically. 8

9 ii The last phase of the lifecycle can be desgined to allow for better caching. It is possible to make the server remember its clients for a certain amount of time if the clients leave gracefully. This can help the server establish stronger trust relationship with the same client next time. Disadvantages i This model is more like peer-to-peer computing model rather than a network. ii If a network contains a lot of participants, the overhead of authentication and authorization is quite big. iii This model contains all the issues related to the limited power of mobile terminal devices such as computational power, memory, battery life etc. iv Accounting information of a device is distributed across the network. If an external entity wants to collect this accounting information, it has to poll all the devices. This can be quite a waste of the bandwidth. Group Server Model This model has the concept of server but the functionality of the server is shared among a set of devices in the network. This model is based on the theory behind threshold cryptography [10]. Out of M (=m+n) mobile device any m devices, as a group, can act as the server for the network. This is illustrated in figure 6. One request for the whole network New Participant Group of devices making the server Ad Hoc Network Figure 6: Group Server Model: Conceptual View Both the AAA and PKI functionalities are distributed among the mobile devices. When the network receives a request from a new participant to join the network, that request is distributed over the m devices, which are acting as a server. Different devices are responsible for different aspects of the functionality and the the final decision is based on the combined result of the server. A client can send its request to join the network to any mobile device in the network. The mobile device which receives such a request from the client becomes the interface device for that client. This interface device delegates the requests to those mobile devices, which constitute the server in the network. The interface device collects the responses from other devices, which received the requests and responds to the client 9

10 with the result. The way how and where the accounting information is stored is still an open issue. The trust model in this group server model is more like hierarchical. However, this hierarchical model is a bit different from the hierarchical model of the Elected Server Model or the one described in X.509. From a participant s point of view, the trust is established between the participant and the mobile device it comes in contact with first. So, the participant perceives that mobile device as the trusted third party. However, for the devices, collectively acting as the server, the trust is between the collection of the devices and the new participant. So, in reality, there is no single trusted third party. And, the trust established this way is the trust between the new participant and the network irrespective of how many devices worked together to make the server. The lifecycle of a participant in this model is exactly the same as the one in the Elected Server Model. The only difference here is that instead of one device acting as the server there is a group of devices that act as the server. Because of this distinction, this model does not have the concept of main server and standby server. This model requires each terminal device to have some functionality of AAA and PKI server. Here, the AAA and PKI functionality is distributed over several terminal devices and the result is a collective work of those devices. For instance, the authentication of a new participant can be distrubuted over three different devices and their collective result can determine the result of authentication. This can be made more robust by delegating the task to any m+n devices and taking the result from any m devices. This can accomodate any possible disagreement among devices or even the possibility of n devices being taken out of the network. Storing accounting information, however, needs careful thought. Once a terminal device is authenticated, it has access to the whole network. Afterwards, it can become one of the devices providing a part of AAA and PKI services to other terminal devices. When the device leaves the network, it does not have a big impact to the AAA and PKI services of the network. Protocol The protocol, which is used by the client to access the network, consists of request and response messages. This is illustrated in figure 7 Client Request Response Accept Session key Accept session key S1 Work1 Work2 Work3 S2 Reply1 Reply2 Reply3 Store trust S3 S4 Figure 7: Group Server Model: Protocol Overview 10

11 The client sends a request to any server in the network. The server which received the request becomes the point of contact of the client to the network. Once this server receives the request it distributes the task of evaluating the request to those m servers and receives the responses. It then examines the responses and evaluates the final response and sends it to the client. Like in the previous protocols the client can either accept or reject the response. If accepted, the session key is established and trust is cached. Advantages i If a terminal device quits the network accidently, the impact of this incident to the overall AAA and PKI functionality is minimal since this functionality can be redelegated to another device. ii Distributing the functionality over several terminal devices also reduces the overall impact of up to n devices being compromised. iii The trust model is reasonably straightforward and is not on a per device basis. Disadvantages i The distribution of services becomes a significant issue if there are less participants in the network. ii Storing accounting information is an issue. This issue can be resolved by making each terminal device record its resource used by other devices. 6.3 Open Issues and Future Work All the proposed models have some common issues. These issues have less to do with the models but more to do with the characteristics of the mobile devices. Due to the limited capability of mobile devices in terms of processing power, memory and power requirements, these devices are not capable of having all the heavy functionalities on them. These devices have to work as routers as well in addition to being terminal devices. Expecting these mobile devices such as a mobile phone or a PDA (Personal Digital Assistant) to have the additional functionalities can be beyond what they are designed for. If these mobile devices start to become more powerful like laptops, such expectation seems feasible. Having said that we believe that further studies are needed in the following areas: 1 Work can be done to slim down the diameter protocol so that it is more suitable for less powered devices. 2 Since mobile devices have to work as routers in ad hoc networks, work can be done to combine routing and authentication. 3 In all the models that are propsed in this paper, authentication and authorization do not require that much of storage unlike accounting information. One important reason for storing accounting is for payment. One area where investigation can occur is some form of pre paid system where a participant has to pay the network during 11

12 authentication and then use that credit to use the services or resources. Depending on the model used, pre-payment can be done either to the network or individual devices. 4 The lifecycle of a mobile device should be investigated in more details for all the models. 5 The implementation details are missing. To consider the details some commonly available devices can be investigated in terms of memory available, computational power of the processor and the possibility of having trust cache. 7 Concluding Remarks Although AAA and PKI are used in fixed infrastructure networks their use in mobile ad hoc networks is still more into research domain. The three proposals that we have presented in this paper are not meant provide the complete solution but they are a good starting point for further research. These models are still more at conceptual level. All models need more and detailed work and attention should be paid to the implementation details. References [1] BERNARD ABOBA, JONATHAN WOOD; AAA transport profile, RFC 3539; IETF Internet Working Group [2] WI-FI ALLIANCE; [3] SCOTT CORSON, JOSEPH MACKER; Mobile ad hoc networking (manet): Routing protocol performance issues and evaluation considerations, RFC 2501; IETF Internet Working Group [4] ITU-T; Information technology - open systems interconnection - the directory: Public key and attribute certificate frameworks; ITU-T Recommendation X.509 ISO/IEC [5] LEON GOMMANS JOHN R. VOLLBRECHT CEES T.A.M. DE LAAT, GEORGE M. GROSS, DAVID W. SPENCE; Generic AAA architecture, RFC 2903; IETF Internet Working Group [6] PRADIP LAMSAL; Understanding public key cryptography and PKI; [7] DAVID SPENCE PAT R. CALHOUN, GLEN ZORN, DAVID MITTON; Diameter network access server application, IETF draft; IETF Internet Working Group [8] JARI ARKKO ERIC GUTTMAN PAT R. CALHOUN, JOHN LOUGHNEY, GLEN ZORN; Diameter base protocol, RFC 2903; IETF Internet Working Group [9] TONY JOHANSSON PAT R. CALHOUN, CHARLES PERKINS; Diameter mobile IP application, IETF draft; IETF Internet Working Group

13 [10] LIDONG ZHOU, ZYGMUNT J. HAAS; Security ad hoc networks; IEEE Networks 13(6):24 30; [11] PHIL ZIMMERMAN; The Official PGP User s Guide; MIT Press;