Figure 3. Agent sequence [30]
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.
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.
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]
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]
Authentication and accounting functionality is not yet defined in the generic architecture.
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].
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]
Authorization requirements for the AAA systems are defined in [17]. Here is a short list of the main requirements from [34].
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]
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].
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]
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].
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].
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]
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].
A trust management systems consist of five basic components. [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].
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].
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.
Mobile IP AAA requirements are described in [20].
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]
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]
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]
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.
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.
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.
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.
| [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 > |
|