Requirements and Phase Design
Jan Hajny, Tomas Pelka and Petra Lambertova
Department of Telecommunications, Brno University of Technology, Purkynova 118, Brno, Czech Republic
Authentication, Authorization, Accounting, AAA, Security, Protocol, Access, Control, Mobile, Networks.
The paper deals with the area of user Authentication, Authorization and Accounting (AAA) in computer
networks. The current state analysis together with main trend identification is presented in the first part. These
data are used as an argument for a statement about insufficient flexibility and security of nowadays solutions.
As a reaction we provide a Universal Authentication Framework which should solve these identified 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 sufficient flexibility 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.
The first phase of our research mainly comprised cur-
rent state analysis in the field of AAA (Authentica-
tion, Authorization and Accounting). The goal was
to find out whether today’s solutions reflect a rapid
change in the computer network domain and eventu-
ally find 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 unclassifiable topics).
Many scientific publications discussed technologies
connected with consolidation of wireless computer
networks (like Wi-Fi) and mobile PLMN networks
(Public Land Mobile Network). Another finding is
that most of core techniques identified during our
study are well–established but quite old. There are
not many new findings 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 efficiency 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
There are some positive findings 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.
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).
In Proceedings of the International Conference on Security and Cryptography, pages 57-60
DOI: 10.5220/0002178700570060
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.
RADIUS (Remote Access Dial In System) is the first
analyzed protocol. It transfers authentication, autho-
rization and configuration 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.
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.
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
first ACCESS-Request message is sent. Authentica-
tion can also run straight between the user and au-
thentication server if we use EAP with tunnelling.
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.
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.
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)
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-
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 reflect
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 is provided by either TLS or IPSec. These
protocols are considered to be secure and robust
Authentication is provided by a new AVP (basic data
unit) definition so the flexibility is wide enough. EAP
can be used in a standard.
Accounting is defined by state diagrams similarly as
authorization. There are two scenarios Client Ac-
counting and Server Stateless Accounting (Calhoun,
2.4 Protocol Comparison
We can find 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.
Protocol UDP
Ports 1812 – Authentication,
1813 – Accounting
Authentication Username/Password, EAP
Authorization After valid authentication,
authorization data are sent.
Accounting Separated - requests are logged
Security Shared secret + MD5
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
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-
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
reflect 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.
Efficiency – the framework must be efficient in a
practical deployment so there can’t be any unnec-
essary overhead.
Table 2: Protocol comparison – 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.
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 first
stages of a design process. Another property comes
from the demand on efficiency. 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 effi-
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 specifies 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
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 first stage of the framework is the most critical
one. The second and third stage is not difficult to im-
plement (protocols are already developed, a record is
trivial) but the first 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
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.
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 first part. Thanks to a deeper
examination we identified 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
findings. Our goal is to solve these problems and pro-
vide a solution based on better flexibility 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.
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
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-
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
Network Sorcery, Inc. (1996). Diameter.
Rigney, C. (1997). Authentication dial in user service (ra-
Rigney, C. (2000). Radius accounting.
SECRYPT 2009 - International Conference on Security and Cryptography