UNIVERSAL AUTHENTICATION FRAMEWORK

Requirements and Phase Design

Jan Hajny, Tomas Pelka and Petra Lambertova

Department of Telecommunications, Brno University of Technology, Purkynova 118, Brno, Czech Republic

Keywords:

Authentication, Authorization, Accounting, AAA, Security, Protocol, Access, Control, Mobile, Networks.

Abstract:

The paper deals with the area of user Authentication, Authorization and Accounting (AAA) in computer

networks. The current state analysis together with main trend identiﬁcation is presented in the ﬁrst part. These

data are used as an argument for a statement about insufﬁcient ﬂexibility and security of nowadays solutions.

As a reaction we provide a Universal Authentication Framework which should solve these identiﬁed issues.

Our ambition is a good support of a wide range of devices – from mobile nodes like sensors, PDAs and mobiles

to work stations and servers. We chose a modular platform for this goal to obtain sufﬁcient ﬂexibility which

allows using any todays protocol together with possible future protocols. There is a basic structure description

and operation phase description in our paper. We also provide information about new protocol inclusion. This

paper also works as a starting document for further work and system implementation.

1 CURRENT STATE

The ﬁrst phase of our research mainly comprised cur-

rent state analysis in the ﬁeld of AAA (Authentica-

tion, Authorization and Accounting). The goal was

to ﬁnd out whether today’s solutions reﬂect a rapid

change in the computer network domain and eventu-

ally ﬁnd techniques or tools usable in a future authen-

tication framework. Our starting point was a pack of

more than 90 research papers and publications dealing

with AAA systems. We analyzed these papers to learn

overall image about directions in the present research.

These directions can be illustrated by the Figure 1.

Figure 1: AAA topic distribution.

It is obvious from the mentioned graph that re-

search groups are very often focused on mobile and

wireless networks (right after unclassiﬁable topics).

Many scientiﬁc publications discussed technologies

connected with consolidation of wireless computer

networks (like Wi-Fi) and mobile PLMN networks

(Public Land Mobile Network). Another ﬁnding is

that most of core techniques identiﬁed during our

study are well–established but quite old. There are

not many new ﬁndings in the AAA area and if there

are then they usually improve operational parameters

or data structures (Lee, 2007), (Jiann-Gwoand Cinhg-

Song, 2007). Simply by thinking only on parameters

of a new network and its efﬁciency the designers for-

get the security. They even simplify security proce-

dures to eliminate time delays or to support weaker

hardware devices. This activity has also an impact

on AAA services – we can see a transfer from the

4-way handshake to the 3-way one or a replacement

of PKI by simple challenge–response. Another dis-

cussed topic is a system modularity which is certainly

positive but only if it is not used to the prejudice of

security.

There are some positive ﬁndings too. We found

that there are still some fresh new authentication tech-

niques. We can give Password Based Authentica-

tion, Zero-knowledge Protocols, Multi-Party Compu-

tation or Threshold Authentication as good examples

although they are not very commonly used in modern

practical systems.

2 AAA PROTOCOLS

The most popular protocol analysis is made in this

chapter. We focus on a different service support and

Pelka T., Hajny J. and Lambertova P. (2009).

UNIVERSAL AUTHENTICATION FRAMEWORK - Requirements and Phase Design.

In Proceedings of the International Conference on Security and Cryptography, pages 57-60

DOI: 10.5220/0002178700570060

 SciTePress

on security. We also tried to identify common parts

of these protocols as well as different ones to get a

starting point for a universal framework design which

should support all these solutions.

2.1 RADIUS

RADIUS (Remote Access Dial In System) is the ﬁrst

analyzed protocol. It transfers authentication, autho-

rization and conﬁguration data among users. The en-

tities are client, NAS (Network Access Server, typi-

cally AP, switch, router...) and authentication server.

RADIUS is currently one of the most preferred solu-

tions when we need a protocol for a private network

access. It is supported by almost all devices working

on an edge of a network.

Security

The RADIUS server receives a username and pass-

word enciphered by XOR with a MD5 hash. This

hash is created by a MD5 function of shared pass-

word and random number. This number must be also

included to the message so the server can compute the

hash too.

Authentication

There are many possible authentication methods in

the RADIUS protocol. In addition to described meth-

ods we can use CHAP, UNIX login, EAP and oth-

ers. In the case of more complex methods like CHAP

there must be a challenge-response phase before the

ﬁrst ACCESS-Request message is sent. Authentica-

tion can also run straight between the user and au-

thentication server if we use EAP with tunnelling.

Accounting

There is a separate RFC for the RADIUS ac-

counting service. This means that accounting was

added to the original protocol by adding of more

messages (Accounting-Request and Accounting-

Response). These messages collect information

needed for billing/logging.

2.2 TACACS+

The TACACS+ protocol is another solution. It is

quite similar to RADIUS – at least by purpose. The

structure is very similar – there is a user who wants

to get inside a network and a TACACS+ client with

server. The main difference between TACACS+ and

RADIUS is the use of the TCP protocol instead of

UDP in case of RADIUS and a complete separation

of Authentication, Authorization and Accounting.

Security

The security is provided by a network packet encryp-

tion. TACACS+ uses the MD5 hash and the XOR

process which is the same as the RADIUS protocol

protection. A shared key is used as secret informa-

tion. (Rigney, 1997) (Network Sorcery, Inc., 1996)

Authentication

The authentication part uses a username and a pass-

word by default but other mechanisms are supported

too. The protocol is also ready for upcoming tech-

niques.

Accounting

A request-response mechanism is used for an ac-

counting service. A request is followed by client data

which can be used for billing, audit or monitoring.

2.3 Diameter

Diameter is the last interior protocol included to our

early framework design. It is a successor of the RA-

DIUS protocol. There is no default compatibility but

a compatibility patch exists. The main reason for its

creation is a wider network device support. Diame-

ter is especially focused on mobile devices to reﬂect

trends on a market. The most obvious differences

from RADIUS are:

• The usage of TCP or SCTP instead of UDP.

• IPSec or TLS is used for an encryption.

• There is a roaming support, error handling, user

sessions and direct accounting support.

Security

Security is provided by either TLS or IPSec. These

protocols are considered to be secure and robust

enough.

Authentication

Authentication is provided by a new AVP (basic data

unit) deﬁnition so the ﬂexibility is wide enough. EAP

can be used in a standard.

Accounting

Accounting is deﬁned by state diagrams similarly as

authorization. There are two scenarios – Client Ac-

counting and Server Stateless Accounting (Calhoun,

2003).

2.4 Protocol Comparison

We can ﬁnd many common properties of these proto-

cols (see Table 1, 2 and 3). Many authentication meth-

ods are common for more protocols but this does not

SECRYPT 2009 - International Conference on Security and Cryptography

necessarily mean that protocols are interchangeable.

Different protocols use different ways how to imple-

ment these methods.

Table 1: Protocol comparison – RADIUS.

RADIUS

Protocol UDP

Ports 1812 – Authentication,

Authorization

1813 – Accounting

Authentication Username/Password, EAP

Authorization After valid authentication,

authorization data are sent.

Accounting Separated - requests are logged

Security Shared secret + MD5

3 UNIVERSAL FRAMEWORK

We provided a brief AAA protocols analysis. We fo-

cused on most common solutions for border authen-

tication. It can be seen that there are many solutions

and the choice is usually based on the type of a net-

work and user properties. It’s also clear that there are

many common areas e.g. similar infrastructures or

authentication phases. Nevertheless some protocols

are much more suitable for some tasks in compari-

son with other. The main purpose of this chapter is to

provide some generalization and create a framework

design usable for a wide spectrum of clients with dif-

ferent demands. The design should work as a starting

point for further implementation tasks and more com-

plex structures.

3.1 AAA Framework Requirements

These criteria are set for the Universal Authentication

Framework:

• Security – the system must be secure. This means

that it must be built on well established solutions

which are regarded to be safe by a technical soci-

ety.

• Flexibility – the framework must support a wide

spectrum of devices from sensors to high end

servers. For all of these devices an appropriate

AAA service must be chosen. The service must

reﬂect device’s capabilities and needs.

• Modularity – the system must lively react on

changes in the area of AAA. The introduction of

a new technique must be easy.

• Efﬁciency – the framework must be efﬁcient in a

practical deployment so there can’t be any unnec-

essary overhead.

Table 2: Protocol comparison – TACACS+.

TACACS+

Protocol UDP/TCP

Ports 49

Authentication Username/Password, Kerberos

Authorization Completely separated.

Accounting Completely separated.

Security Shared secret + MD5

Table 3: Protocol comparison – Diameter.

Diameter

Protocol TCP/SCTP

Ports 3868

Authentication Username/Password, EAP

Authorization After valid authentication,

authorization data are sent.

Accounting Separated - requests are logged

Security IPSec, TLS

The Universal Authentication Framework (UAF) de-

sign was started with these criteria in mind. Current

established protocols were chosen as fundamentals

because of the security demand. Protocols like RA-

DIUS, Diameter, Kerberos or TACACS+ are consid-

ered to be secure enough to work as a core in the ﬁrst

stages of a design process. Another property comes

from the demand on efﬁciency. We decided to add

only necessary parts and that’s why AAA protocols

will not be encapsulated in different data packets but

will be used as they are. This will provide both efﬁ-

ciency and compatibility. These protocols will be run

as concrete instances of the framework right after the

protocol decision phase. That’s why we can distin-

guish 3 main stages of the framework:

1. Handshake – a primary communication between

the client and the server. The client speciﬁes a de-

manded service (all from AAA or just a part) and

other parameters used for a protocol decision. The

server then chooses appropriate protocol based on

this stage and informs the client about protocol

parameters (type, IP, port...)

2. Service execution – the client has all necessary in-

formation so the protocol can be executed. There

should be no difference from the normal run of the

protocol

3. Record – after the end of the protocol run there is

a record phase where data about this run are saved

in a server database. These data are later used in a

protocol decision.

3.2 Handshake

The ﬁrst stage of the framework is the most critical

one. The second and third stage is not difﬁcult to im-

UNIVERSAL AUTHENTICATION FRAMEWORK - Requirements and Phase Design

plement (protocols are already developed, a record is

trivial) but the ﬁrst one needs a deeper analysis be-

cause it is responsible for an authentication method

and connected services choice. We can talk basically

about a parametric system which decides about pro-

tocol/protocols based on input information. We can

model it by a system shown in a Figure 2.

Figure 2: Process of choice.

Information from the client or the server database re-

ceived during the handshake phase works as an input.

The protocol is chosen based on this information and

on information from the protocol information table.

Information from the handshake can be considered as

parameters of the system. The protocol choice pro-

cess works as follows:

• A new protocol inclusion – It is necessary to cre-

ate a new record in the protocol information ta-

ble. The authority must provide information about

proof factor (what is used for authentication), se-

curity, mobile devices support etc. so the system

is later able to do correct decision. This protocol

assessment is needed only during the new proto-

col inclusion.

• Parameters discovery – this is a part of the hand-

shake phase. As all server data are accessible from

the database the server needs only data sent by the

client.

• Protocol choice – the system analyze the agree-

ment between client demands and server sup-

ported protocols. Firstly protocols that does not

comply critical demands are rejected. The most

suitable protocol is chosen in the second phase. If

there is a need for more services than one proto-

col can support then more protocols are selected.

There is no need for more handshakes among

these protocols runs.

• Execution – the client gets information about the

choice so the service can be provided

We chose only basic protocols for this system by now.

The important fact is that there is a possibility to use

any authentication method in future. It is also easy

to reduce the use of a weak protocol by changes in a

protocol information table so it wont be used except

inevitable situations.

4 CONCLUSIONS

This paper is dealing with the AAA area and is fo-

cused mainly on user authentication. We did a cur-

rent state analysis in the ﬁrst part. Thanks to a deeper

examination we identiﬁed a need for a better sup-

port of new authentication techniques and easier in-

clusion of new systems. The Universal Authentica-

tion Framework was introduced as a reaction to these

ﬁndings. Our goal is to solve these problems and pro-

vide a solution based on better ﬂexibility and modu-

larity. The dependency on a concrete mechanism is

removed. The choice of an actual protocol is made

during the handshake stage from extendable set of

supported protocols. By this design we get a system

where always a most suitable protocol is used for ev-

ery type of client and where new and better methods

can be easily introduced. This also solves the prob-

lem of today’s networks where varied equipment with

very different capabilities and needs meet.

ACKNOWLEDGEMENTS

Sponsored under the National Program of Research

II by the Ministry of Education, Youth and Sports of

the Czech Republic in 2C08002 Project - KAAPS Re-

search of Universal and Complex Authentication and

Authorization for Permanent and Mobile Computer

Networks.

REFERENCES

Calhoun, P. (2003). Diameter base protocol.

Cao, X. and Li, H. (2006). Secure mobile ip registration

scheme with aaa from parings to reduce registration

delay. pages 1037–1042.

Hill, J. (2001). An analysis of the radius authentication pro-

tocol.

Jiann-Gwo, D. and Cinhg-Song, W. (2007). Secured op-

eration planning on service networks. ICICIC ’07:

Second International Conference on Innovative Com-

puting, Informatio and Control, pages 1–4.

Lee, J.-H. (2007). Architecture for mobile ipv6. pages

1246–1251.

Network Sorcery, Inc. (1996). Diameter.

Rigney, C. (1997). Authentication dial in user service (ra-

dius).

Rigney, C. (2000). Radius accounting.

SECRYPT 2009 - International Conference on Security and Cryptography