Generic Access Method for Network Resources

Abstract

We are living in the communication era. The communication technology is growing at a fast pace. From the market survey, it has been shown that the fastest growing demand in the market was for electronics items in the past before 1990s. After the introduction of the mobile technology in the market, the demand for mobile technology users grew at a rate never before and crossed the graph of the consumer electronics also. There are so many parallel developments within the past decade. The development of computing technology, networking technology, wireless technology, and web technology has resulted in the integrated effort of providing more network services and better quality of the network services. There are many challenges for providing secure and network services to the user may it be internet connection, VPN services or VOIP services or e-commerce.

Acknowledgements

This project work could not have been shaped without the guidance and environment given by respected teachers from IOE. The help and support from the staffs of vendor who have deployed the RADIUS implementation for NT's internet services billing system is also worth mentioning. I would like to thank all for shaping this project to the right track.

Introduction

With the rapid development going on in the communication technology, there is more demand of new services broadly categorized as voice, data and video. The underlying technologies to support such services may be viewed similar to layered architecture of OSI(Open System Interconnection) model. There may be broadly three layers for such system as core layer, distribution layer and access layer. In access layer, there may be different technologies for access at the user end such as the copper technologies, fiber optics technologies and microwave technologies for the transmission of signal working as the access layer. The distribution layer is in the middle of core and access layer and works for distribution of services from the core layer to access layer. The MPLS and VLAN technology used for concentration of user traffic in ADSL system may be an example of the distribution layer. In the core layer there is generation of service which may be voice service, internet service, VOIP service, etc. The core layer thus includes the infrastructure for generation of services. There is new trend of convergence of the telecommunication technologies from circuit switched architecture to packet switched. The use of digital modulation to the customer premises like in ISDN, ADSL service access, use of soft switches instead of normal PSTN switches, use of ATM and POS (Packet Over SONET) as WAN technologies, etc suggest the trend towards IP based technologies. The development of the IP network technology began with the wired media. Development of internet technology helped to connect the users from different networks irrespective of media used and applications and protocols used within the network. With the evolution of client-server technology and server capacity it was then possible to provide the service to many outside of the network. There is huge investment for such service infrastructure. So the service provider has to give access to the services for many users demanding it with proper security and accounting of the usage. There are many access technologies available according to the environment of access for the user. Most used mediums are wire line, wireless and optical. The PSTN services, 56 Kbps dialup services and ADSL services use wire line medium at the user access layer. The GPRS, CDMA data service, wireless broadband services (WiMax) use wireless medium at the user access layer. The FTTH (fiber to the home) based broadband services uses optical medium at the user access layer. The project will try to explore the different technologies in use for the network access and the problems faced for different scenarios while accessing the network services. As this is the age of mobility, and backed by the development of broadband wireless technologies, there is more possibility that the multi access methods would coexist together in access field in the future and IP could provide a simple unique platform for convergence of different techniques. We will begin to see Multi-Mode Devices entering the market. These devices will be capable of accessing WLAN,GPRS/3G and Bluetooth networks from the one device. Such devices will be integrated into mobile phones, PDAs ( as for example Pocket PC, Palmtop, etc) and laptop PCs. Software within these devices will enable users to configure rules that will determine the best choice of network for a particular application. There may be IP carrier based authentication methods which support smooth interaction between mobile terminals and access networks while roaming, and also provides the original model of the implementation based on ICMP/IP. There is possibility of generic, link layer independent authentication and authorization method which supports smooth interaction between mobile terminals and access networks while roaming. This requires analysis of common access authentication schema in detail and the concept of IP carrier with ICMP extension implementation and AAA function based on radius or diameter platform. AAA functions generally include user authentication, authorization of the service to use and accounting of the service usage. Access authentication should prevent the unauthorized user from abusing the network connectivity and prevent intruder from stealing an IP address from an authorized user. When designing authentication schema, two methods are popular: one is based on the PPP and PPP Extensions (such as PPPoE,L2TP) and another is based on LAN layer method (such as IEEE 802.1x). A practical aspect of this technology might be to provide, for example, fixed IP address to a roaming wireless user wherever his/her location might be, to have assigned IP address and subscribed class of service

Problem definition

PPP was deployed widely in communication world, especially in traditional telecom and wireless world, for dialup services, etc. But in many access technologies the most cost effective method to attach multiple hosts to the customer premise access device is via Ethernet. But providing access control and billing functionality in Ethernet LAN is not easy task when connecting multiple hosts at a remote site through the same customer premise access device. For such purposes PPPoE and L2TP were introduced. Through the client and server model, PPPoE and L2TP can control the connections based on user granularity. These protocols can also adopt EAP (extensible authentication protocol) to incorporate access authentication. The guideline for the future direction of access technology for the network resources is summarized as,

1. Only the authentic user must get access to the network. The user's identity as the authentic service user must be secured from the intruders or malicious users.
2. Only the authorized service must be given access to the user. This may be by implementation of service profiles to the user (or maintaining QOS) and provisioning systems.
3. Correct accounting of the resources used by the users must be done.
4. In case of availability of multiple access alternatives, users should feel indifference to the access alternatives used while using the service.
5. Users should not be restricted for using the network resources due to mobility.

Those guidelines are easier for statement than implementation. So with this project the challenges faced in different scenarios for the implementation of above guidelines and practical solutions will be explored.

Objectives

1. To study the various network access methods and their security issues
2. To study the implementation of AAA functions
3. To evaluate RADIUS and Diameter protocols under different conditions of AAA implementation

Project Methodology

Literature Review

What is access layer technology?

A layered view of service provider's infrastructure is helpful for concentrating the development of different protocols in a layer. Basically, the service provider's infrastructure is divided into three layers.

Core Layer

This layer is characterized by the high speed network connection with high throughput network nodes. The core service providing servers are in this layer. This layer is also considered the backbone of the network. This layer of network does not route traffic and also do not manipulate the data packets. This layer is instead concerned with the speed and reliable delivery of packets. No policy is enforced on the data traffic in this layer. High reliability for transport of data packets is ensured with the provision of redundant links or data paths. Fewer and faster systems create a more efficient backbone layer.

Distribution Layer

This layer is mainly focused with distribution of channel to next layer, the access layer. This layer mainly comprises of networking technologies and uses mostly routing protocols for correct routing of the data traffic to access layer. The QoS is maintained in this layer as it is also the aggregation point for access layer traffic. The distribution layer is responsible for routing. It also provides policy-based network connectivity. This layer serves as the boundary for broadcast and multicast domains. The layer allows you to create protocol gateways to and from different network architectures. The distribution layer also performs queuing and provides packet manipulation of network traffic.

Access Layer

It is the layer where there is direct access of the customer. The examples of the access layer arrangements are wireless access point, RAS, DSLAMs for DSL/ADSL connections, etc. The mac address filtering, creating separate collision domains, sharing bandwidth, and all user level control are performed in this layer. The access layer contains devices that allow workgroups and users to use the services provided by the distribution and core layers. In the access layer, we have the ability to expand or contract collision domains using a repeater, hub, or standard switch. This layer may have low power devices such as hubs switches or access points as compared to high power devices used in core and distribution layers. The AAA functions are to be considered in this layer. This fuction helps for user administration, accounting and authorizing. The present project is concentrated in access layer of the service provider architecture. This layer is also characterized by the need to multiplex the multiple access created by large number of individual identities of the user. Physically we can view the three layers in terms of types of equipment used. They are presented in a diagram below.

What are the requirements of access layer implementations?

The protocols and the developments for services are based on the requirements. So for implementation of access layer functions there are basically three requirements.

1. Need for efficient and secure authentication of the user or entity
2. Need for appropriate authorization for the user
3. Need for correct accounting of the usage

All the above requirements are summarized in a protocol called AAA protocol. "AAA "stands for Authentication, Authorization and Accounting.

Authentication

This function is needed in the system for making sure that the user is authentic and has rights to use the service. Security concerns are the main threat to implementation of the authentication function. The implementation of authentication consists of two acts, one being providing the proof of authenticity by the user and another being the act of verifying the proof of authenticity by the service provider. There is basically three types of authentication.

1. 1. client authentication

It may be user or device that needs to be authenticated through the credentials provided by them

1. 1. message authentication

In this type of authentication authenticity of the message is checked. Eg. Using digital signatures.

1. 1. mutual authentication

when the user needs to test the validity of the network also it is connecting to, this type of authentication is used. There are two modes in which authentication can be performed. The access link protocol considers the physical channel and link layer protocol. The layer-2 services like packet formatting, framing and multiple-access mechanisms are needed in access link protocol. PPP was a protocol of choice for phone line dialup and cellular systems for layer-2 services. The AAA protocol is implemented in a relatively secure network channel in case of single administrative domain. In multiple administrative domain, the AAA protocol may traverse untrusted network also. Currently most favoured AAA protocol is the RADIUS (remote access dial In user service) protocol. Other protocols in use are TACACS+ (Terminal Access Controller Access Control System), Kerberos, COPS (Common Open Policy Service) protocol and in future may be Diameter. The different classes of authentication mechanism can be based on following three criteria.

1. Authentication based on something the authenticating party has, such as a physical hardware token or a card.
2. Authentication based on something the authenticating party knows, such as a secret or a password.
3. Authentication based on something the authenticating party is, such as a physical characteristic of the link it is attached to.

Authorization

It is the next function to be performed after the authentication is successful. It is the act of determining whether a particular privilege can be granted to presenter of valid credentials. What kind of privilege and to which resources for a user is decided with this protocol. Privilege can be right of access to a resource like communication link, an information database, a computing machine or particular services. The authentication process is completed by AAA server. Then authorization process is done with provisioning server which acts as an interface to the service equipments or resource manager which controls the resources. Advanced implementation of authorization is aided by policy framework which helps to have flexible control over the authorization process.

Accounting

It is the correct auditing of the usage of the service. It defines procedures for collecting usage data. Accounting server sends the usage data to the billing server which converts the usage in terms of monetary values. may be extended to have inter-domain accounting functions in which the accounting packets and session records cross the administrative boundaries. Accounting data from the network access servers or service devices are collected by the accounting server. Accounting server does processing of accounting data which may include summarization of fraction of accounting information, elimination of duplicate data, generation of session records, etc. In the case of accounting across administrative domains where the administration of each network is managed by separate accounting and billing server, there involves intra-domain accounting and inter-domain accounting.

Polling model

The accounting server or accounting manager polls devices for accounting information at regular interval. The polling interval needs to be shorter than the maximum time the polled device can hold the accounting information. Regular polling may increase network traffic. There is loss of accounting data in case of device reboot if device has volatile storage.

Event-driven model

The device contacts the accounting server when it is ready to transfer the accounting data. Most event-driven accounting systems, such as RADIUS-based accounting systems, do not perform batching and hence transfer only one accounting event per packet. This model is called even-driven model without batching and is rather inefficient. An event-driven model typically stores accounting events that have not yet been delivered only until a timeout interval expires. Once the timeout interval has expired, the accounting event is lost, even if the device has sufficient buffer space to continue to store it. As a result, the event-driven model has the smallest memory requirement, and is the least reliable, since accounting data loss will occur due to device reboots, sustained packet loss, or network failures of duration greater than the timeout interval. The event-driven model is frequently used in networks with roaming applications, since this model sends data to the recipient domains without requiring them to poll a large number of devices. As roaming accounting events are frequently of high value, the poor reliability of this model is an issue. As a result, an event-driven polling model may be more appropriate. In event driven with polling model, accounting manager polls the device when it receives an event from the device. Event may be like when a batch of given size has been reached, data of certain type are available, lapse of certain time interval, etc. In the event-driven model with batching, a device will contact the accounting server or manager when it is ready to transfer accounting data. However, the device contacts the server when a batch of a given size has been gathered or when data of a certain type are available or after a minimum time period have elapsed. Since, such systems transfer more than one accounting event per packet, they are more efficient. An event-driven system with batching will store accounting events that have not yet been delivered up to the limits of memory. As a result, accounting data loss will occur due to device reboots, but not due to packet loss or network failures of short duration.

Implementation scenarios of access layer

Providing a complete solution typically requires understanding of all the dimensions of the problem typically through analysis. This can be rather difficult as more and more sophisticated networks and services arise, and more and more sophisticated hackers deploy ever stronger computing devices against these networks every day. Thus, it is no surprise that a large number of authentication mechanisms have been developed and standardized through a variety of standard bodies. The plethora of authentication mechanisms is so large that the Internet Architecture board (IAB) has decided to conduct a survey and a classification of various authentication mechanisms to aid the designers to better understand and track the process in the field [AUTHSRV]. In the beginning of the internet development stage, most widely used service was the dialup service that used PPP (point-to-point protocol) and PPP was designed to provide a number of link layer functionalities. The traditional dial-up networks and even some of the newer wireless access networks, such as CDMA2000 cellular networks, provide data service to mobile users relying on PPP for establishment of layer-2 links to network access node. From the standpoint of these networks, the main role of PPP is to provide layer-2 framing by encapsulating the data between the PPP header and the cyclic redundancy (CRC) checks. PPP includes three phases that are vital for setting up dial-up connections:

1. Link control protocol (LCP) phase: It is the first phase of PPP during which PPP allows the user and the network to negotiate link parameters such as maximum frame size and link speed. The important point for this discussion is that LCP also allows the two parties to negotiate a mechanism for the authentication to be performed during the next phase.
2. Authentication phase: The second phase of PPP is designed to handle authentication exchanges according to the authentication protocol that was negotiated during the LCP phase of PPP. The PPP end point within the network can either authenticate the supplicant directly, or act as a mediator and pass the authentication credentials to an authentication server (or an AAA server). PPP originally supported two authentication methods: password authentication protocol (PAP) and challenge handshake protocol (CHAP).
3. Network control protocol (NCP) phase: It is the phase during which network layer parameters such as header compression protocol and the network protocol (such as IP or IP control protocol, IPCP) are negotiated.

PAP and CHAP over PPP are merely user authentication protocols and not encryption protocols, i.e. they do not provide data privacy protection for the PPP link. PPP link by itself does not provide data encryption service for protection of PAP or CHAP data either. Hence, the PAP or CHAP data carried by PPP essentially goes over unprotected media. The reason PPP was designed this way is because it was designed for phone lines and phone lines are physically difficult to hijack. Furthermore, PAP and CHAP themselves are not considered as cryptographically strong mechanisms. PPP and CHAP are vulnerable to a variety of attacks. For those reasons PPP-based authentication phase is deemed unfit for wireless channels, such as CDMA2000 and 802.11 wireless local area networks (WLAN). These systems tend to deploy specific methods for authentication of data traffic Next drawback with PPP authentication mechanisms is that, when PPP is used for link layer connections, the protocol and mechanism by which the user were to authenticate to the network was negotiated during LCP phase of PPP. The actual act of authentication is performed during the authentication phase of PPP. This means that the network point of presence with which the user engaged needs to understand the negotiations regarding the authentication mechanism. Adding new authentication mechanisms, algorithm, or even parameter changes requires upgrading the network points of presence. Due to the inflexibility of PPP toward new authentication mechanisms, the IETF decided to extend the PPP protocol. IETF PPP extensions group designed the EAP (Extensible Authentication Protocol) specifications in the form of RFC 2284 as an extension to PPP. EAP was designed to provide extensibility to PPP by providing support for generic and newer authentication mechanisms. EAP can be chosen as one of authentication mechanisms over a PPP link. However, the difference between using EAP versus PAP or CHAP over PPP links is that the two ends of the PPP negotiation negotiate the use of PAP or CHAP as well as the authentication parameters (such as hash function, etc.) during LCP link negotiation phase, while, EAP as an authentication method is negotiated during the authentication phase of PPP as opposed to during LCP phase. This way, when EAP is chosen as authentication protocol, the actual authentication is performed at a later stage. The main advantage of EAP is the flexibility it provides to the three-party authentication models. Whenever, new authentication methods are developed, rather than requiring the authenticator (NAS) to be updated for support of the new method, EAP permits the authenticator to simply pass the message exchange for a new method through to a backend server that in turn understands the new authentication method. This way, only the backend server (typically an AAA server) needs to be upgraded. This saves the administration the trouble of upgrading a large number of NASs (at the edge of network).The implementation of EAP is shown in a block diagram as below. Finally, another concept that is useful to be familiar with, when considering security is the concept of threat model or threat analysis. Threat analysis is a very important step in choosing authentication and security mechanisms. During the threat analysis, the designers brainstorm on what security problems can arise for their network architecture and its usage scenarios, what sort of attacks can be performed on the ongoing communications or on the network entities and how these attacks should be countered. An important factor to consider is also to assess how technically savvy or competent are the users. Practical examples of security measures to consider include: should the data being communicated protected against tampering or eavesdropping. Implementing EAP for authentication has a problem that they only provide security mechanisms for the link between the client and a device at the edge of the network (network point of presence) and do not extend beyond that single hop. There are many implementation scenarios that arise when link layer security mechanisms are deployed for generic communications scenarios which have multiple hops. One prominent method for solving the problem is to deploy a so-called virtual private network (VPN). The VPN establishes a secure channel between the two network parts (hence the term "private") and routes the traffic in a way that the users at each end feel they are part of the same network (hence the term "virtual").

RADIUS (Remote Access Dial-In User Service)

RADIUS was originally designed to serve the purpose of allowing a NAS to forward a dial-up user's request and its credentials to a backend server (three-party authentication model). The Access-Request, Access-Challenge message structure in Radius attests to the fact that Radius was originally designed to accommodate PAP and CHAP. However, due to its extensible nature; RADIUS is able to support more complex EAP authentication methods through support for EAP. Furthermore, RADIUS was later extended to provide authorization and accounting procedures. The attributes are the main vehicle for carrying information over RADIUS messages. This means, the attributes also provide the opportunity to extend the functionality of RADIUS server to interact with many other entities and for many purposes. Also to support implementation-specific scenarios, vendor-specific attributes (VSA) can be defined, so that each vendor's NAS and RADIUS server can interact in a manner that is specific to the implementation defined by the vendor. Most of the functionality provided by RADIUS protocol is driven by the attributes that RADIUS messages carry. Security and privacy requirements dictate that some of these attributes must be protected from eavesdropping during transport. In RADIUS this is mostly provided by a feature called attribute hiding. Since RADIUS was initially designed to support PAP and CHAP-based authentication mechanisms, support for hiding the attributes that carry passwords was added to basic RADIUS specifications. Attribute hiding performed for "User Password" is typically called password hiding. The RADIUS message set is rather simple and consists of only eight messages, of which only the first four are specified in the base specifications.

1. Access Request: This message is generated by the NAS (RADIUS client) towards the server to forward the request from or on behalf of a user.
2. Access Challenge: This message is sent from the RADIUS server to the RADIUS client (NAS) and is generally used to question the NAS or the user about something or perform some sort of negotiation.
3. Access Accept: This message is sent from the RADIUS server to the NAS to indicate a successful completion of (and typically grant) the request.
4. Access Accept: This message is sent from the RADIUS server to the NAS to indicate a successful completion of (and typically grant) the request.
5. Accounting request: This message is sent from the client to the accounting server to convey accounting information regarding the service provided to the user.
6. Accounting response: This message is sent by the server to the client to acknowledge that the accounting information sent by the client has been received and indicates the result of the performed accounting function by the server.
7. Status-Server and Status-Client: These two messages are experimental.

RADIUS can be considered as an application layer protocol, running over a transport protocol. At the time of the RADIUS specification, UDP was deemed more appropriate than TCP, due to the fact that TCP session establishment is a time-consuming process involving state machines. As will be discussed later, the lack of reliability support in UDP causes some serious problems for RADIUS, especially for accounting functions. Security protection in RADIUS is rather primitive. Two main functions are provided, one is attribute (mainly password) hiding and the other is authentication of certain messages. Both these functions are performed using MD5 hash functions and a secret that is shared between the RADIUS server and the RADIUS client (NAS). This secret is usually called the RADIUS shared secret. As a way of getting around the security vulnerabilities of the use of the shared secret for RADIUS, the community has started recommended using IPsec in some of the specifications for which security is extra important. One such specification is RFC 3579 which defines the support of RADIUS for EAP. EAP provides a key management framework that allows the AAA server to assist the user and the NAS in establishing a secure communication channel before starting data traffic. As we saw there, the key material needed at the NAS needs to be transported from the AAA server to the NAS over the AAA protocol. To provide authentication and encryption support the use of IPsec is recommended for the protection of RADIUS messaging. EAP is designed to provide support for a generic authentication protocol without requiring specific upgrades to the NAS. Since EAP relies on a backend server to understand and perform the actual authentication, RADIUS was extended to provide this support. when transiting between the NAS and the RADIUS server, EAP messages are carried over a AAA protocol. The RADIUS flexibility and extensibility provided by the concept of carrying information inside attributes allow RADIUS message even to carry messages from other protocols. The EAP-RADIUS framework allows the messages for EAP authentication schemes to be embedded inside RADIUS attributes and carried along RADIUS messages. The embedding of EAP authentication messaging in service provider's network is shown below. RADIUS accounting uses two messages types: Accounting Request and Accounting Response, both of which are also transported over UDP. Accounting Requests are always sent from the RADIUS client towards the RADIUS server, while Accounting Responses are generated by the RADIUS server upon receiving and processing the Accounting Requests. However in roaming scenarios proxy servers may have a hand in the Accounting Request-Response exchange. Because RADIUS is transported by UDP, reliability in data transfer is not guaranteed. So it is possible that the accounting packets are lost in the network. Loss of RADIUS Accounting-Stops creates several problems as follows:

1. Incomplete and incorrect billing information for metered services results in lost revenue or customer disputes that cannot be resolved.
2. Some operator networks may implement a limit on the number of simultaneous sessions a user can run at any given time. If accounting packets carrying the stop indication for some previously ended sessions are not received by the server, the user will be out of luck when trying to start a new session.

RADIUS specification is very primitive for mobility and multi-domain operation support. RADIUS specification provided by IETF does not provide any support for Mobile IP functionality; most support for user mobility is in terms of support for roaming applications and is based on the work done by the "Roaming Operations" working group in IETF, shortly named ROAMOPS

Diameter

The RADIUS protocol has since a time back been used with AAA services for dial-in PPP(Point to Point Protocol) and terminal server access. The Diameter protocol wasn't created out of nothing but the creators rather have retained the basic RADIUS format and have tried to fix all the known different RADIUS deficiencies. Diameter doesn't use the same Protocol-Data-Unit (PDU) as RADIUS but still borrows sufficiently from RADIUS in order to be backwards compatible. The idea with Diameter is to create a base protocol which easily can be extended in order to allow new access methods. Currently the developers are limiting the scope of the Diameter protocol to Internet access, through common PPP and through the criteria's stated by the ROAMOPS and Mobile-IP models. Diameter consists of a Base protocol and different extensions and applications like CMS Security, NASREQ and Mobile-IP. All basic functionality common to all applications and services is implemented in the base protocol while all application specific functionality exists within the different applications The Diameter base protocol concerns itself with capabilities negotiation, how messages are sent and how peers may eventually be abandoned. The base protocol also defines certain rules which apply to all exchanges of messages between Diameter nodes. The Diameter base protocol is intended to provide an AAA framework for Mobile-IP, NASREQ (Network Access Server REQuirements) and ROAMOPS (ROAMing OPerationS). The Base protocol also specifies message format, transport, error reporting and security services to be used by all diameter application and must be supported by all Diameter implementations. [ietf-draft] One thing that is new with Diameter is that the Diameter base specification defines the concept of applications. Diameter applications are services, protocols, and procedures that use the facilities provided by the Diameter servers, proxies and the Diameter protocol itself. A good example of a protocol using Diameter is Mobile IP. All Diameter applications must support the functionality specified in Diameter base specification. This explains why Diameter base protocol is at the bottom of the pyramid Dealing with NAS for authentication and authorization purposes is considered an application for Diameter. Despite all the volume and feel of completeness offered by Diameter base specification, no details on simple authentication and authorization procedures or even on interaction with NASes are provided in that specification. The interaction of Diameter with NAS for providing authentications is defined in a separate specification (NAS application). Also when it comes to authorization, the Diameter base protocol assumes that authorization request messages (including those for access authorization) are application specific and need to be defined by other application-specification documents. The Diameter base specification goes only as far as saying that the Diameter client is the entity issuing an authentication and/or authorization request on behalf of the user to the server, but does not offer any detail on the messaging procedure or the messages themselves. Diameter base specification does define messages for terminating user sessions. The Diameter base specification also specifies end-to-end as well as hop-by-hop security mechanisms. Unfortunately transport layer security protocols, such as TLS or network layer security protocols, such as IPsec would provide security for the entire Diameter message between the two nodes. However, often it is important to protect only specific data objects from some dubious intermediaries, while the message itself may have to be examined or processed by these intermediaries. Roaming scenarios, where Diameter signaling has to go through foreign-owned Diameter proxies, are perfect examples of this. To provide end-to-end data object security an additional security mechanism, called Cryptographic Message Syntax security (CMS) module was suggested. Unfortunately, even though the specification describing the use of CMS with Diameter [DICMSDR] was pursued by the IETF AAA working group for a while and survived 4 revisions, it is no longer an active working group item. Some of the applications in Diameter protocol are as given below. Diameter accounting: This is the only Diameter application whose specification is provided in the Diameter base protocol specification. Diameter credit control application: It support the pre-paid model used in cellular networks with AAA infrastructures. Examples of services requested by end users are: messaging service, download service, and many other services controlled by Session Initiation Protocol (SIP). The service provider must be able to determine the allowed coverage for each of the requested services prior to service initiation and cease the initiated service, once the applied credits are exhausted. The credit control application provides methods for real-time credit control for many services offered by the cellular networks to the end users. This application defines the interaction between the entity providing the service and the so-called credit-control server. The application specification is currently a work in progress. Diameter NAS application: This application describes the details of the interaction of the Diameter servers with network access servers (NAS) for authentication and other procedures The NAS application would be the closest Diameter specification to RADIUS base specification, as RADIUS was also originally designed to provide authentication services to PPP users. The NASREQ application allows the NAS to support a variety of authentication mechanisms, such as PAP, CHAP and EAP. NASREQ supports RADIUS attributes as often as possible to provide backward compatibility with RADIUS. Diameter Mobile IP: While Mobile IP facilitates routing and transport of data for communications to and from a mobile host, Diameter, among other things, facilitates identity verification and authorization mechanisms for end hosts. The IETF Mobile IP community has also defined a number of security and key management mechanisms that are facilitated by AAA protocols, but has left the specification of the AAA mechanisms to support those mechanisms to the AAA community. While RADIUS does not provide any specific guidance for Mobile IP applications, Diameter Mobile IPv4 application specification closes the gap in a rather complete manner for Mobile IPv4. This application furthermore allows for mobility across administrative domains. Diameter EAP is another Diameter application defining procedures for carrying EAP exchanges over Diameter messages between the NAS and Diameter servers. Various entities involved within a Diameter infrastructure are ,[RFC 3588] Diameter Node: A host process that implements the Diameter protocol. Diameter Peer: A diameter node that has a direct transport connection with another diameter node. Diameter Client: A device at the edge of the network that performs access control. Examples are NASes or Mobile IP foreign agents. Diameter server: A server is the device that handles AAA requests (authentication, authorization and accounting requests) for a particular realm. The server must support Diameter base protocol and additional Diameter applications utilized in the realm. Diameter Agent: The agent is a Diameter node that provides relay, proxy, redirect or translation services. Relay agents: It forward Diameter messages based on routing-related attributes with the message and special routing tables. Relay agents do not make any policy decisions and therefore do not examine any non-routing attributes within the messages. For that reason, these agents need to understand the semantics of routing-related attributes only. A relay never originates a message, but is capable of handling any Diameter application or message types. Proxy agents: It can be seen as relay agents that can also make policy decisions. They can track various states at the NAS device for resource provisioning purposes. Proxies typically do not respond to the client requests, but may originate Reject messages in cases where policies are violated. Redirect agents: They do not sit on the forwarding paths and do not alter any message attributes. So, they do not forward any messages, as relay agents do, but refer the client to a server by redirecting the messages according to a configuration. They are able to handle any message types but may be configured to only redirect certain message types. Translation agents: They perform protocol translations between Diameter and other AAA protocols, such as RADIUS. They are specially considered for backward compatibility with RADIUS. Diameter messages consist of a standard header, and a number of AVPs. most of the information to be carried by Diameter in the form of attributes are formatted as attribute-value pairs, commonly known as AVPs. AVPs can arbitrarily be added to messages, as long as the minimum required AVPs for a message are included and no AVP that is specifically excluded for inclusion in that message is added. All Diameter implementations must support the IPSec transport mode with encryption and authentication algorithms to provide per-packet authentication and confidentiality. They must also support IPSec anti-replay mechanisms. Furthermore, Diameter mandates the use of Internet Key Exchange (IKE) for peer authentication, key management and negotiation of IPsec security associations in all Diameter implementations. As part of the transmission level security at each connection, not only are the two Diameter peers on each side of the connection ("AAA hop") required to authenticate each other, but also they need to authorize both the connection and the session. A sample message exchange for Diameter accounting application is shown below. The capability exchange messaging is included for completeness to make sure that both nodes support the accounting application. In contrast to the RADIUS specification, Diameter is a peer-to-peer protocol with more than just authentication and accounting in mind. The Diameter NAS application specification, describing the interaction between the NAS and the Diameter server is not fully standardized yet and is still in Internet draft form

Other existing AAA protocols

There are many AAA protocols in use besides RADIUS suited for the specific application and efficiency. Some of them are listed below.

Kerberos

Kerberos is an authentication service developed as part of the ATHENA project at MIT. Kerberos is one of the earliest developed Authentication protocols and is also one of the most widely used Authentication protocol on the market today. Kerberos avoids sending passwords over a network where they may be sniffed by snoopers or captured by hackers, instead relying on encrypted messages from the user to a Kerberos security server. Once proper ID is established, Kerberos issues an encrypted ticket which the user can use to Authenticate himself to the server he wishes service from. The authentication process proceeds as follows: A client sends a request to the authentication server (AS) requesting "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of a "ticket" for the server and a temporary encryption key or a "session key". The client transmits the ticket (which contains the clients identity and a copy of the session key, all encrypted in the servers key) to the server. The session key (now shared by the client and server) is used to authenticate the client, and may optionally be used to authenticate the server (if mutual authentication is desired). The session key may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication. [RFC 4120]

TACACS+

TACACS (Terminal Access Controller Access Control System) is an industry standard protocol specification that forwards username and password information to a centralized server. TACACS+ protocol is a new version of the TACACS protocol referenced by RFC 1492. TACACS+ is Cisco's propriety security implementation of TACACS. It is a client/server protocol where a client (Network Access Server) sends a request, which is responded by the server (AAA server). The protocol is based on the TCP transport protocol. The overall design goal of TACACS+ has been to define a standard method for managing different Network Access Servers (NASes) from a single management server, such as a server in connection with a database. TACACS+ improves on TACACS by separating the functions of Authentication, Authorization and Accounting and by encrypting all traffic between the NAS and the TACACS+ node. TACACS+ also allows for arbitrary length and content authentication exchanges which allow for any authentication mechanism to be used with TACACS+ clients. It is extensible to provide for site customization and future development features, and it uses TCP to ensure reliable delivery. The separation of authentication, authorization and accounting is a fundamental component of the design of TACACS+, but an implementation or configuration is not required to employ all three. TACACS+ overall function is similar to that of RADIUS but RADIUS has enjoyed a more widespread use since it is not a proprietary of Cisco.[draft-grant-tacacs-02]

COPS

COPS (Common Open Policy Service) protocol is a query and response protocol stated in RFC 2748 and is a policy control protocol to be used as a link between a PDP (Policy Decision Point) and a PEP (Policy Enforcement Point) usually a NAS. Recently (read within the last two years) voices have been raised to propose the protocol AAA Working Group as a possible future AAA protocol. The basic model of interaction between a policy server (PDP) and its clients (PEPs) is compatible with the policy framework document "Policy based admission control" RFC 2753.

An implementation Scenario

There are many discussion forums in the internet which bring about the specific issues related to the AAA protocol implementation. As RADIUS is the widely used protocol for AAA functions, there are vendors who have made their own flavor of RADIUS implementation. Due to wide acceptance of RADIUS as AAA server, there are more scenarios of use of RADIUS and increasing cases which the RADIUS must cope with by extension of its functionality. The extension cases of RADIUS can be explored from different literatures of IETF website and RADEXTWEB ( IETF RADIUS extension working group).

Sample RADIUS Server log messages

02/17/2010 12:13:46 #09 000E Authenticate: from 202.70.79.121 - Reject User: adsl025585661, Reason = Your account is not active, CallerID = htd_bras/0 0/0/0:4096.32 Itahari/0/0/4/0/1:8.81/Remote-Agent-Id Not Present 02/17/2010 12:13:46 #09 0011 Authenticate: from 202.70.79.121 - Reject User: adsl5120600, Reason = User Not Found, CallerID = htd_bras/0 0/0/0:4096.1015 BRGNJ_DSLAM1/0/0/4/0/36:8.81/Remote-Agent-Id Not Present 02/17/2010 12:13:46 #09 0008 Authenticate: from 172.16.100.1 - Reject User: adsl654833, Reason = You reached maximal concurrent sessions, CallerID = NT-SE800/0 0/0/0:4096.17 Naxal3/0/0/10/0/50:8.81/Remote-Agent-Id Not Present 02/17/2010 12:13:46 #09 0019 Authenticate: from 172.16.100.1 - Reject User: adsl440433, Reason = Password Mismatch: Password Typed = adsl440433, CallerID = NT-SE800/0 0/0/0:4096.71 bhaktapur/0/0/4/0/39:8.81/Remote-Agent-Id Not Present

Inference cases found in literatures

There are many literatures regarding the hotly debated issue of what requirements will be incorporated in the upcoming generalized AAA protocol and which AAA protocol to deploy to meet maximum heterogeneous environments. Some literatures are regarding the drafts made for the requirements that future AAA protocol should meet. Some others are regarding the protocol specifications and others related to application specific implementation. Those literatures are the basis for the current project work and are referred extensively in the section 4.1.

Algorithm Development for comparison

As per the usage instances found from the data collection different criteria can be formulated like scalability, failover, mutual authentication between client and server, transmission level security, etc. Those evaluation criteria can be broadly categorized into two categories as,

1. Requirements point of view
   1. Functional requirement of the protocol
   2. Manageability of the protocol with respect to administration
   3. The most important is the security issue
   4. Economic point of view for deployment
   5. Existing Market share
2. Technical point of view

1. Server initiated messages
2. Reliable Transport
3. Capability Negotiation
4. Security and Audibility Issues
5. Agents and Inter-Domain Roaming
6. Peer Discovery and Configuration
7. Compatibility

Comparison and analysis

Comparison between all the protocols can be made from requirement point of view. Then the competing protocols will be analyzed from the technical point of view.

1. 1. Comparison with respect to functional performance

Kerberos v5 is today widely used as a plain Authentication protocol but it might be used in close connection with the other AAA protocols (TACACS+, RADIUS) as their Authentication mechanism. COPS was developed to support different policy based services and is like Diameter made to be scalable. The protocol was created for and is best used with general administration, configuration, and enforcement of policies, but with minor to medium work it can come into total compliance with the AAA requirements and is therefore suitable to perform AAA functions as well, all in accordance with RFC 2748 RADIUS is best used as an AAA protocol in minor to medium size networks as it has congestion control problems. It doesn't completely support the scalability requirements since only up to 256 outstanding requests can be handled at the same time, instead of tens of thousands simultaneous request between two communicating devices. Like RADIUS TACACS+ is best used as an AAA protocol in minor to medium sized networks. The TACACS+ specifications says the protocol is scalable to provision large networks but lately some complaints about this not being entirely true have been raised since the protocol in large networks have started to show degraded performance. Diameter is developed to be an AAA protocol used in anything from small to very large networks with the scalability in mind and 2^32 different requests can be handled simultaneously. It also is backwards compatible with RADIUS which makes Diameter agents able to act as RADIUS gateways sending RADIUS messages trough the network without any conversion needed.

1. 1. Comparison with respect to Firewall friendliness

A firewall friendly protocol is one which is designed to accommodate a firewall acting as a proxy according to RFC2989. to be firewall friendly, stated by the Mobile-IP Working Group [ 19 ] for protocols to support Mobile-IP, permits a Home Agent AAA-server situated behind a firewall to be reachable from the Internet so it can provide AAA services to a Mobile-IP Foreign Agent. Another thing that could be accounted a firewall friendly protocol is that the protocol doesn't make the firewall look into packet much beyond the application port number. Since Kerberos runs on both UDP and TCP with fixed ports assigned by IANA and the Kerberos packets are easily recognized by a firewall (i.e. without thorough packet examination), Kerberos is considered to be firewall friendly. COPS runs over TCP and uses a fixed port number assigned by IANA, in addition, COPS proxy servers can easily be supported which is why it is considered firewall friendly. But on the other hand, depending on what it means to be firewall friendly, since COPS has other usage's than AAA and uses the same port for every kind of message a firewall has to look deeply into the package to determine what kind of package it is, and this doesn't comply to being firewall friendly. RADIUS is known to be operational in environments where firewalls acting as proxies are active. RADIUS also runs on a fixed port number assigned by IANA which helps the firewall and is on the market considered to be firewall friendly. TACACS+ is known to be operational in environments where firewalls are acting as proxy. As RADIUS, TACACS+ also runs on a fixed port number assigned by IANA which helps the firewall and TACACS+ is, as RADIUS, therefore considered to be firewall friendly on the market. Diameter relies on SCTP, which is currently not supported on firewalls, and can therefore not be used with some firewalls. However a firewall could easily implement a Diameter proxy server, which would provide for firewall penetration, as an application proxy and it would probably be more secure than punching holes through the firewalls. In the future as SCTP gets more recognition on the market one can assume that firewall implementations will allow Streaming traffic to penetrate the firewalls. But with the ability for the Diameter protocol to accommodate firewalls acting as proxies and that Diameter packages are easily recognized and it could be considered firewall friendly.

1. 1. Comparison with respect to manageability of the protocol

When using Kerberos to Authenticate a user against a server (any server) the user needs to have a shared secret with the TGS and this secret shouldn't be passed over the Internet but in fact be distributed in some trusted offline form. With a shared secret with the TGS the user never has to send a password over the Internet. The COPS protocol that, like Diameter, relies on CMS Objects to provide security doesn't require a key to be distributed in any trusted offline form, since the use of CMS enables the communicating peers to exchange secret keys through the Deffie-Hellman key exchange capabilities provided by the CMS support. The RADIUS protocol requires a shared secret to exist between the communicating client and server. This shared secret is required to pre-exist the communication attempt and thus needs to be transmitted in some secure offline form, so that it can't be snooped off the Internet. The TACACS+ protocol requires that a shared secret exist in order to provide confidentiality. So in order to be able to provide any kind of confidentiality to the message a shared secret needs to exist between two peers. Without a shared secret no confidentiality can be provided so to achieve confidentiality one has to distribute keys in an offline secure form, to, like with RADIUS prevent key snooping on the Internet. But for messages that don't require confidentiality, no offline key distribution is necessary. The Diameter protocol doesn't require a shared secret between communicating peers and thus there is no need to distribute keys in any kind of offline form.

1. 1. Comparison with respect to security

The Kerberos protocol is usually just used to authenticate a client/user to a network node. Kerberos is an Authentication protocol that doesn't need to send the user password over the net, and through this the information sent to the Authentication server, in Kerberos case the TAGS (Ticket Granting Server), doesn't encrypt the Authentication message to the TGS. Since the user password is never sent over the Ethernet, every opportunity to sniff the net for passwords is removed. In COPS all the objects can be protected through the use of the Cryptographic Message Syntax. In the RADIUS protocol just the Authentication information is encrypted and the AVPs are in plain text according to RFC 2865 the TACACS+ header (describes the remainder of the packet) of 12 bytes is always in plain text and the complete body of the packet may be encrypted. In Diameter all the AVPs can be protected through the use of the Cryptographic Message Syntax.

1. 1. Comparison with respect to encryption

While Kerberos is just an Authentication protocol there is no need for encryption beyond the Authentication part since there is no entire message other than the Authentication information. As Kerberos is just an authentication protocol the only security it applies in usage is the encryption of the TGS ticket, encrypted with the receiver's key i.e. the requested service providers key, which the service provider receives from the requesting user. The COPS protocol supports the use of CMS objects and once the support is implemented it is easy to use the extra security CMS provides. With COPS, encryption of the entire message is possible The RADIUS protocol only encrypts the authentication information with no possibility to encrypt the other AVPs, i.e. it is impossible to use any extra encryption. With RADIUS, just encryption of the Authentication information is possible. In TACACS+ it is standard to use the encryption, i.e. it is simple, but it is still optional. Just encryption of the body of the message is possible with TACACS+. In order for Diameter to be able to have end-to-end and hop-to-hop security the implementation of Diameter has to support the CMS Security application, if it does, it is easy to use the extra encryption otherwise you cannot encrypt the AVPs or check integrity of the AVPs. Encryption of the entire message is possible with Diameter.

1. 1. Comparison with respect to security mechanism supported

While the earlier version Kerberos v4 requires the use of DES (Data Encryption Standard) Kerberos v5 tags every cipher text with an encryption identifier so that any encryption technique may be used. With the Diameter application CMS Security one can use several symmetric and asymmetric encryption algorithms to encrypt the Diameter AVPs. COPS like Diameter uses the Cryptographic Message Syntax objects to provide Message integrity and confidentiality and the Encryption techniques used with the CMS is the same as those with Diameter. According to RFC 2865 and as stated above the RADIUS protocol just encrypts the authentication information. RADIUS does this by running the shared secret (between the NAS and the RADIUS server) followed by a Request Authenticator through a one way MD5 hashing algorithm to create a 16 bytes digest value which is then XOR-ed byte-wise with the user password. The encrypted password is then put in the user-password AVP which is sent with the Access-Request from the NAS to the RADIUS server in order to Authenticate the user. TACACS+ encrypts the body of a package with MD5, it does so by hashing the plain text in the packet header concatenated with a secret key to form a padding, which then is XOR-ed byte-wise with the packet body.

1. 1. Comparison in terms of type of transport protocol supported

Kerberos is according to RFC 1510, supporting UDP as well as TCP on port 88 as transport protocols. Kerberos is also using port 464 with both TCP and UDP to change/set passwords. According to RFC 2748, COPS uses a TCP connection between the PEP (responsible for initiating the connection) and a remote PDP, and at least one PDP implementation per server must listen on port 3288. RADIUS supports UDP on port 1812 and RADIUS Accounting runs on port 1813 of UDP according to RFC 2865. According to RFC 1492, TACACS+ runs on port 49 of TCP. The Diameter base protocol run on both TCP and SCTP transport protocols. Today the protocol run in port 1812 in order to test interoperability until IANA assigns the Diameter protocol a port. The Diameter clients must support either of TCP and SCTP (might be mandated to use SCTP in the future) while agents and servers must support both.

1. 1. Comparison in terms of market share in present context

Kerberos is one of the earliest developed Authentication protocols and is also one of the most widely used Authentication protocols on the market today considered just as an Authentication protocol. Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users. Useful in cases the users and servers are just interested in knowing who they are dealing with, for instance in a company or a school the personnel/students once authenticated might be authorized to use whatever resources they want and no accounting or resource usage information is to be collected. As an Authentication protocol Kerberos is one of the most widely used protocols in the market today and as it looks today like it will continue as that. But with the introduction of the AAA protocols it has been losing weight in areas where more services than just Authentication is wanted, since they can provide a larger usage area. The COPS protocol today exist as a policy provisioning protocol, but the use of COPS as a AAA protocol is nonexistent on the market today as it yet doesn't provide full AAA functionality, and it too as Diameter above has been submitted as a proposed standard. As a policy provisioning protocol COPS is enjoying a wide spread recognition on the market and is rapidly increasing its market shares. As an AAA protocol COPS hasn't received any real recognition yet but like as Diameter, it isn't completely finished, and there are still fairly large amount of work to be done before it complies with the NASREQ requirements. Both RADIUS and TACACS+ are used by service providers all over the world. The protocols are today mainly used to support dial-in access and to handle access through other connection like xDSLs. But as new services like Voice over IP and QoS is used the need for new AAA protocols increases. RADIUS is the largest and most widely used AAA protocol on the market today with the most users and developed implementations. For the most part its success depends on the easily managed implementations and that it has no propriety owner. As more and more service providers see the benefits of using an AAA protocol, RADIUS is increasing its market shares and usage around the world today. Almost every major remote-access vendor supports RADIUS today. Both RADIUS and TACACS+ are used by service providers all over the world. The protocols are today mainly used to support dial-in access and to handle access through other connection like xDSLs. But as new services like Voice over IP and QoS is used the need for new AAA protocols increases. The second most used AAA protocol today is TACACS+ and it, as RADIUS, benefits from the increasing AAA protocol usage on the market and are increasing regarding usage around the world but TACACS+ is little by little losing market shares in favour of RADIUS. Mainly this is because many both larger and smaller companies are appealed by an open standard like RADIUS instead of having to rely on a single vendor with propriety rights to the protocol. Of major remote-access protocols only every third seems to support Cisco's TACACS+. The Diameter protocol at the present just exists as a couple of drafts submitted to the AAA Work Group as to be proposed standard. There are also a couple of binary implementations of the protocol which can be found on the internet. Since the Diameter protocol is still under development there aren't any real fully working implementations out on the market but there exists a few free binary implementation which is downloadable on the Internet. Several major vendors do support the development and are implementing the Diameter protocol as it looks today.

1. 1. Comparison in terms of economical advantage

If one is just interested in Authentication Kerberos is probably in an economical advantage compared to the other protocols since it through its long existence and wide usage is well established and not too expensive compared to the AAA implementations. The source codes for several Kerberos implementations are free, but the possibility to buy a commercial Kerberos implementation so that you don't have to build the source code and get help with configuration is also available at different prices but considerably cheaper than the other AAA protocols Since COPS needs quite a bit of time and work to be done before it conforms to the NASREQ requirements, it's an economical disaster to try to change to COPS from any other protocol now. But if you are in the need of an policy provisioning protocol and chooses to use COPS as provisioning protocol then it might be an economical advantage to use as AAA protocol when it complies to the NASREQ requirements, since you only need to have one protocol. If one at the present aren't using an AAA protocol and are using some kind of implementations that are providing AAA functions one might want to start using an AAA protocol in order to provide the AAA functions, and one might get an economical advantage by considering using Diameter straight away since it is extendible and the need for an upgrade can be avoided. If one is using one of the present ordinary AAA protocols, RADIUS or TACACS+, one has to think about what needs one has. If you aren't in the need of an extendible protocol, or if the protocol you have works fine for the intended use and you don't see any immediate change of one's usage areas of the protocol, like with the adaptation to Mobile IP or Voice over IP, it would be an economical disadvantage to upgrade to Diameter. One of the things that are positive with the use of TACACS+ is the ability to separate the different AAA functions. If one today uses TACACS+ and doesn't need the functions of a Next generations AAA protocol, like Mobile IP functionality, it is an economical disadvantage to change to either RADIUS or Diameter. If one wants to be able to extend the uses of the AAA protocol Diameter might be the way to go.

1. Comparison with respect to support for real-time accounting

The Kerberos protocol isn't supporting Accounting at all. The RADIUS protocol supports real-time accounting as per RFC 2866. The diameter protocol supports real-time accounting as per its base protocol. COPS supports real-time accounting as per RFC 2748. TACACS+ supports real-time accounting as per TACACS+ specification. From the above comparisons, RADIUS and Diameter are in a good position for selection as a choice of future AAA protocol. Now analysis can be performed with RADIUS and Diameter for better choice in terms of criteria as below.

1. 1. Fail-Over

Fail-over is defined as the process of forwarding all the pending requests with an agent to another agent, once a transport failure with the first agent is detected. For this to be possible, it is, however, required that the nodes have agreed on failure support by setting up a flag in their Diameter messaging. RADIUS does not define a standard fail-over mechanism, and as a result, fail-over behavior can differ between RADIUS implementations. Diameter, on the other hand, is more resilient towards transport failures and provides a well-defined fail-over behavior. Diameter supports application layer acknowledgements and specific watchdog mechanisms to detect lack of activity. Diameter fail-over mechanisms are defined in [AAATR3539]. A pending message queue for every peer is maintained at a Diameter node. Upon receiving a response, the corresponding request is removed from the queue.

1. 1. Server initiated messages

Support of server-initiated messages is only optional in RADIUS [RAD3576] and this makes it difficult to implement features such as unsolicited disconnects or re-authentication/re-authorizations on demand across a heterogeneous deployment. Support for server-initiated messages is mandatory in Diameter. [RFC 3588]

1. 1. Reliable transport

Using UDP as a transport and lack of retransmission specifications in RADIUS makes reliability an issue for use of RADIUS for accounting: Packet loss may translate directly into revenue loss. Diameter runs over reliable transport mechanisms (TCP, SCTP) as described earlier.

1. 1. capability negotiation

The client and server have no way of indicating their support of various attributes to each other and RADIUS does not support error messages. This means performing capability discovery and negotiation to a mutually agreeable service may be very difficult with RADIUS. Diameter includes support for error handling, capability negotiation, as well as ways to indicate support of attribute-value pairs (through the mandatory flag).

1. 1. security and audibility issues

RADIUS defines an application-layer integrity protection (message authentication) scheme that is only required for Access Response packets. The authentication is based on shared secrets, but the trust is only established between neighbor hops and not end to end. Malicious proxies between client and server can modify attributes or even packet headers without being detected. Per packet confidentiality is not supported, only attributes can be hidden. RADIUS accounting protocol has replay protection issues. Support of IPSec is not required in RADIUS. Use of IPSec is only defined when RADIUS is used with IPv6. Even then, the use of IKE limits the usefulness of IPSec for various applications. Also not having the possibility of setting up a certificate hierarchy makes usage of RADIUS in roaming applications difficult where inter-domain AAA trust relationships are required. On the other hand, Diameter defines both transmission-level security and end-to-end security and requires mandatory support of IPSec and optional TLS support at the clients. However, data object security is not mandatory in Diameter.

1. 1. Diameter support for agents and inter-domain routing

RADIUS does not provide support for agents and proxies clearly. Since the expected behavior is not defined, it varies between implementations and interoperability problems may arise. Although the concept of RADIUS proxy chaining via intermediate servers is defined, due to lack explicit support for proxies and data object- and transmission-level security, RADIUS-based roaming is vulnerable to attacks and fraud, and as a result, it may cause problems for wide-scale deployment. Diameter defines the role of agents and proxies and their behavior explicitly. By providing explicit support for inter-domain roaming, message routing and transmission-layer security, Diameter addresses the RADIUS limitations.

1. 1. Peer discovery and configuration

RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden, and creates the temptation to reuse the RADIUS shared secret for many clients (NAS) and that can result in major security vulnerabilities Through DNS, Diameter enables dynamic discovery of peers. Derivation of dynamic session keys is enabled via transmission-level security. [ietf-draft]

1. 1. Backward compatibility with RADIUS

While Diameter does not share a common message format with RADIUS, considerable effort has been expended in enabling backward compatibility with RADIUS, so that the two protocols may be deployed in the same network. It is, however, expected that translations will need to take place through gateways enabling communication between legacy RADIUS devices and Diameter agents.

1. 1. Authorization without authentication

The Radius protocol does not support non-Authenticated Authorization, because the protocol does require some form of credentials in request messages. The Diameter protocol does not require Authentication information to be included in the request to the other peer. Authorization without Authentication is a requirement from the NASREQ Working Group to assert that dummy credentials doesn't have to be filled in according to RFC 3169, thus minimizing the processing burden on servers.

1. 1. PAP/Plain text password support

Even though PAP is an ill-suited protocol in today's networks, it is still in use in many applications. Therefore AAA protocols to be used in large scale roaming networks still need to securely transport plaintext passwords. And in order for an AAA protocol to securely transport plaintext passwords it has to provide confidentiality for the password and it also must protect the password against disclosure to proxies in forwarding paths. Since RADIUS only supports hop-by-hop security it can't prevent disclosure of the password to proxies, neither can it provide end-to-end confidentiality of the password. The Diameter protocol can by its CMS security application both provide the confidentiality as well as keep proxies from getting hold of the password as needed.

1. 1. Replay attacks and denial of service attacks

Since RADIUS doesn't contain end-to-end Authentication just hop-by-hop authentication, the protocol does not include any replay attack prevention. This means that a malfunctioning server or malicious user can replay old packets without detection. For example when Radius is used in a proxy chain this means that a malicious user or server through a proxy server can replay old access-request messages to an RADIUS server and get Access-Accept messages back and use this to get access to network resources. For servers that maintain state information, to limit the number of concurrent sessions for a user, this can be used against the RADIUS server to mount a denial of service attack simply by replaying old RADIUS messages. For servers not keeping state information another drawback with no replay prevention are that it can be used to send duplicate accounting messages, which might create economical disadvantages to the ISP. The Diameter protocol prevents replay protection through a timestamp mechanism and through the support of end-to-end Authentication.

1. 1. Mandatory Shared Secret

The RADIUS protocol requires that a shared secret exists between two peers. That this can be a problem and the magnitude of it can be realized when thinking of Mobile nodes roaming through different administrative domains since all Foreign Agents need a shared secret with the home agent, which require all Agents to have database containing unlimited amounts of shared secrets. The Diameter protocol does not require shared secrets.

1. 1. Radius Gateway Capability

Since RADIUS is the largest AAA protocol today, the next generations AAA protocols need to have RADIUS capabilities in order to ease migration and be able to interact with the major AAA agents today, which maybe neither needs nor wants to migrate to Next Generations AAA protocol. The Diameter protocol was engineered/created with RADIUS capabilities in mind, but with all the applications trying to comply with the different IETF Working Groups requirements on Next Generation AAA protocol and the changes of the RADIUS protocol, has resulted in that the Diameter protocol today doesn't completely satisfy backward capability. Obviously the RADIUS protocol support RADIUS gateway capabilities but with all the different implementations from different vendors it isn't certain that all RADIUS implementations are interoperable. It is safe to say though that the RADIUS protocol by nature is better at providing RADIUS gateway capability for authorization than Diameter.

1. 1. State-reconciliation

If an AAA protocol has State-Reconciliation capabilities it allows the clients to use the AAA server to manage Resource allocation state. State-Reconciliation allows the server to assist the clients with simultaneous user login control, limitations on port usage, tunnel limits and connection time. But in order for an AAA server to assist its clients with these tasks the AAA protocol must provide state recovery capabilities, in case data is lost due to fault of any reason, like at an AAA server reboot. And in order for AAA protocols to provide state recovery session/resource status and update and disconnect messages is needed. RADIUS doesn't provide an applicable command for any of the above needed messages as well as it has the issues with unsolicited messages. Diameter on the other hand through the former resource management application and now by the base protocol do support the messages needed for state recovery and therefore supports State-Reconciliation.

1. 1. Unsolicited disconnection

The Diameter base protocol defines a set of termination messages that can be used for unsolicited disconnects. The Diameter server sends a Session Termination Request to the client which then acknowledges the termination of the session. In comparison RADIUS in the newer RFCs of the protocol also includes a set of disconnect messages but the ability of unsolicited disconnect fails as the protocol fails to support unsolicited messages. The ability for servers to initiate a disconnect is useful when changes in the different authorization polices occurs at the servers.

1. 1. re-authorization on demand

It refers to the ability for a server or client to trigger re-Authorization. RADIUS is stated to support this feature by the Session-Timeout and Terminate-Action AVPs, but these AVPs just provide the ability to Re-Authorize periodically, and that can't be considered to be on demand. A RADIUS server doesn't have the ability to send unsolicited messages to the client so even on this point the RADIUS protocol fails to support this feature. Diameter on the other hand supports this feature through its session-based peer-to-peer relation between the "server" and "client".

1. support of unsolicited messages for accounting

Unsolicited messages are messages that are not a reply to an explicit request. The RADIUS protocol doesn't allow a server to send unsolicited messages to its clients (the NASes). As network services have become more complex, this limitation has forced implementers to deviate from the RADIUS protocol, causing interoperability problems. Since Diameter is a session based protocol (peer-to-peer) it supports unsolicited messages from the Diameter "server" (any direction from peer to peer) in traditional "server to client" sense. In comparison RADIUS does not support unsolicited messages since it is a client/server protocol that requires a client to initiate a request. Support of Unsolicited messages is typically needed for accounting purposes, to request that a NAS terminate a specific user session and to support of services where session/configuration information have to be changed during a session, like with mobile phone cards which have a credit limit.

Limitations of the study

The time constraint is the most limiting factor for covering lots of scopes in given time frame. It is not easy to collect the data regarding the cases of protocol implementation. Actual requirements are the real world needs while in implementation and may not be taken into account unless they are reported. They are collected from discussion forums and groups created for drafts and protocols. The comparisons and analysis are based on literatures only.

Conclusions

In the past time when there was no need for roaming and the concept of multiple access for services was not developed, primitive protocols for AAA function satisfied the purpose. With the growth of requirements for mobility and security, the present AAA protocols are found to be insufficient for future. From the comparisons and analysis, it is seen that Diameter has the capability of scalability and customization to be the generic access protocol for most of the network access scenarios.

References

• [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
• [AUTHSRV], Rescorla, E., "A Survey of Authentication Mechanisms", Internet Architecture Board (IAB), work in progress, draft-iab-auth-mech-02.txt, October 2003.
• [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
• [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
• [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
• [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
• [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006.
• [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006.
• [RFC4670] Nelson, D, "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
• [RFC4671] Nelson, D, "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006.
• [RFC4672] Nelson, D, "RADIUS Dynamic Authorization Client MIB", RFC 4672, August 2006.
• [RFC4673] Nelson, D, "RADIUS Dynamic Authorization Server MIB", RFC 4673, August 2006.
• [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
• [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176,
• [RADIUS2865], C. Rigney et al., "Remote Authentication Dial In User Service (RADIUS)", IETF Draft Standard, RFC 2865, June 2000.
• [RADACC2866], C. Rigney, "RADIUS Accounting", IETF Informational RFC, RFC 2866, June 2000.
• [RADEXT2869], C. Rigney, "RADIUS Extensions", IETF Information RFC, RFC 2869, June 2000.
• [RADTUN2868], G. Zorn et al., "RADIUS Attributes for Tunnel Protocol Support", IETF Informational RFC, RFC 2868, June 2000.
• [RADEAP3579], B. Aboba, and P. Calhoun, RADIUS (Remote Authentication Dial In User Service) Support for Extensible Authentication Protocol (EAP), RFC 3579, September 2003.
• [ROAMOPSWEB], Roaming Operations Working group website URL, https://www.ietf.org/html.charters/OLD/ roamops-charter.html, IETF WG, concluded January 2001.
• [PROX2607], B. Aboba, and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", IETF, RFC 2607, June 1999.
• [RADEXTWEB], IETF RADIUS extension working group, Web URL, https://ietf.org/html.charters/radextcharter. html.
• [RADIUSWEB], RADIUS working group website URL, https://www.ietf.org/html.charters/OLD/radiuscharter.html, IETF, concluded July 2000.
• [FREERADIUS], FreeRADIUS Server Project, https://www.freeradius.org/.
• [HASSELL], J. Hassell, "RADIUS", O'Reilly, ISBN 0-596-00322-6, 2003.
• [RAD3576], M. Chiba et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", IETF, RFC 3576, July 2003.
• [AAATR3539], B. Aboba, J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", IETF, RFC 3539, June 2003.
• [ietf-draft], https://www-nrc.nokia.com/sua/nsis/interim-2003/1.txt

Cite this page