Professional Documents
Culture Documents
Declaration
Herewith, I declare that I have written this thesis myself and no other sources than listed
in the references have been used.
Asma Alazeib
Stuttgart, 07.October.2005
An Ontology for Generic Wireless Authentication 2
Acknowledgements
I would like to thank first and foremost my supervisors in Alcatel SEL AG, Dr. Stephan
Rupp and Andreas Diehl for all their help, support, follow ups and encouragement. I
thank them for the weekly meetings held, for all the guidance and assistance and for all
the times they were there whenever I needed advice and support.
I would also like to thank Prof. Klaus Schünemann and Prof. Wolfgang Meyer for
supervising me at the Hamburg University of Technology during my master thesis and
for their help and support.
Special thanks also goes to Franz Josef Banet and Matthias Duspiva who were always
there to answer my questions, spent several hours clarifying my doubts, and whom
supported me throughout my thesis.
Never ending thanks also goes to the former Telematics group of Alcatel SEL AG, now
the mm-lab company for being my entrance point in Alcatel and for making the
company feel like home, for all the moral support, encouragement and for always being
there for me in every case. Special thanks go to Lothar Krank, Ronald Prestin, Martin
Geiger, Bernd Herrmann, Michael Meiser, Wolfgang Schäffer, Michael Koch, Horst
Idler, Gerald Sander, Claus Hirdes, Andreas Streit and Sandra Steege.
Warm wishes go to all my friends that I’ve encountered during my stay in Germany, each
person has made a positive influence in my life and in very special and different ways. I
thank them for the making me see life from other aspects and whom have greatly
contributed to the person I am today.
Last but not least, I would like to thank all my family members for believing in me and
for their encouragement.
An Ontology for Generic Wireless Authentication 3
Table of Contents
Declaration......................................................................................................................................1
Acknowledgements........................................................................................................................2
1 Introduction...............................................................................................................................10
1.1 Restructuring Telecommunication Networks...............................................................12
1.1.1 Physical Consolidation of Subscriber Data ...........................................................13
1.1.2 Logical Consolidation of Subscriber Data .............................................................13
1.1.3 Harmonization of Interfaces....................................................................................13
2 Authentication in Wireless Networks ....................................................................................16
2.1 Security in wireless networks...........................................................................................16
2.2 Introduction to Authentication.......................................................................................17
2.3 Introduction to GSM networks ......................................................................................18
2.3.1 GSM Network Components....................................................................................19
2.3.1.1 Radio Subsystem ................................................................................................19
2.3.1.2 Base Station Subsystem.....................................................................................19
2.3.1.3 Network and Switching Subsystem.................................................................20
2.3.2 Visited Access/Core Network, Operator Home Network .................................21
2.3.3 Numbers and Identities ............................................................................................21
2.3.3.1 International Mobile Subscriber Identity .......................................................21
2.3.3.2 Mobile Subscriber Integrated Services Digital Network Number..............22
2.4 Security in GSM Networks..............................................................................................24
2.4.1 GSM Authentication .................................................................................................24
2.4.2 Security Algorithms in GSM....................................................................................26
2.4.2.1 A3 Algorithm......................................................................................................26
2.4.2.2 A5 Algorithm......................................................................................................27
2.4.2.3 A8 Algorithm......................................................................................................27
2.5 Introduction to UMTS networks....................................................................................28
2.5.1 UMTS Network Components .................................................................................29
2.5.1.1 User Equipment.................................................................................................29
2.5.1.2 UMTS Terrestrial Radio Access Network .....................................................29
2.5.1.3 Core Network.....................................................................................................30
2.6 Security in UMTS networks.............................................................................................31
2.6.1 UMTS Authentication ..............................................................................................32
2.6.1.1 UMTS Authentication Vector..........................................................................34
An Ontology for Generic Wireless Authentication 4
Table of Figures
1 Introduction
The increase in network complexity in telecommunication systems has given rise to the
need of restructuring telecommunication networks.
Today networks are structured in such a way, that the introduction of new network
elements and network services significantly increase the complexity of networks for
network operators. Thus making it difficult to deploy and integrate new services and
domains into existing networks, as well as complicating the maintenance and
management of such networks.
Examples for telecommunication networks are mobile and wireless networks. The
original architecture for mobile networks was based on supporting the mobility of phone
calls. The extension of such networks and the difficulty of maintaining such extensions
were not put into consideration while designing these networks.
Today several network domains exist in mobile and wireless networks. Each domain
brings along with it new services, features and applications. And each domain requires
the introduction of new network elements, thus further contributing to the complexity of
networks.
Each network element requires its own independent set of services, applications and
subscriber data. As well as interfaces and protocols to communicate with each other.
Subscriber data is required for the new network elements existing within the network,
which is sometimes redundant across the different nodes. Each network node owns its
own subscriber profile (data), which is sometimes replicated and distributed across the
network. This complicates access to data and makes it impossible to obtain and maintain
a complete profile of a specific network subscriber, since all data related to a subscriber is
distributed along the network. Managing the network elements becomes difficult and
operating expenses involved for network planning and maintenance of such networks
also increases.
Another problem that arises from the current architecture of networks today is the
integration of several networks and domains (e.g. the integration of UMTS and WLAN
networks). The current architecture was not designed to support the integration of new
networks and services. The never-ending extensions of these networks will only make it
impossible in the future to maintain such networks.
An Ontology for Generic Wireless Authentication 11
The following points summarize the problems that arise from the way
telecommunication networks are structured today:
• Several domains
• Several network elements within each domain
• Inaccessible data due to vendor specific systems for the network elements
• Separate set of subscriber data for each network element
• Redundant subscriber data across the network elements
• Several protocols and interfaces to communicate between the nodes
• Increased complexity
• Increased expenses
The following figure illustrates the current status in telecommunication networks today:
Node 3
Node 1
Node 3
Node 1
Domain 2
Domain 1
Node 4 Node 2
Node 4 Node 2
Node 3 Node 3
Node 1 Node 1
Domain 4 Domain 3
For the purpose of this thesis the restructuring of the GSM, UMTS and WLAN domains
are considered. In particular the authentication specific data related to a certain
subscriber is modelled for the next generation profile register.
An Ontology for Generic Wireless Authentication 12
Next Generation Networks (NGNs) are introduced in this thesis as a solution to the
previously mentioned problems. The introduction of such networks reduces the
complexity of current networks, but only to a certain extent.
The concept behind a NGN is the separation of data from applications. Subscriber data
is one of the most vital components of a network, and in today’s networks this data is
not centrally accessible. Data today is not separated from the applications they belong to
and this data is locally stored, distributed and inaccessible by other applications. Such an
arrangement also causes the increase of operating and maintenance efforts and costs.
A NGN solves these problems by providing a common storage for subscriber data ,
which is accessible to all applications. This common profile store is also referred to as the
Next Generation Profile Register (NGPR). It simplifies data management and the
interfaces needed for applications to access the data; it also enables the re-use of data
among the various applications.
The following figure illustrates the distribution of subscriber data among the three
network domains:
Physical consolidation of data enables better data management, by storing data belonging
to a subscriber in dedicated data servers. Data is stored in one physical location and the
data servers can then be accessed via a common data interface. This process simplifies
the integration of new application servers and network management, enables faster
introduction of new services, and enables direct access to the data by different systems
and applications.
Logical consolidation of subscriber data provides a common data model that provides
meaning to subscriber data, and that describes this data. It solves the problem of the
multiple independent subscriber sets of a certain subscriber, which are distributed across
the network. It also associates subscriber data to the subscriber and provides the
definition of data objects. The logical model can be used in conjunction with a common
data interface.
The following figure illustrates the logical and physical consolidation of subscriber data
for the three mentioned domains:
An Ontology for Generic Wireless Authentication 14
Physical Consolidation
of Data
Relational models are not sufficient to describe the data for the logical model, the
Unified Modelling Language (UML) focuses on the operational properties and run time
data, the Extensible Markup Language (XML) and XML schema provide and define the
structure of data, the Resource Description Framework (RDF) and RDF Schema define
the data model for objects and the relationship between objects. It also provides a
terminology for expressing classes and properties. The appropriate method evaluated for
modelling the logical data was using the Semantic Web to provide meaning for the data.
The most suitable language evaluated for the description of the data was the Web
Ontology Language (OWL), which supports sharing and distribution of knowledge, a
richer vocabulary for modelling and which focuses on the structural properties of a
domain [49][52].
The thesis is organized in the following manner: this chapter provides an introduction to
the thesis and the motivation behind the work performed. Chapter two provides an
overview of GSM, UMTS and WLAN networks. The main focus of this chapter is the
An Ontology for Generic Wireless Authentication 15
authentication procedures for each network. Chapter three describes the Semantic Web,
ontologies (a knowledge based used to model the data), the Web Ontology Language and
the tools needed to model an ontology. Chapter four describes the ontology created with
the Protégé Tool. The ontology provides the definition of classes, the properties and the
relationships between the classes. Chapter five describes the installation requirements
needed to create the ontology, how the ontology can be loaded and a list of errors during
testing the consistency of the ontology. The summary of the work achieved, the
conclusions and open issues are described in Chapter 6.
An Ontology for Generic Wireless Authentication 16
Security has become an important issue in current mobile and wireless networks. As the
security measures for such networks increase, the tools and techniques used to attack
such networks also increases.
Wireless communications security in simple terms, is the procedures or methods used for
protecting the communication between certain entities. (An entity could be a user or a
device requesting network access). Protection mechanisms are used to protect the entity
from any third party attacks, such as impersonating an identity, revealing a specific
identity, data-hijacking or data modification, eavesdropping and so forth.
Dedicated technologies for securing data and communication are required in wireless
networks, which vary according to the type of wireless technology deployed. Security in
mobile and wireless networks covers various issues, from authentication of a user
accessing a certain network, to data encryption and data integrity. Thus three major
aspects are considered in securing wireless networks: [5]
• Access control (Authentication)
• Confidentiality
• Anonymity [5]
Encryption is used to ensure the confidentiality of data. Data integrity guarantees that
the data is not modified or destroyed in any way, thus sensitive signalling information
and data are protected against eavesdropping attacks.
Anonymity is another security aspect that protects user identity, making it hard to track
the whereabouts of a certain user. Anonymity is achieved using temporary identities [6].
An Ontology for Generic Wireless Authentication 17
The scope of this thesis only addresses the authentication procedures of mobile and
wireless networks, specifically GSM, UMTS and WLAN networks. Other security aspects
are not within this scope.
The kind of access and services granted depends on the privileges given to the specific
entity requesting authentication. In the case the identity is not proven (unsuccessful
authentication), no access is granted to the entity requesting access.
The simple form of authentication is providing a user name and password, which is
mainly the case in internet based authentication (e.g. email, online shopping, etc…) and
in some wireless based networks. However, different types of authentication exist
depending on the complexity of a certain system. Dedicated systems require a complex
procedure of authentication involving the use of secret keys, tokens, certain credentials,
digital certificates or signatures, complex algorithms and encryption methods and more
[7] [8].
Several authentication methods exist, depending on the technology used and the type of
information or services requiring access.
In the following, the authentication procedures of GSM, UMTS and WLAN networks
are discussed in detail.
An Ontology for Generic Wireless Authentication 18
The Global System for Mobile Communication (GSM) is a second generation (2G)
network and is the largest existing 2G network. Second generation refers to the fact that
the system uses digital signals in contrast to first generation networks, where analogue
signals were used [5].
The GSM network comprises of several network components that interact and function
with each other. For the purpose of this thesis, only the components involved in the
authentication process of GSM networks will be described and illustrated.
The following figure illustrates a general overview of the GSM authentication specific
network architecture. (All other elements not related to authentication are not illustrated
or addressed):
RSS NSS
BSS
BTS
HLR AuC
MS BSC MSC VLR
Mobile Device Visited Access Network Visited Core Network Home Network
The GSM network comprises of three subsystems, namely the Radio Subsystem (RSS),
the Network and Switching Subsystem (NSS) and the Operation Subsystem (OSS) [1] [4].
The OSS is not discussed in this thesis.
An Ontology for Generic Wireless Authentication 19
The RSS [9] [4] deals with all the radio aspects of a network and is responsible for the
following components it comprises:
The Mobile Station (MS) [3] [4] consists of two major components:
The Mobile Equipment (ME) is the actual mobile device a user uses to establish calls and
other telephony services. The ME communicates with the radio channel and provides
various services to the user of the mobile device.
The Subscriber Identity Module (SIM) [3] is located inside the ME and contains
subscriber specific data. This data is used for identifying a subscriber to the network via
the International Mobile Subscriber Identity (IMSI). Authentication specific data is also
stored inside the SIM (e.g. algorithms, secret key), which are later used for key generation
[4] [6].
Two security services are implemented for the SIM card. The first security mechanism
for the SIM is access control, which controls a user from accessing the card and the
information and services provided upon card access. This is provided via a secret
Personal Identification Number (PIN), which the user has to enter before gaining access
to the SIM. The second security mechanism provided is the network challenge and
response mechanism described in section (2.4.1).
The Base Station Subsystem (BSS) [1] [3] [4] is responsible for all radio functions and
comprises of the Base Station Transceiver (BTS) and the Base Station Controller (BSC).
These two components together support the radio interface. The responsibilities of the
BSS are then assigned to the following two components:
An Ontology for Generic Wireless Authentication 20
The Base Transceiver Station (BTS) takes care of the communication with the mobile
station, and is responsible for radio specific functions (sending and receiving) [4]
The Base Station Controller (BSC) is responsible for the switching between several BTSs,
and for the switching of radio channels. The BSC provides the necessary control
functions and physical links between the Network Subsystem (NSS), via the Mobile
Switching Center (MSC) and the BTS [1] [3] [4].
The NSS [3][4] comprises of the Mobile Switching Center (MSC), the Home Location
Register (HLR) and the Visitor Location Register (VLR). The NSS provides switching
services between GSM and external networks, and maintains the location registers
needed to manage and administer subscribers.
The Mobile Switching Center (MSC) is the switching node in the NSS that controls all
MS connections. It provides telephony switching services to fixed and mobile networks.
It links the NSS to the RSS via the BSC. Several BSCs can belong to a single MSC [1] [3]
[4].
The Home Location Register (HLR) is the main subscriber profile register, and contains
all data related to a mobile subscriber. This data includes but is not limited to the
following: the mobile subscriber’s identity, represented as the International Mobile
Subscriber Identity (IMSI) (also stored in the SIM card), administrational information,
service subscription and service specific data and location information [1] [2] [3] [4].
outside their home network. Certain administrational data is replicated in the VLR from
the HLR in order to provide service provisioning and call control. Information about the
visiting subscriber is retrieved from the HLR and stored in the VLR as a temporary
record [1] [2] [3] [4].
The Authentication Center (AuC) is a register that is logically part of the HLR.
Authentication specific data for a given subscriber is stored in the AuC. It is responsible
for storing the secret key of a subscriber (section 2.4.1). Other tasks of the AuC include
the generation of authentication parameters needed for authentication and encryption,
proving the identity of a subscriber and providing protection mechanisms for a
subscriber’s SIM card [1] [3] [4].
The Visited Access Network is the radio network accessed by the mobile station. Access
is accomplished via the BSS.
The Visited Core Network is the switching part of the network, and is a network other
than the home network the subscriber is registered at. Visited Core Networks can be
located at various national or international locations. The MSC and VLR reside at this
network [6].
The Operator Home Network is the original network the mobile subscriber is registered
at. The HLR and AuC reside in this network.
The International Mobile Subscriber Identity (IMSI) is a unique 15 digit identifier for a
mobile subscriber. It is stored in the SIM card of the mobile station, and is assigned to a
mobile subscriber at the time of subscription. It is used to identify a subscriber to a given
network (i.e. GSM, UMTS networks). The main purpose of the IMSI is to allocate
International Mobile Station Identities (INMSI) to stations. Mobile subscribers do not
have access to this number or have any knowledge of it. Although this number is stored
in the SIM card, it cannot be reached via a telephone call. Thus, the number is not made
public.
An Ontology for Generic Wireless Authentication 22
o HLR-Number
The Mobile Country Code is a three digit code, specifying a list of predefined mobile
country codes that identify a mobile station in mobile networks. The MCC for Germany,
for example is 262 and each country has its own respective MCC.
The Mobile Network Code is the code, which identifies the home network of the mobile
subscriber. E.g. in Germany the codes 01, 02 and 03 are used to identify the T-Mobile,
Vodafone and E-Plus networks respectively. This code is 2 digits in Europe and 3 in
North America.
The Mobile Subscriber Integrated Services Digital Network Number (MSISDN) is the
mobile subscriber’s telephone number, which is associated with the IMSI. Several
MSISDN numbers can be assigned to a single IMSI and are also stored on the SIM card.
Together the IMSI and MSISDN are used for call setup and call routing.
o HLR-Number (HLR#)
The CC is consists of 1 – 3 digits and represents the code for the country. The NDC is
consists of 2 – 3 digits and indicates the type of telephone number being called. In the
case of mobile networks it indicates the code for the specific operator, E.g. 179 for the
O2 network operator. The CC and the NDC together are used of routing purposes.
The SN is a 10 digit number and consists of two parts; the HLR number representing the
logical address of the HLR and the ISN, which is a number assigned to the subscriber [2]
[10] [12].
An Ontology for Generic Wireless Authentication 24
As described in section 1.1, the security issue covers three main aspects:
• Authentication
• Confidentiality
• Anonymity
A new mobile subscriber is given a SIM card, in which relevant information about a
subscriber is stored. The SIM card contains the necessary keys and algorithms needed for
the authentication procedure, which enables a subscriber to connect to the home
network.
A secret key referred to as Ki is stored in the SIM card of the mobile subscriber, and in
the Authentication Center of the home network of the mobile operator. This key remains
secret and is never transmitted from the AuC or SIM card. The Ki is a unique 128-bit
key. The whole authentication procedure depends on the privacy/secrecy of this key.
The concept behind the challenge-response type of authentication is to prove that the
secret key, stored in the SIM card of the mobile station is the same as the key stored in
the AuC.
The authentication procedure begins when a mobile station, requests access to the
network. This is achieved via an authentication request, in which the mobile device sends
out the IMSI as a request for authentication. The IMSI is broadcasted to a corresponding
MSC, which in turn forwards this information to the HLR in the home network, and also
the VLR in the visited network.
The AuC is associated with the HLR, and is responsible for storing authentication
specific parameters. After the reception of the IMSI by the AuC, a random number
(RAND) is generated using the received IMSI and the stored secret key Ki. The RAND
number is a 128-bit key, and represents the challenge to be sent to the SIM by the home
network.
The AuC and SIM card contain authentication algorithms, namely the A3 algorithm for
authentication and the A8 algorithm for key generation (explained in section 1.4.1). With
the help of these algorithms an Expected Response key (XRES), which is 32-bits long,
and a Cipher key (Kc), 64-bits long are generated.
An Ontology for Generic Wireless Authentication 26
The XRES is used to verify if the SIM can generate the same response, and is based on a
symmetric mechanism. The Kc is used for encrypting calls between the mobile and base
stations, and is a temporary session key.
Upon generating these keys, the HLR sends out an authentication response known as
triplets, which consists of the (RAND, XRES and Kc). The triplets are generated and
stored in the VLR for each subscriber. The MSC then forwards the RAND number of
the generated triplets to the mobile station. This RAND number is sent as a challenge to
the mobile station, and challenges the mobile station to calculate the same response
generated by the AuC.
With the use of the A3 and A8 algorithms, the RAND number and Ki key are used to
calculate the RES and a Kc. The RES is then forwarded to the MSC/VLR, and a
comparison of RES and XRES is made. If both responses match, the authentication
procedure is successful and the mobile station gains access to the network and its
services. If, however the XRES and RES don’t match, then access is denied to the
mobile station and the authentication procedure fails [5] [6] [15].
2.4.2.1 A3 Algorithm
The A3 algorithm is the authentication algorithm for GSM networks, and resides on the
SIM card of the mobile subscriber, and on the HLR/AuC of the home network. The
implementation of the A3 algorithm is network specific and depends on the network
operator.
The A3 algorithm is a non-recursive algorithm, meaning that the output generated from
the input cannot be used to derive or guess the inputs. Thus, the output gives no
indication about the input. The main purpose of this algorithm is to authenticate the
identity of a mobile subscriber.
An Ontology for Generic Wireless Authentication 27
The A3 algorithm generates the XRES on the network side and the RES on the mobile
side. Both the XRES and RES are a 32-bit long key and are generated from Ki and
RAND [13] [14] [15].
2.4.2.2 A5 Algorithm
The Kc ensures that all calls are encrypted between the MS and the BSS. The A5
algorithm is a standardized algorithm, but this algorithm can only be obtained with a
specific license from the GSM Association [5]. Although the A5 algorithm is
standardized, its specification remains undisclosed [5] [13] [14] [15].
2.4.2.3 A8 Algorithm
The A8 algorithm is the ciphering key generation algorithm, as with the A3 algorithm it
also resides on the SIM card and HLR/AuC. Its implementation is network specific and
it is also a non-recursive algorithm.
The A8 algorithm is used for generating the Kc, which is a session key and is used for
encrypting voice and data traffic. The Kc is generated from the Ki and RAND and is 64-
bits long [13] [14] [15].
An Ontology for Generic Wireless Authentication 28
The Universal Mobile Telecommunications System (UMTS) is one of the new third
generation (3G) networks. 3G networks build on 2G networks with the General Packet
Radio Service (GPRS) support, which are known as 2.5G networks. 2.5G networks
support packet switching domains. A UMTS network also provides for inter-operability
with a GSM network and is an extension of existing GSM networks [18].
UMTS networks support the circuit and packet switched domains, and are backward
interoperable with GSM/GPRS networks [5][18] [19].
UMTS networks provide enhanced data transmission rates and a wider range of services,
including multimedia and IP based services [5] [6] [16].
The following figure illustrates the UMTS network architecture, (only components
related to authentication are illustrated):
BTS
BSS
HLR AuC
Node B
UE RNC 3G SGSN
RNS
Mobile Device Visited Access Network Visited Core Network Home Network
The UMTS network consists of the following components: [16] [17] [18]
The UE consists of the mobile device and the Universal Subscriber Identity Module
(USIM) card. The UE separates between the user device functionality and the USIM
functionality [16].
The USIM is similar in functionality to the SIM of the GSM network. The USIM is more
enhanced in terms of security. The keys and algorithms used for authentication and
encryption are stored on the USIM. Subscriber specific data and several identities are also
stored on the USIM [15].
The UTRAN is the new access network for UMTS networks, which uses different
multiple access methods than previous GSM networks [17]. It is responsible for network
access procedures, mobility and resource allocation [4].
UTRAN is subdivided into individual Radio Network Subsystems (RNS), which consists
of the following components [16] [17]:
The RNC is the controlling unit of the UTRAN and is responsible for communicating
with the UE. It performs radio specific functions and maintains the connection to the
CN for each UE. It functions like the BSC of GSM networks, and provides switching
functions between other RNCs [16]. The RNC is connected to one or several Node Bs
[17].
Two types of RNCs exist, namely Serving Radio Network Controllers (SRNC) and
Drifting Radio Network Controllers (DRNC) [4] [18]. The SRNC is responsible for
An Ontology for Generic Wireless Authentication 30
controlling the connection to the CN, while the DRNC is responsible for the connection
to the UE and offers additional resources [4] [18].
2.5.1.2.2 Node B
Node-Bs are the base stations of the UMTS network, and several Node-Bs can be
connected to one RNC. Each Node-B can serve one or several radio cells. A Node-B
fulfils almost the same functionalities as a BTS in GSM networks [16]. A Node B is
mainly responsible for the transmission and reception of data [17].
The CN consists of two domains: the Circuit Switched (CS) domain, and the Packet
Switched domain (PS). The CN in UMTS is an enhanced version of the GSM core
network with GPRS.
Each domain has its specific components. The CS domain includes the MSC and VLR as
its components, and provides circuit switched functionalities such as calls and switching
of calls. The PS domain includes the 3G Serving GPRS Support Node (SGSN) as its
component, which is responsible for the delivery of data packets to and from the UE.
The SGSN takes the role of the MSC/VLR of the CS domain. The PS domain provides
IP-Based services. Components like the HLR and AuC are shared by both CS and PS
domains [17] [18].
An Ontology for Generic Wireless Authentication 31
Security in UMTS networks is based and built on the existing GSM security mechanisms.
However, UMTS has far more security mechanisms than in GSM, and is more enhanced
in terms of security [6].
Robust security mechanisms of GSM networks have been adopted into UMTS networks.
Compatibility with GSM networks is ensured in order to ease inter-working operations
between the networks [21].
New security services have been introduced into UMTS networks as well as new
domains. This required the introduction of new security mechanisms [5].
• Secure Services and Applications; enhanced security features for services and
applications [21].
IMSI IMSI
Authentication Request Authentication Request
UE
MSC VLR SGSN
HLR AuC
USIM
(Quintets)
RAND, AUTN,
RAND, AUTN XRES, CK, IK
Authentication Response
RES SQN CK IK RES XRES AUTN CK IK
RES = XRES
UMTS authentication provides mutual authentication [5] [6], meaning that the network a
certain subscriber is connecting to is authenticated. Details about the exact mutual
authentication procedure are described below.
• The IMSI.
These identities are also used in 2G GSM networks, apart from the P-TMSI, which is
used in 2.5G networks.
A permanent secret key (K) – 128 bits - resides in the USIM of the UE and in the AuC
of the home network. As with GSM authentication, this key is never transmitted and is
always kept secret.
The user’s identity is verified by the Serving Network (SN) or the visited core network.
Access to the network is granted by the SN if the verification procedure is successful.
The SN forwards the authentication request (IMSI) to the HLR/AuC of the Home
Network (HN). An authentication vector, called (Quintets) is generated as the
authentication response and is returned back to the SN. Using the IMSI, the AuC then
generates a Random Number (RAND) – 128 bits – and a Sequence Number (SQN) – 48
bits. This SQN is chosen in ascending order in order to later check the freshness of the
SQN, and thus the freshness of the generated authentication vector sent to the USIM.
The SQN and RAND number are then used, with the help of the f1, f2, f3, f4 and f5
functions/algorithms to generate the authentication vector. These functions are all non-
recursive, and it is important to note that the output of one function cannot reveal any
information about the input of another function [5].
The inputs for the authentication vector are the RAND, SQN and K, which is stored in
the AuC. The authentication vector consists of the following keys: the Expected
Response (XRES) generated using the f2 function and is 32 – 128 bits; the Cipher Key
(CK) generated using the f3 function and is 128 bits; the Integrity Key (IK) generated
using the f4 function an is 128 bits; the Authentication Token (AUTN), which is a
concatenation of different keys (explained below) and is 128 bits.
The authentication procedure on the USIM starts upon the reception of RAND and
AUTN. The importance of sending these two keys is for the mutual authentication
process. The AUTN can only be computed by the AuC of the home network. Therefore,
the UE is able to verify that it is connecting to a trusted network; a network that holds
the same secret as the USIM (i.e. K) [19].
The RES is then forwarded to the SN, and is evaluated against the XRES response
received from the Home Network. If both responses match then the UE is authenticated
to access the network [5] [6] [19].
The following figure illustrates the authentication vector generated in the AuC. It is
important to understand this authentication vector, in order to understand how UMTS
performs mutual authentication. Up till now, only the UE has been authenticated to use
the network, the second step of authentication is performed on the USIM side, where the
UE checks whether it is connecting to a trusted network or not.
The generation of the authentication vector on the home network side begins with the
reception of the IMSI (authentication request) from the UE. A fresh SQN and a RAND
number are generated. SQN proves to the USIM that the generated authentication vector
An Ontology for Generic Wireless Authentication 35
is fresh. Five one way functions (f1, f2, f3, f4 and f5) [5] are used for generating the
authentication vector.
The f3, f4 and f5 functions are key generating functions, which all take the RAND and K
as inputs. The f2 function generates the XRES, and is used to compare the RES
generated on the USIM side for subscriber authentication. The f3 and f4 functions
generate the CK and IK keys respectively for ciphering and integrity protection purposes
on the air interface. The f5 function generates an Anonymity Key (AK) 48 bit, which is
used to conceal the generated sequence number SQN [5] [19].
An Ontology for Generic Wireless Authentication 36
The following figure illustrates the authentication procedure on the USIM of the UE:
USIM
K
RAND
f5 f2 f3 f4
AK RES CK IK
SQN
SQN + AK +
f1
AMF
AUTN
XMAC
MAC ?
MAC = XMAC
Figure 11: USIM Authentication
The functions f1 – f5 are ordered in a different manner on the USIM as compared with
the functions on the AuC. In USIM authentication the f5 function must generate outputs
before the f1 function. The authentication procedure starts with the computation of the
Anonymity Key (AK). This key is generated from the inputs of RAND and K using the
f5 function, which is used to conceal the SQN preventing any leakage of user identity
through the SQN.
The functions f2, f3 and f4 take the RAND and K as inputs and generate RES, CK and
IK respectively. The input of the f1 function is a bit more complicated; two keys from
the AUTN namely SQN and AK are concatenated with the AK, which is generated from
the f5 function in the following manner: SQN = (SQN ⊕ AK) ⊕ AK [19]. This SQN is
then an input for the f1 function along with the AMF key. The f1 function generates the
Expected MAC (XMAC) a 64 bit key as its output. This value (XMAC) is compared to
the MAC of the AUTN key, which is a concatenation of the SQN, AK, AMF and MAC
An Ontology for Generic Wireless Authentication 37
in the following way: AUTN = SQN ⊕ AK || AMF || MAC [19]. If both MACs
match, authentication of the network is completed and the USIM verifies that it is
connected to a trusted network [5] [19].
The main algorithms in UMTS networks concerned with authentication are the f1, f1*,
f2, f3, f4, f5 and f5* functions. These functions are operator-specific and only reside on
the AuC of the home network and the USIM of the UE.
Each of these functions is a one-way function. The functions are used for computing the
authentication vector. The importance of these functions lies in that the output of one
function cannot reveal any information about the other functions [5].
The f1 function is the network authentication function and is responsible for the
generation of the MAC key on the network side and the XMAC key on the USIM side.
The f1* function is the resynchronization message authentication function and is used
for resynchronization purposes.
The f2 function is the user authentication function and is responsible for the generation
of the XRES key on the network side and the RES key on the USIM side.
The f3 function is the CK derivation function. It generates the CK on both the network
and USIM side.
The f4 function is the IK derivation function. It generates the IK on both the network
and USIM side.
The f5* function is the AK derivation function for resynchronization and is used for
resynchronization purposes [5] [6].
An Ontology for Generic Wireless Authentication 38
The IMS is an application layer, residing on top of the packet switched domain of the
UMTS network. It is independent of the access network, and supports various types of
networks and devices [5]. The main intention of the IMS is to provide multimedia
services and applications to end users. IMS also supports roaming services for mobile
networks [5] [23]. A multimedia service is a service that supports two or more kinds of
multimedia services for telecommunication networks. Services can be for example, video
and audio downloading and streaming, text messaging, web browsing, etc… [22]
The following figure illustrates an overview of the IMS system architecture in mobile and
fixed networks:
Core Network
PLMN / PSTN /
GMSC ISDN
Home IMS
BTS
MS
BSC
BSS MSC VLR
HSS
UTRAN
I-CSCF S-CSCF
Node B
P-CSCF
UE RNC SGSN
RNS Visited IMS
GGSN
Fixed Access
Networks /
WLAN
• Gateway GRPS Support Node (GGSN); also supported in UMTS and 2.5G
networks [22].
The HSS is the main database of the IMS network. The HLR and AuC are integrated
into this database, and subscriber specific, location-related data and user identities are is
stored in this database.
The CSCF consists of three types that perform different functions within the network:
The P-CSCF is the first contact point in the IMS. It is responsible for forwarding
registration requests and responses, to and from the mobile device and the I-CSCF. The
P-CSCF resides in the visited network, and is assigned to a terminal supporting IP
Multimedia (E.g. mobile phone, laptop, computer, etc…). It is also responsible for the
confidentiality and integrity of messages sent in the network.
The I-CSCF is responsible for contacting the respective S-CSCF within the home
network via the HSS. Its main task is the assignment of an S-CSCF, routing, and
forwarding of requests and responses to the relevant S-CSCF.
The S-CSCF is responsible for session control and session management. In addition,
authentication and subscriber specific data are stored in the S-CSCF, which are retrieved
from the HSS. The S-CSCF is assigned to an IMS terminal, and performs the
authentication of an IMS user. Registration requests received by the S-CSCF are
forwarded to the HSS [5] [22] [23].
The I-CSCF and S-CSCF reside in the home network of the IMS.
The GGSN is a gateway between the IMS and UMTS networks, and represents the
entrance point to the IMS system.
The IMS supports the access of other networks like; Fixed Access Networks, Wireless
Local Area Networks (WLAN), Public Land Mobile Networks (PLMN), Public Switched
Telephone Networks (PSTN) and Integrated Services Digital Networks (ISDN). The
An Ontology for Generic Wireless Authentication 40
latter three can be accessed by GSM networks via, the Gateway Mobile Switching Center
(GMSC) [23].
Authentication in the IMS is performed, via the IMS Authentication and Key Agreement
(AKA) mechanism, which is a challenge/response type of authentication and which is
analogous to UMTS authentication. The IMS uses the IMS Subscriber Identity Module
(ISIM), in the UE instead of the USIM and SIM in UMTS and GSM networks
respectively [5].
Several identities exist in the IMS system, which are used to uniquely identify a user or a
service of the IMS system. These identities are; Public User Identities, Private User
Identities and Public Service Identities and are briefly described in the following:
Every user of an IMS system has one private user identity, used to identify the user of the
IMS system. This identity is assigned by the home network, and it takes the form of a
Network Access Identifier (NAI). An NAI is a standardized way to identify users to a
network during authentication via a username or a username@realm. Private user
identities are static, and are used to identify information related to a specific subscriber
(subscriber and authentication information), which is stored in the HSS. Apart from the
private user identity being stored in the HSS, it is also stored in the ISIM of the UE and
also in the S-CSCF. The private user identity takes a similar function as that of the IMSI
in GSM and UMTS networks. The private user identity is authenticated during user
registration [23] [24] [25].
One or more public user identities can be allocated to a user of an IMS system. A user
should obtain at least one public user identity, which is also stored in the ISIM. This
identifier is used for communication purposes with other IMS users. It is also used by
external users to address a user. The public user identity takes the form of a
telephone:URL number or a URL. Public user identities are used to identify information
related to a specific subscriber within the HSS, but unlike private user identities, public
user identities are not authenticated by the network. IMS terminals are tied to public user
identities by the S-CSCF [24] [25].
An Ontology for Generic Wireless Authentication 41
Private and public user identities are used to identify users within an IMS system.
However, public service identities are used for identifying the various services available to
the IMS via application servers. Each public service identity is bound to a service of the
IMS [24].
An Ontology for Generic Wireless Authentication 42
A WLAN is a local area network that does not use wires to communicate between the
stations, instead high frequency radio waves are used for communication. An example of
WLAN networks is the 802.11 standard defined by the IEEE [26].
Wireless Station 1
Target Network
Access Point
Wireless Station 2
The main components involved in a WLAN network are the mobile station, which could
be any mobile device (E.g. a laptop, Personal Digital Assistant (PDA)), the wireless
Access Point (AP) that performs the task of a wired hub – the AP acts as an entry point
to access the target network- , and some kind of authentication server performing,
authentication and granting access to the network via the AP [8].
In the following the WLAN security architecture will be explained along with concepts
relating to WLAN authentication.
An Ontology for Generic Wireless Authentication 43
2.9.1 802.11
The 802.11 is a standard developed by the IEEE for wireless networks. The specification
defines the interface between a wireless station, and an access point or another wireless
station. The 802.11 also specifies how access to a WLAN is achieved or in other words
how authentication of WLANs is implemented. Authentication in 802.11 networks is
based on authenticating a wireless station rather than a user [29].
In order for a wireless station to connect to another station or access point, the initiating
station must prove its identity, to the receiving wireless station or access point. This is
achieved via various authentication methods, which depend on the type of authentication
method deployed.
The 802.11 is a family of standards, and several specifications of this standard exist,.
Amongst these are; 802.11, 802.11a, 802.11b, 802.11g. Each specification differs from
the other in the spectrums/multiplexing methods, transmission rates and bandwidths
[27].
The Wired Equivalent Privacy (WEP) key is used, between a wireless client, and an AP,
in order to encrypt data being sent from the client to the AP, and to decrypt the same
data on the AP. It is a standard defined by the IEEE 802.11 Working Group for data
encryption. WEP keys are static keys, and are used as session keys, to enable
communication of the client and the AP. If the client is not able to detect the AP’s WEP
key, access to the network is blocked from the client. As the name implies, WEP was
developed to be as secure as that of wired networks that is why it is termed as equivalent.
This fact does not hold, since many flaws have been detected in this encryption scheme.
Wi-Fi Protected Access (WPA) is an enhancement over the vulnerable WEP encryption
scheme. All flaws in WEP have been addressed in WPA. WPA provides authentication,
key management and encryption mechanisms, to secure a wireless network [31].
Unlike GSM and UMTS networks, security in WLAN networks is not standardized.
WLANS are implementation specific, and depend on the technology deployed and
chosen on the wireless devices and access points. Another issue to put into consideration
when securing wireless networks is, how secure the network should be, and what are the
costs of implementing such security, these factors influence the type of security
mechanisms deployed.
The following figure illustrates the general security architecture for a WLAN:
2.10.1 802.1X
The 802.1X is an essential element in securing WLAN networks. It is a standard from the
IEEE, and is used for port-based network access control. Authentication of wireless
stations (e.g. laptop, access point) is performed via this standard, and is based on the
EAP protocol [33]. The 802.1X is the authentication framework, and the EAP methods
deployed are the authentication algorithms [29].
An Ontology for Generic Wireless Authentication 45
• Support for mutual authentication between client and access point, thus
preventing rogue (impersonating) access points.
• Protection against eavesdroppers and man in the middle attacks, this can be
ensured using session keys for message authentication, data confidentiality and
data integrity.
The client initiates the connection procedure, by associating itself to the access point, and
issuing an EAP Start Request. At this point, the access point blocks the communication
between the client and the network, until the authentication procedure is completed, (i.e.
until the client presents correct authentication data (user ID and password/certificate)
and is verified).
The access point requests the identity of the client, by issuing an EAP Request Identity
message. The client replies to this message via an EAP Response message containing its
identity. This information is forwarded to the AAA server.
The 802.1X, along with the EAP authentication methods provide centralized
authentication and dynamic key generation and distribution. Authentication methods in
An Ontology for Generic Wireless Authentication 46
WLAN can be of different types, the ones described in this chapter are password based
and certificate based methods.
Authorization specifies what rights a client is entitled to during the connection to the
network. This includes but is not limited to session time, access to certain
resources/groups, etc…
Accounting is used for tracking a user, and for billing purposes. The user name and
connection duration are stored for this purpose.
Several types of authentication servers exist. The AAA server based on the Remote
Authentication Dial In User Service (RADIUS) protocol is discussed in this thesis.
The Remote Authentication Dial In User Service (RADIUS) is a protocol, used for
providing authentication, authorization and accounting services between an access point
and an authentication server (a RADIUS server or any other kind of AAA server). It
provides a central user database [35] that can be accessed by different servers, in order to
authenticate users (validate credentials) as well as provide configuration information,
such as the type of service to deliver to the user (authentication) and accounting services,
based on the user’s usage of the network.
A RADIUS server supports several methods for authentication (RFC 2138). In simple
terms, a RADIUS server checks for the validity of a user, requesting access to a network.
It authorizes the user to access the network, if the information stored in a database is
verified [34].
An Ontology for Generic Wireless Authentication 47
• A digital signature
• Version
• Serial Number
• Signature Algorithm
• Issuer Name
• Validity period
• Subject
A certifying authority is a trusted third party that issues digital certificates, and verifies the
validity of public keys [39].
An Ontology for Generic Wireless Authentication 48
A public key is a number belonging to a certain entity. This key is distributed among
entities that interact with the entity owning this key. The public key is used for verifying a
digital signature and is used for encryption [39].
A private key is a number belonging to a certain entity and is not known to any other
entity. The private key is used for computing signatures and decryption. Public and
private keys exist in pairs and correspond to each other; a message can be decrypted by a
private key upon the reception of a public key associated with that private key [39].
A digital signature is a digital code, verifying that the sender is the one issuing the
electronic message. The digital signature, also verifies that the contents of the electronic
message have not been altered.
In password based authentication, the password is not directly transmitted to the access
point from the client. Instead a password hash or secret key is generated from the
password to protect it from being sniffed across the network. The secret key or password
hash is calculated via a hash function, which provides a one way encryption of the
password. The password is shared between the network and the client. The network
calculates the password from the received secret key [29].
Messages for the purpose of authentication, are sent from the wireless device to the
authentication server via the Extensible Authentication Protocol (EAP), which is an
envelope consisting of different types of authentication methods. EAP is a general
authentication protocol, supporting various authentication procedures. Our
concentration for this thesis will be EAP authentication methods for password and
certificate based authentication [33].
An Ontology for Generic Wireless Authentication 49
The EAP protocol defines several types of authentication methods, amongst them are
the following:
LEAP, is a password based authentication protocol that authenticates the user rather
than the device. Authentication is performed according to the user name and password
provided. No certificates are used in this type of authentication. Mutual authentication of
the client and authentication server is performed in this protocol, which depends on the
existence of a secret key, and the user’s password that is shared between the client and
the network.
An authentication challenge is sent to the client, from the authentication server. The
client responds to the authentication challenge with the hashed password. The
authentication server retrieves relevant authentication information, from a database to
create a response to the authentication request. The response generated by the
authentication server is then compared to the one received from the client. The client
authenticates the authentication server in a similar fashion. A dynamic session key called
WEP is generated upon successful authentication. Successful authentication ends with an
EAP-Success method [28].
EAP TLS is a certificate based authentication method, and is based on the TLS protocol
(RFC 2246), which is the present version of the Secure Socket Layer (SSL).
SSL is used by web browsers to secure transactions within web applications [29].
In EAP-TLS, certificates are used on both the client and server side for authentication.
The client authenticates the authentication server via a digital certificate, sent to the client
by the authentication server, and checks for the validity of the certificate. The server in
turn authenticates the client in a similar manner. Upon the reception of the EAP-Success
An Ontology for Generic Wireless Authentication 50
message, the dynamic session keys are generated and network access is granted to the
client [28].
The PEAP protocol is a hybrid of EAP-TLS and any other EAP authentication method.
It is a certificate based authentication method. Server side authentication is performed via
EAP-TLS and the use of digital certificates is employed. For client side authentication
any EAP method can be deployed, which is transported via a secure TLS tunnel.
Certificates are not required for client authentication in PEAP.
As with the authentication of the server in EAP-TLS, PEAP performs the same
procedure of requiring and verifying a digital certificate, from the authentication server.
After verification of the server’s side certificate, an encrypted tunnel, between the client
and the authentication server is created. The tunnel is a secure path, for authenticating
the client via non-mutual EAP methods, like EAP-Message Digest 5 (EAP-MD5) or
EAP-Challenge Handshake Authentication Protocol (EAP-CHAP) (RFC 2284, RFC
1994). Upon successful client authentication the EAP-Success message is sent and
session keys are derived [28] [29].
An Ontology for Generic Wireless Authentication 51
For EAP-SIM, the wireless station requires a SIM reader, which could be in the form of
a smart card, USB stick, PC access cards, etc…
center via a GSM gateway. The GSM gateway is responsible for translating requests from
an authentication server into GSM syntax. After the retrieval of the authentication data,
several messages are exchanged to and from the client and authentication server. Upon
successful authentication, the client gains access to the network.
Before successful authentication of the client and network, the communication ports are
blocked from the client by the AP. The client is not able to send any messages to the
network except for the authentication specific messages (EAP and EAP-SIM messages).
After authentication is completed, the client is able to communicate with the network
and the AP unblocks the ports from the client.
The EAP-SIM mechanism is more secure than the stand alone GSM system for
authentication, since it provides mutual authentication of the client and the network.
Another factor is that client’s session key, is never transmitted via the radio interface with
EAP-SIM, thus less data is exposed in comparison to GSM networks.
EAP-SIM functions in a way that it retrieves several GSM triplets from the AuC, and
combines them together in order to generate a session encryption key. This encryption
key is more secure than the GSM counterpart.
For the communication of the EAP-SIM between the client and the network, the EAP-
SIM protocol and the EAP-SIM authenticator code are implemented on the client. The
authenticator code is responsible for handling server side EAP-SIM messages, and is also
responsible for communicating with the AuC. Messages sent from the AAA server to the
AuC are translated into GSM specific messages [28].
EAP-AKA is used for 3G networks, namely UMTS networks and is similar in concept to
EAP-SIM but with more enhanced security features. EAP-AKA is not addressed in this
thesis.
An Ontology for Generic Wireless Authentication 53
EAP-SIM Authentication
The following figure illustrates WLAN authentication via the EAP-SIM protocol:
EAP Request
Network Identity
MAC_RAND
= Server
Authenticated
MAC_RAND
Calculate
Challenge Challenge Calculate
XRES, Kc,
Response Response MAC_XRES
MAC_XRES
MAC_XRES MAC_XRES
MAC_XRES Client
= Authenticated
MAC_XRES
EAP-Success Session Key Accept
The EAP-SIM authentication procedure starts, when the client sends an EAP-over-LAN
(EAPOL) Start message to the AP. This message informs the AP that the authentication
procedure will be carried out via EAP. The AP responds to the EAPOL Start message,
with an EAP Request Identity message, which requests the network identity of the user.
This identity is forwarded from the client to the authentication server via the AP in the
form of an EAP Identity Response.
The user’s network identity takes the following syntax: 0 <IMSI>@<realm>, where
IMSI represents the subscriber’s identity number and realm represents the network
An Ontology for Generic Wireless Authentication 54
operator’s domain name. The network identity is used for WLAN authentication
purposes.
The authentication server determines the EAP type being used, and sends an EAP-SIM
Start message to the client. The client responds via an EAP-SIM Start Response message
that carries the RAND number generated from the SIM. After reception of the EAP-
SIM Start Response message, the authentication server retrieves several GSM triplets
from the AuC of the GSM network provider. A gateway is needed in order to translate
the request from the AAA server’s syntax to GSM specific syntax.
An EAP-SIM Challenge message is created from the RAND number, received from both
the client’s SIM and the triplets from the GSM response. This challenge consists of the
AuC’s RAND number and a Random Message Authentication Code (MAC_RAND),
which is 160 bits long.
A MAC_RAND number is calculated separately on the SIM card, and is compared to the
one received from the authentication server in the EAP-SIM Challenge. If both
MAC_RAND numbers are equal, the first step of mutual authentication is completed
and the server is authenticated.
Upon successful server authentication, the SIM generates the XRES and Kc for the
respective RAND numbers received. Another number is also generated, which is the
Expected MAC Response (MAC_XRES).
The MAC_XRES is sent by the client to the authentication server as a response to the
challenge sent. The authentication server separately calculates a MAC_XRES, and
compares it to the one received from the SIM. If both MAC_XRES are equal, the
second step of mutual authentication is completed and the client is authenticated to the
server.
Session encryption keys are generated on the SIM and authentication server. An Accept
message is sent from the authentication server to the AP, along with an encapsulated
EAP-Success message (which is sent to the client) and the client’s session key. The
client’s session key, is sent to the client from the AP via a Broadcast key. Authentication
at this stage is completed and the client is able to access the network [28].
An Ontology for Generic Wireless Authentication 55
“The Semantic Web is not a separate Web, but an extension of the current one, in which information is
given well-defined meaning, better enabling computers and people to work in cooperation.” [40].
“The Semantic Web is a mesh of information linked up in such a way as to be easily processable by
machines, on a global scale. You can think of it as being an efficient way of representing data on the
World Wide Web, or a globally linked database.” [41]
The Semantic Web is used to express the meaning of content, to machines. It is used to
provide machine readable content, on the web, to machines and processes. This content
can be easily processed, and manipulated in a meaningful way.
The current state of the Web today, only provides information accessible and
understandable by humans. No semantics are expressed, or provided for the contents of
the different web pages displayed. Thus, vital information cannot be used automatically,
without manual insertion, or processing into some sort of application or database.
As the first definition of the Semantic Web states, it is an extension of the current Web.
This extension is in the form of three main components of the Semantic Web:
The meaning of content can be expressed, in order to enable machine readability, rather
than just being used, for displaying content to humans, and which has no real value to
processes or machines. Providing meaning to content enables the Web to be a resource,
for processable data and information.
among terms, and can be used for the creation of new meaning. The machine is able to
read the ontology, and provide a user with more meaningful information [40].
Various languages and tools have been developed for the Semantic Web. The most
popular are, the eXtensible Modelling Language (XML) – used to add arbitrary structure
to documents without expressing the meaning of the structures, the Resource
Description Framework (RDF) – used to express meaning and used to exchange
knowledge on the Web, and the Web Ontology Language (OWL) – used for sharing and
distributing knowledge. OWL is an ontology language, which supports knowledge
management, and advanced Web searches [40] [42].
The ontologies section takes a deeper look into ontologies and explains ontologies in
more detail.
The most popular languages developed for the Semantic Web, and which are World
Wide Web Consortium (W3C) recommendations are as follows:
• XML and XML-Schema; provides structured syntax for documents (XML), restrict
the structure of XML and extend it with dataypes (XML-Schema), but which also
provide no semantic meaning for the documents.
• RDF and RDF-Schema; using XML syntax provide a datamodel for objects and
define the relationships between the datamodels (RDF). RDF-Schema provides a
terminology to express RDF datamodels using classes and properties.
• OWL; provides more terminology for expressing the relationships between the
classes and properties. It provides more terminology for the description of classes
and properties [51]. OWL differs from XML-Schema, in that it represents
knowledge of a certain domain rather than just being a message format [52].
3.2 Ontologies
3.2.1 Origin
The term Ontology originates from philosophy and describes the nature of being in its
different aspects. Ontology relates back to many years and has had a long history.
Ontology in the field of metaphysics is the study, of existence and the relationships that
relate to this existence. It attempts to answer questions like; what defines the nature of
beings, what are its main characteristics/properties, what relationships exist among
An Ontology for Generic Wireless Authentication 57
different beings, and how can they be defined, what are the main causes of being, what
different entities exist in beings and what rules govern them, etc…
3.2.2 Definition
3.2.2.1 In Philosophy
“That department of the science of metaphysics, which investigates and explains the nature and essential
properties and relations of all beings, as such, or the principles and causes of being” [44].
“A branch of metaphysics concerned with the nature and relations of being” [45].
“A systematic arrangement of all the important categories of objects or concepts, which exist in some field
of discourse, showing the relations between them. When complete, an ontology is a categorization of all the
concepts in some field of knowledge, including the objects and all of the properties, relations, and functions
needed to define the objects and specify their actions. A simplified ontology may contain only a hierarchical
classification (a taxonomy) showing the type subsumption relations between concepts in the field of
discourse. An ontology may be visualized as an abstract graph with nodes and labelled arcs representing
the objects and relations” [47].
“An ontology defines a common vocabulary for researchers who need to share information in a domain. It
includes machine-interpretable definitions of basic concepts in the domain and relations among them”
[49].
Ontologies are designed for the purpose of knowledge sharing and re-use. An Ontology
is formal if a machine is able to interpret its meaning. It is explicit if the ontology concepts
and the constraints applied to the ontology are explicitly defined. It is a specification
because it describes the concepts of a certain domain in an actual manner. It is a shared
view or concept of a particular domain and finally, conceptualization refers to the fact that
the ontology represents an abstract analysis/vision of a certain nature or reality.
An important point to put into consideration when addressing ontologies, is that apart
from ontologies defining information or data as formal semantics, which can be
interpreted and processed by machines (machine-understandable). They also define real
An Ontology for Generic Wireless Authentication 58
Ontologies can be expressed in various ways, and different approaches exist for defining
concepts and the relations of concepts in a certain domain. A brief description between
three approaches, namely Description Logics, Frame-based and Predicate Logic is given
in the following:
A first step in representing a domain is the definition of concepts, related to and relevant
for this domain. These concepts can be described, in terms of properties and restrictions
that must be satisfied, in order for the concepts to belong to the described domain.
Reasoning of the concepts, represented in the knowledge base (the ontology and its
instances), is used to infer new information about the domain from the already existing
knowledge.
Description Logics also support the classification of concepts and individuals, which
expresses the child and parent hierarchies amongst the defined concepts [50] [60].
3.2.3.2 Frame-based
Modelling in Frame based approaches, consists of classes and local class properties. It
takes more of an object oriented approach in defining a domain. Frames (classes)
describe an individual, or a set of individuals in a certain domain, thus representing
knowledge of a concept in that domain.
Properties of a class can be reused by other classes with other range values and value
restrictions. Frames in a Frame-based system are interconnected and follow a hierarchy,
such that the properties defined for parent frames, are inherited by those of the child
frames. Properties can take specified values, or can be computed values [50] [59].
An Ontology for Generic Wireless Authentication 59
In Predicate Logic, the relationship(s) between subjects and objects are expressed.
Predicate logic is based on predicates. A Predicate is an expression that expresses (a)
relationship(s) between terms, e.g. the predicate “is a” in “GSM is a second generation
network”. Thus, GSM is the subject and second generation network is the object.
The most important elements in predicate logic are constants, predicates, variables,
formulas and quantifiers.
Constants are the names used in predicate logic, and represent the vocabulary used.
Predicates as explained, define the relationships between terms. Variables represent
terms, and are used as place holders for objects that represent individuals. Terms can also
be objects and constants. Formulas form expressions that have meanings, which are a
combination of individual terms. Quantifiers indicate the number of objects asserted to a
predicate. Two types of quantifiers are, the universal quantifier that asserts a predicate to
all objects, and the existential quantifier that asserts a predicate to some objects [58] [50].
Closed sentences are the result of combined terms that formulate expressions. A
knowledge base in predicate logic is represented by a set of sentences [50].
Several ontology languages exist, which depend on the ontology approach being used, is
a matter of preference, and also a matter of what purposes the ontology is used for. For
the purpose of this thesis, the Web Ontology Language is chosen and is discussed in the
following in detail.
The Web Ontology Language (OWL) is a language, created specifically for designing,
defining, creating and instantiating Web Ontologies. OWL is used for creating and
describing classes, properties and their instances, as well as defining the relationships that
exist between these classes and properties [52].
The use of OWL can be summarized into the three following points:
• The description of a certain domain via the definition of classes and properties.
• The definition of the relationships existing among these classes and properties.
• The reasoning of the defined classes, properties and relationships, which prove
the defined logic of the described domain, and verify its consistency [52].
OWL is divided into three sublanguages; OWL-Lite, OWL-DL and OWL Full, which
differ from each other in the level of expressivity. Each sublanguage is an extension of its
predecessor, and is designed according to what the required ontology should describe.
Making a choice of which sublanguage to choose is based on the level of expressivity
required for the ontology, and which best suits the needs of the ontology.
OWL represents an important part of the Semantic Web. It allows the collection of
information from distributed sources, by relating ontologies together. This enables web
resources to be accessible to processes, via the description of the resource’s web content
[52].
Is the simplest form of OWL ontologies and provides simple classification support, and
simple constraints [51].
3.2.4.2 OWL DL
OWL Full is an extension of OWL DL, and full support of the OWL constructs is given
in OWL Full, without any restrictions. OWL Full provides for maximum expressiveness,
but without any computational assurances. OWL Full provides some reasoning
mechanisms, but complete reasoning for OWL Full is unlikely to be implemented.
OWL is used to define classes, instances and properties, in addition to describing the
relationships between the defined classes and properties. The basic language elements of
OWL are built on these concepts, and the most important ones are described in the
following [52]:
3.2.5.1 Classes
Classes can be sub-classed, forming a hierarchy and a class may have several sub-classes.
The subclass inherits its characteristics from the super or parent class, and it may have
one or more parent class. Multiple inheritance is supported.
Subclasses and instances of a class are, sometimes used interchangeably, and can be
confused from the meaning. The main difference is that a subclass is used, to describe a
subset of the class. Instances are used to state that the individual described, is an actual
member of the class, and not a member that can be further characterized or subset.
OWL Full supports classes and instances, while OWL DL does not [52].
using the oneOf construct, the class consists of oneOf the enumerated members and
nothing more [51] [52].
Disjoint classes describe the difference between classes, and state that one class cannot
have the same instance(s) as another class that it is disjoint with. This helps a reasoner in
detecting inconsistencies between classes. What is an instance in class A cannot be an
instance in class B, if both classes are declared as disjoint [51] [52].
3.2.5.2 Properties
Properties describe individuals that belong to a class. They define general and specialized
facts about an individual. Relationships among individuals are defined using properties.
The same property can be re-used by several classes. This is achieved by specifying rules,
or restrictions for a particular individual. Therefore, the rules are specific to that
particular individual, and are not a tied to the property. Applying restrictions to
properties is a method, for defining the relationships between individuals of a class.
As with classes, properties can have sub-properties that further classify or define the
property, and that form a hierarchy of properties. A sub-property can have multiple
properties as a parent, or super-property. Sub-properties inherit the super-property’s
characteristics [52].
The two important types of properties in OWL are datatype properties and object properties:
Domains and ranges can be defined for properties, which relate individuals of one class
(the domain), to individuals of another class (the range), via a specific property.
Domains specify the individuals the property can be applied to. A range limits the values
a property can have, only the individuals specified in the range, can be values of the
specified property.
An Ontology for Generic Wireless Authentication 63
3.2.5.2.2.1 TransitiveProperty
Transitive properties are properties, which relate one individual to another, via a
common individual. E.g. considering two individuals (individual 1 and individual 2), are
related to each other via a property, if a third individual (individual 3), is related to
individual 2 via the same property, it can be deducted that individual 1 is also related to
individual 3 via the same property. This is a transitive property [53].
3.2.5.2.2.2 SymmetricProperty
3.2.5.2.2.3 FunctionalProperty
Functional properties can also be referred to as single valued properties, and are
properties that can take only one individual as its value. If a functional property is applied
to two individuals, it can be deducted that these two individuals, represent the same
individual. The minimum cardinality allowed for a functional property is zero and the
maximum cardinality is 1 [51] [53].
3.2.5.2.2.4 InverseOf
3.2.5.2.2.5 InverseFunctionalProperty
An inverse functional property, states that the inverse property is functional (i.e. has only
one individual as its value) [51].
Property restrictions are, rules applied to properties, in order to specify which and how
many individuals can belong to a certain class. A restriction is used, for describing an
unknown class, which consists of individuals satisfying the restriction (e.g. individuals
belonging to a certain group or that satisfy certain criteria). Property restrictions can be
classified into quantifier restrictions; (existential quantifiers and universal quantifiers),
hasValue restrictions and cardinality restrictions. These are addressed in the following
[51] [53]:
Three parts make up a quantifier restriction; the first part is the type of quantifier
(existential or universal), the second part is the property involved in assigning the
restriction, and the third part is, the class from which values/individuals, are to be taken
from, in order to create an anonymous class that satisfies the restriction (The creation of
a group of values satisfying the condition).
Cardinality is used, to specify the number the number of relationships that can be
associated to a particular individual, via a specific property. In OWL minimum
cardinality, maximum cardinality and cardinality, can be defined for properties, and which
express the minimum, maximum and arbitrary number of occurrences respectively.
Cardinality values start from 0 and are never negative values [53].
3.2.5.3 Operators
3.2.5.3.1 intersectionOf
The intersectionOf operator performs a logical ‘AND’ operation, between two or more
classes. It combines the features of the classes specified, into a new class. Individuals of
the intersected classes become individuals of the new class [53].
3.2.5.3.2 unionOf
The unionOf operator performs a logical ‘OR’ operation between two or more classes,
and combines either the characteristics of all the specified classes, or one of the classes
into a new class. (E.g. if a union operation is performed for class A and class B, the
resulting class would be the individuals, of class A and B, or would be either one of
them) [53].
3.2.5.3.3 complementOf
The complementOf operator selects the individuals that do not belong to the specified
class.
An Ontology for Generic Wireless Authentication 66
Several tools for editing and creating ontologies exist. For the purpose of this thesis, the
Protégé tool with the Protégé OWL Plug-in were used as an ontology editor, the Racer
tool as an ontology reasoner and the GraphViz tool as a tool to visualize the ontology.
Descriptions of each tool are provided in the following:
3.2.6.1 Protégé
Protégé was developed as a tool for developing ontologies. Apart from the development
of ontologies, Protégé also supports the customization of data entry forms, and data
entry. It is an open source tool, and provides a knowledge-base framework, based on
Java and which can be extended, via customized Application Programming Interfaces
(API) and Plugins. Extensions can provide different kinds of components, such as;
graphs, tables, images, etc…as well as providing support for different storage formats,
such as; XML, RDF(S), OWL and HTML [54].
The Protégé OWL Plug-in is a complex extension of the Protégé tool, which is called
Protégé Core. With Protégé OWL, it is possible to edit OWL ontologies and perform
description logic reasoning, and OWL-related services (classification, consistency
checking and ontology testing).
Formats like RDF(S), OWL Lite, OWL DL, and OWL Full are supported by the Protégé
OWL Plugin. Extensions that include custom tabs and widgets can be added.
Protégé OWL provides a library of reusable components, and a very flexible architecture,
which can be extended in various ways. Protégé OWL, becoming an architecture for the
building of ontology based Semantic Web applications can be foreseen [55].
inconsistent classes), and classification (inferring new concepts, classes, relations, etc…
from the existing asserted concepts) [55] [56].
Inferred concepts correspond, to the deduction of new content and meaning from
existing content (computed concepts). Asserted concepts are concepts which are defined
in a certain domain, (manual definition of concepts).
A knowledge base in description logics consists of, TBoxes (ontologies) that represent
the knowledge of a certain domain, and ABoxes that represent the instances of the
TBoxes domain knowledge.
RacerPro can be used in many application fields, among them are the Semantic Web and
Knowledge Engineering fields [56].
GraphViz also supports manual editing of graphs, via test files or with the use of a graph
editor [57].
GraphViz is used in Protégé for visualizing the ontology, in terms of its structured
hierarchy (subclasses and superclasses). It also provides visualization for the asserted and
inferred hierarchies of the ontology.
• Asserted/Inferred Conditions/Hierarchy/Model
Defined classes are classes that consist of at least one set of necessary and sufficient
conditions. Necessary and sufficient conditions imply, that the necessary conditions
defined, in order for an individual to qualify in being a member of a class, are not only
necessary for class membership, but are also sufficient for the individuals, satisfying the
conditions in becoming class members.
Primitive classes are classes that consist of at least one set of necessary conditions.
Necessary conditions imply that, certain conditions need to be satisfied, in order for an
individual to become a member of the defined class. It does not imply, however, that any
individual that satisfies the defined conditions must be an individual of the defined class
[53].
Two issues in ontology development are addressed in this thesis. The first, is the reasons
why anyone would want to develop an ontology, and the second, is the steps involved in
the development of an ontology, and what points should be put into consideration.
Several reasons exist to develop an ontology, some important reasons could be one of
the following:
There is no right or wrong way for the design and development of an ontology, different
approaches can be used. This thesis concentrates on the following approach:
The first point to consider while developing an ontology, is the domain the ontology is
being developed for. A proper understanding of the intended domain should be
performed, and the definition of the domain’s components, and the relationships that
exist between these components should be clarified.
An ontology defines concepts of the real world, which is a fact that should be put into
consideration in ontology development. Therefore, the concepts defined in the ontology,
must relate to the real concepts and relationships, in the real world domain. It must be
clear what the ontology will be used for in order to decide the details of the ontology.
Ontology development includes the definition of the domain concept (classes) and the
arrangement of these classes in a certain hierarchy. The definition of the properties,
property values, and the definition of the relationships, existing amongst the concepts.
The following lists and describes the steps that could be followed in developing an
ontology:
Q: Who will the ontology be useful for, and for what purposes?
The re-usage of ontologies could save a lot of effort, by just taking already existing
ontologies and refining them, or extending them according to the intended use.
The enumeration of terms is helpful in determining the contents of an ontology, e.g. the
enumeration of the concepts the ontology will define, the concepts properties and
characteristics, etc…
Several approaches in defining the class hierarchy could be used, e.g. a top-down
approach; which defines the most general terms first, and then goes down to specializing
each term definition, a bottom-up approach; which defines the specific terms first and
then goes up to the most general term definitions, or a combination of both approaches.
After the definition of the concepts (classes of an ontology) further descriptions can be
given to these concepts, by defining the properties of a concept, and its relationships to
the other concepts in the ontology.
The last step of the ontology development would be the instantiation of class instances.
An instance is the value filled in for a certain property, of an individual belonging to a
class [49].
An Ontology for Generic Wireless Authentication 71
Ontologies can be classified and checked for consistency using a reasoner. RacerPro is
one example for an ontology reasoner.
An Ontology for Generic Wireless Authentication 72
The Protégé 3.0 tool with the Protégé-OWL plugin, was used for the development of the
Generic Wireless Authentication Ontology. RacerPro and several older versions of Racer
were used, to classify and create the inferred hierarchy and check for consistencies in the
ontology. For the visualization of the class hierarchy, the GraphViz tool was used along
with the OWLViz plugin.
The following figure illustrates a general overview of the ontology’s class hierarchy:
The ontology consists of 14 main classes, which are divided into subclasses. The super
class (not visualized here), is owl:thing which is part of the OWL language defined by the
W3C. It represents the set that contains all individuals. All individuals in an ontology are
subclasses of owl:thing [53].
An Ontology for Generic Wireless Authentication 73
The main ontology classes are: the Algorithm class, the AuthenticationMethod class, the
AuthenticationType class, the Certificate class, the CertificateComponent class, the Code
class, the Database class, the Identity class, the Key class, the Network class, the Number
class, the Service class, the UserData class and the Subscriber class. These classes are
related to the description of authentication data stored in the profile registers for GSM,
UMTS and WLAN networks and are explained in detail in the following section.
The Algorithm class is the parent class of the authentication specific algorithms, used in
GSM and UMTS networks.
• A3
• A8
• f1
• f2
• f3
• f4
• f5
individual as any other class in the ontology. (E.g. an Algorithm cannot be a service or an
identity).
The AuthenticationMethod class is the parent class of the authentication types, used in
WLAN networks. It describes some of the EAP authentication methods.
• EAP-SIM
• EAP-TLS
• LEAP
• PEAP
The AuthenticationMethod class is declared disjoint from all of the classes in the
ontology, except for the AuthenticationType class, because an authentication method can
be both an authentication method and an authentication type. E.g. LEAP, which exists in
the AuthenticationMethod class is a password based type of authentication method. The
password based characteristic is a subclass of the AuthenticationType class, therefore,
these two classes cannot be declared as disjoint. More details on the EAP authentication
methods can be found in section (2.10.5.2 ).
• CertificateBased
• ChallengeResponse
• MutualAuthentication
• NetworkAuthentication
• PasswordBased
• UserAuthentication
An Ontology for Generic Wireless Authentication 75
The Certificate class is an empty class that takes individuals of the CertificateComponent
class as values. This is described in the following section.
The CertificateComponent class describes the components that make out a digital
certificate as described in section (2.10.3).
• IssuerName
• PublicKey
• SerialNumber
• Signature
• SignatureAlgorithm
• Subject
• ValidFrom
• ValidTo
• Version
An Ontology for Generic Wireless Authentication 76
The Code class describes the codes that are part of the IMSI and MSISDN. Details on
the codes contained in the IMSI and MSISDN can be found in section (2.3.3).
• CountryCode
• MobileCountryCode
• MobileNetworkCode
• NationalDestinationCode
The Database class describes the databases used by the GSM, UMTS, IMS and WLAN
networks. Individuals of other classes are linked to subclasses of the database class, since
several individuals are stored in the databases, defined as children of the database class.
• AuC
• HLR
• HSS
• UserDatabase
The AuC and HLR are also subclasses of the HSS class, and are later removed from the
hierarchy in the inferred model. This will be discussed later on in this chapter. Details
about the AuC, HLR, HSS and user database can be found in section (2.3.1.1 and 2.7).
The Identity class describes the identities used in the GSM, UMTS, IMS and WLAN
networks.
• IMSI
• NAI
• PrivateUserIdentity
An Ontology for Generic Wireless Authentication 77
• PublicServiceIdentity
• PublicUserIdentity
• UserNetworkIdentity
• URL
• Realm
• IPAddress
• UserName
Details about the IMSI, NAI, public service, private and public user identities are
described in section (2.7.1).
The Key class is subdivided into three subclasses; the DerivedKey class, the
GeneratedKey class and the StaticKey class, which are also sub-classed. The Key class
describes the keys used, in the authentication process of the networks, and that are used
for verification purposes. The DerivedKey class describes the keys that are derived from
other keys, or that result of an algorithm computation. The GeneratedKey class contains
the generated keys, like the RAND and SQN numbers. The StaticKey class, contains the
keys that are static, and that are not created dynamically, like the secret key (Ki) of GSM
and UMTS networks, or the public and private keys of a certificate.
• AK
• AMF
• AUTN
• IK
• Kc
• MAC
An Ontology for Generic Wireless Authentication 78
• MAC_RAND
• MAC_XRES
• RES
• XMAC
• XRES
• RAND
• SQN
• Ki
• PrivateKey
• PublicKey
The Network class is the domain of the ontology modelling. All classes in the ontology
correspond to one or more of the networks described in the network class.
• GSM
• IMS
• UMTS
• WLAN
The Number class describes the numbers associated with the IMSI, IMSDN, and
numbers associated to a public user identity. Details about these numbers can be found
in section (2.3.3).
• HLRNumber
An Ontology for Generic Wireless Authentication 79
• MSISDN
• MobileSubscriberIdentificationNumber
• SubscriberNumber
• IndividualSubscriberNumber
• FixedTelephoneNumber
Three types of services are distinguished in the Service class, namely; basic services,
supplementary services, and multimedia services. The Service class describes the types of
services available for a subscriber. Multimedia services are available for UMTS and
WLAN networks and include several services like the Multimedia Messaging Service
(MMS).
• SMS
• Speech
• CallBarring
• CallDivert
• CallWaiting
• ConferenceCall
• CustomerCareBilling
• DataService
• AudioDownload
• AudioStream
• MMS
• VideoDownload
An Ontology for Generic Wireless Authentication 80
• VideoStream
• WebBrowsing
The UserData class describes personal user data needed for a subscription to a mobile
service (GSM, UMTS or WLAN). Information includes banking details, personal details
(name, address, etc…). Session duration, also a subclass of the UserData class is used to
record the duration of usage and is used for billing purposes in WLAN networks. The
Password subclass of the UserData class is associated with the AuthenticationType class
for password based authentication.
• AccountHolder
• AccountNumber
• BankCity
• BankCode
• BankCountry
• City
• Country
• FirstName
• HouseNumber
• LastName
• Password
• PostalCode
• SessionDuration
• State
• StreetName
An Ontology for Generic Wireless Authentication 81
The Subscriber class is an empty class that uses individuals of other classes as its values.
E.g. using a property it can be used to describe that a subscriber is a subscriber of a
certain service.
The following figure illustrates a snapshot of the Protégé-OWL tool, and the disjoint
classes declared for the CertificateComponent class:
A subclass inherits its disjointness to other classes, from its super class and cannot be
disjoint from its super class. Logical errors occur in the ontology, when checking for
consistency. An error is generated, if a subclass is declared as disjoint from its super class.
The following section goes into detail about the disjointness of the classes in the
ontology:
The Algorithm class is disjoint from all the classes in the ontology, except for the
SignatureAlgorithm subclass of the CertificateComponent class. A SignatureAlgorithm is
also an Algorithm, it is not declared as disjoint from the Algorithm class for this reason.
All subclasses of the Algorithm class, namely (A3, A8, f1, f1_, f2, f3, f4, f5 and f5_) are
disjoint from each other, and are also disjoint from the SignatureAlgorithm class. An A3
algorithm is not an A8 algorithm, this case also holds for the other members of the class.
A SignatureAlgorithm is not an A3 algorithm.
The AuthenticationMethod class is disjoint from all classes in the ontology, except for
the AuthenticationType class. An authentication method e.g. EAP-SIM is an
authentication type e.g. ChallengeResponse type.
The EAP-SIM subclass is disjoint from all its siblings (an EAP-SIM method is not an
EAP-TLS method for example). It is also disjoint from the following subclasses of the
AuthenticationType class; CertificateBased, PasswordBased, NetworkAuthentication and
UserAuthentication. This is because EAP-SIM is neither a certificate based, password
based, network authentication or user authentication type of authentication. What is
meant by user and network authentication is that, the authentication method only
authenticates the user, or only authenticates the network.
An Ontology for Generic Wireless Authentication 83
The EAP-TLS subclass is disjoint from all its siblings (EAP-SIM, LEAP and PEAP). It is
also disjoint from the PasswordBased, ChallengeRepsonse, and UserAuthentication
subclasses of the AuthenticationType class. EAP-TLS does not perform any
authentication, based on password, or challenge response mechanisms. It does not
authenticate the user of a network.
Classes that are not declared disjoint from the EAP-TLS class are; the CertificateBased,
MutualAuthentication and NetworkAuthentication classes. EAP-TLS authentication is
based on certificates. It performs mutual authentication of the network and user, and it
also authenticates the network only in conjunction with the PEAP authentication
method.
The LEAP subclass is disjoint from all its siblings, and is also disjoint from the
CertificateBased and NetworkAuthentication subclasses of the AuthenticationType class.
LEAP is a certificate based type of authentication, and it does not authenticate the
network only (i.e. it provides mutual authentication of the client and network).
The classes that are not disjoint from the LEAP class are; the ChallengeResponse,
MutualAuthentication, PasswordBased and UserAuthentication classes. LEAP is a
password based type of authentication. In this type of password based authentication, a
challenge is sent in return for a response. This is performed in order to calculate the same
secret, which enables a user to be authenticated. LEAP performs mutual authentication
of the network and user, and also performs authentication of the user only in
conjunction with PEAP authentication.
The PEAP subclass is disjoint from all its siblings (EAP-TLS, LEAP and EAP-SIM). It is
not disjoint from any member of the AuthenticationType class, since the PEAP method
is a certificate type of authentication method. It performs mutual authentication, it uses
An Ontology for Generic Wireless Authentication 84
the EAP-TLS to authenticate the network, and any type of EAP method to authenticate
the user. Network only authentication, user only authentication, password based
authentication and challenge response type of authentication are supported by this class.
The AuthenticationType class is disjoint from all the classes in the ontology, except for
the AuthenticationMethod class. The concept behind the classes being disjoint from each
other or not is the same as that for the AuthenticationMethod classes, except that it is in
reverse order.
The CertificateBased subclass is disjoint from all its siblings, (a certificate based type of
authentication is not a password based type of authentication or a challenge response
type of authentication, etc…). It is also disjoint from the EAP-SIM and LEAP classes.
The CertificateBased subclass is not disjoint from the EAP-TLS and PEAP classes.
The ChallengeResponse subclass is not disjoint from the EAP-SIM, LEAP and PEAP
classes.
The MutualAuthentication subclass is disjoint from all its siblings. It is not disjoint from
any of the AuthenticationMethod subclasses, since all the authentication methods
described in the AuthenticationMethod class perform mutual authentication.
The NetworkAuthentication subclass is disjoint from all its siblings and from the EAP-
SIM and LEAP classes. It is not disjoint from the PEAP and EAP-TLS classes, since
these methods can perform authentication of only the network.
The PasswordBased subclass is disjoint from all its siblings, from the EAP-TLS, and
EAP-SIM classes. It is not disjoint from the PEAP and LEAP classes, since password
based authentication is what LEAP is based on, and PEAP can use an EAP password
based method to authenticate the user.
The UserAuthentication subclass is disjoint from all its siblings, from the EAP-TLS, and
EAP-SIM authentication methods. It is not disjoint from the PEAP or LEAP classes,
since these methods provide authentication of the user only, in conjunction with PEAP
authentication.
The Certificate class is disjoint from all the classes in the ontology, since no other class in
the ontology is-a Certificate.
The CertificateComponent class is disjoint from all classes in the ontology, except for the
Public Key subclass of the StaticKey subclass of the Key class. A public key is both a
certificate component and a static key, therefore they are not declared as disjoint from
each other. The PublicKey class has two super classes: the CertificateComponent class
and the StaticKey class.
These subclasses classes are also disjoint from the Algorithm class, since the algorithm
class is not declared as disjoint from the CertificateComponent class.
The SignatureAlgorithm subclass is disjoint from all its siblings, and from the subclasses
of the Algorithm class. Nothing can be a SignatureAlgorithm and a A3 algorithm.
An Ontology for Generic Wireless Authentication 86
The Code class is disjoint from all the classes, except for the Number class. A code is-a
number, therefore it is not declared as disjoint from the number class. The subclasses of
the code class are all disjoint from each other, and also the subclasses of the number class
are disjoint from the subclasses of the code class. E.g. The CountryCode subclass of the
Code class is disjoint from the MSISDN subclass, of the number class, because a country
code is not an MSISDN number.
The Database class is disjoint from all classes in the ontology, no class in the ontology,
except for the subclasses of the class DataBase is-a database. The subclasses of the
DataBase class are disjoint from each other. A HLR database is not a user database, an
authentication database or a home subscriber server database.
The Identity class is disjoint from all classes of the ontology, except for the UserData
class. An identity can represent user data; therefore the classes are not disjoint from each
other. The subclasses of the Identity class are all disjoint from each other e.g. an IMSI is
not a NAI. Subclasses of the UserData class are also disjoint from the subclasses of the
Identity class. A password for example is not a public user identity.
The Key class is disjoint from all the classes in the ontology, except for the PublicKey
class of the CertificateComponent class.
The DerivedKey subclass is disjoint from all of its siblings, (GeneratedKey class and
StaticKey class). The subclasses of the DerivedKey class are also disjoint from each
other.
The GeneratedKey class is disjoint from its siblings, (DerivedKey class and StaticKey
class). The subclasses of the GeneratedKey class are also declared as disjoint from each
other.
An Ontology for Generic Wireless Authentication 87
The StaticKey class, as the DerivedKey and GeneratedKey classes is disjoint from its
siblings. The subclasses of the StaticKey class are also disjoint from each other.
The Network class is disjoint from all the classes in the ontology. A network is not any
other type of concept declared in the ontology, therefore it must be declared as disjoint
from all the other classes.
The Number class is disjoint from all the classes in the ontology, except for the Code
class. A number is-a code and is therefore not declared as disjoint from the code class.
The subclasses of the number class are all disjoint from each other, and the subclasses of
the code class are also disjoint from the subclasses of the number class.
The Service class is disjoint from the other classes in the ontology. A Service is not any
other type of concept defined in the ontology, therefore it is declared as disjoint.
The BasicService subclass is disjoint from the SupplementaryService subclass and its
subclasses. Nothing can be both a BasicService and a SupplementaryService.
The SupplementaryService subclass is disjoint from the BasicService subclass, for the
same reason mentioned above. The subclasses of the Supplementary subclass are also
disjoint from each other. E.g. the CallBarring and CallDivert subclasses are disjoint from
each, other because a call barring service is not a call diverting service.
The MutilmediaService subclass also contains subclasses, which are all disjoint from each
other. E.g. the VideoDownload and AudioDownload subclasses are disjoint from each
other, because a video download service is not an audio download service.
An Ontology for Generic Wireless Authentication 88
The UserData class is disjoint from all classes of the ontology, except for the Identity
class. User data can represent an Identity, therefore the UserData class and the Identity
class are not disjoint from each other. Subclasses of the UserData class are disjoint from
each other. Subclasses of the Identity class are also disjoint from the subclasses of the
UserData class.
Declaring classes as disjoint could result in reasoning errors that state that a class is
inconsistent. For example, the following figure illustrates an inconsistency in the
PublicKey class.
This inconsistency appeared because the Key and CertificateComponent class were
declared as super classes of the PublicKey class. At the same time, the whole
CertificateComponent class was declared as disjoint from the Key class.
An Ontology for Generic Wireless Authentication 89
The solution to this problem was to make sure that the PublicKey class was not declared
as disjoint in the Key class, and also in the CertificateComponent class.
The Ontology consists of some of the following properties and inverse properties that
describe how classes are related to each other: (Appendix A lists all the properties in the
ontology)
The hasIdentity property describes that an individual, has the value of another individual
as its identity. The inverse property describes that an individual is an identity of another
individual.
The hasNetworkIdentity property describes that one individual or more, has the value of
another individual or more as its network identity. The inverse property implies the same,
but in reverse order (i.e. an individual is the network identity of another individual).
The hasUserName property describes that an individual, has the value of another
individual as its user name. The inverse property describes that an individual is a user
name of another individual.
The hasCertificate property, describes that an individual, has the value of another
individual as its certificate. The inverse property describes that an individual, is a
certificate of another individual.
The hasPassword property, describes that an individual, has the value of another
individual as its password. The inverse property, describes that an individual, is a
password of another individual.
The hasBasicService property, describes that an individual, has the value of another
individual as its basic service. The inverse property, describes that an individual, is a basic
service of another individual.
The hasDatabase property, describes that an individual, has the value of another
individual as its database. The inverse property, describes that an individual is a database
of another individual.
An Ontology for Generic Wireless Authentication 91
The hasChallenge property, describes that an individual, has the value of another
individual as its challenge. The inverse property, describes that an individual, is a
challenge of another individual.
The hasSecretKey property, describes that an individual, has the value of another
individual as its secret key. The inverse property, describes that an individual, is a secret
key of another individual.
The hasTriplets property, describes that an individual, has the value of other individuals
as its triplets. The inverse property, describes that individuals, are triplets of another
individual.
The hasInput property, describes that an individual, has the value of another individual as
its input. The inverse property, describes that an individual, is an input of another
individual.
The hasOutput property, describes that an individual, has the value of another individual
as its output. The inverse property, describes that an individual, is an output of another
individual.
An Ontology for Generic Wireless Authentication 92
The hasNumber property, describes that an individual, has the value of another
individual as its number. The inverse property, describes that an individual, is a number
of another individual.
The hasSubscriber property, describes that an individual, has the value of another
individual as its subscriber. The inverse property, describes that an individual, is a
subscriber of another individual.
The Stores property, describes that an individual, stores the value of another individual.
The inverse property, describes that an individual, is stored by another individual.
The hasAlgorithm property, describes that an individual, has the value of another
individual as its algorithm. The inverse property, describes that an individual, is an
algorithm of another individual.
After the definition of the class properties, a new is-a relationship was identified. This
relationship should have been expressed in a super class – subclass relationship.
The NAI is an Identity, and belongs to the Identity class. However, the NAI is also a
Private user Identity and must therefore be a subclass of the class PrivateUserIdentity.
Thus NAI has two super classes, namely Identity and PrivateUserIdentity.
The ontology process continues in this manner, with the identification of new concepts
and new hierarchies. It is an iterative process.
An Ontology for Generic Wireless Authentication 93
Until this point, only the classes and properties of the ontology have been defined. Initial
testing and reasoning of the ontology is performed, which checks whether the properties
have been well defined and also checks for the consistencies between classes of the
ontology.
The following figures illustrate a list of errors generated from the ontology tests and from
reasoning:
The NAI is inconsistent due to the fact that it was identified and declared as a subclass of
the PrivateUserIdentity and that it is still disjoint from its siblings. Removing the disjoint
characteristic from the NAI makes the class consistent. Inconsistent classes are marked
with a red circle around the class name.
An Ontology for Generic Wireless Authentication 94
Classes are described and defined by creating restrictions on the defined properties.
Properties restrict the individuals that belong to a specific class, thus enabling the
description of the characteristics of a class.
A class restriction takes the following form; (the class name (the restriction, the property,
the filler)). The class name is the class that the restriction is defined for, the restriction
can be either one of the following (an existential quantifier, a universal quantifier, a has
value restriction, equal cardinality, minimum or equal cardinality and maximum or equal
cardinality) the property is any property defined for the classes, and the filler can be a
class and individual or instance of a class or a data type).
The following, explains in detail some classes and how they are defined:
The following figure illustrates the conditions defined for the f1 class:
The f1 class belongs to the Algorithm class, which means that f1 is an algorithm. The f1
algorithm has an AMF as its authentication management field, and all authentication
quantifier, and in this case means “only” (only AMF as an authentication management
field). The hasAuthenticationManagementField is the property, and the AMF is a class,
which is a subclass of the DerivedKey class.
The f1 class, only has the XMAC key as its expected message authentication code; f1(∀
as its secret key, only the RAND key as its random number, and only the SQN key as its
The f1 class has only SQN “AND” AMF “AND” Ki “AND” RAND keys as its inputs,
this is expressed by the following expression; f1(∀ hasInput SQN, ∀ hasInput AMF, ∀
The f1 class is only an algorithm of the UMTS network, this is expressed as f1(∀
stored in BOTH the AuC, and the HSS; f1(∀ isStoredIn AuC, ∀ isStoredIn HSS), or;
The output of the f1 class can be either the XMAC key or the MAC key, this is expressed
XMAC ⊔ MAC).
An Ontology for Generic Wireless Authentication 96
The following figure illustrates the conditions defined for the EAP-SIM class:
The EAP-SIM class belongs to the AuthenticationMethod class. This indicates that EAP-
SIM is an authentication method. The EAP-SIM class has a challenge response and a
The EAP-SIM class, has the RAND and MAC keys as its challenge, and the
MAC_RAND and MAC_XRES keys as its challenge response, this is expressed by;
The MAC_RAND, the random message authentication code and MAC_XRES, the
expected response message authentication code, are described in the EAP-SIM class by
UserNetworkIdentity).
The triplets (RAND “AND” Kc “AND” XRES) are the triplets used by the EAP-SIM
hasTriplets XRES).
isAuthenticationMethodOf WLAN).
An Ontology for Generic Wireless Authentication 98
The following figure illustrates the conditions defined for the Subscriber class:
The Subscriber class only has individuals, as user data that belong to the UserData class.
The UserData class contains all personal details of a user, e.g. first name, last name,
address, country, etc…The following expression describes that the subscriber class only
hasPrivateUserIdentity PrivateUserIdentity).
An Ontology for Generic Wireless Authentication 99
MultimediaService).
The following figure illustrates the conditions defined for the IMSI class:
The IMSI class is a member of the Identity class, meaning that an IMSI is an identity.
The IMSI has a mobile station ISDN number as its number; IMSI(∀ hasNumber
MSISDN). The IMSI is made up of the following parts; the mobile station identification
An Ontology for Generic Wireless Authentication 100
number, and the mobile network code and the mobile country code. This is expressed by
hasPart MobileCountryCode).
The IMSI is an identity of a subscriber and is part of a user network identity, this is
UserNetworkIdentity) respectively.
The IMSI is stored in the HLR, AuC and the HSS, this is expressed by IMSI(∀
The following figure illustrates the asserted and inferred hierarchy in the ontology:
In the inferred hierarchy, the NAI is now the subclass of the PrivateUserIdentity class,
this is because in the asserted hierarchy it was defined to be a child of both the
PrivateUserIdentity, and the Identity class, which is a super class of the
PrivateUserIdentity class. The changes are marked in blue in the inferred hierarchy.
An Ontology for Generic Wireless Authentication 102
In order to create the ontology, an editor to edit ontologies was needed. The ontology
editor used for this thesis was the Protégé Tool version 3.0 available from
protégé.stanford.edu.
The Racer tool was used for reasoning and classification of the ontology. Several versions
of the racer tool exist; the current version is RacerPro available from www.racer-
systems.com. For the purpose of this thesis the racer reasoner version 1.7.23
For the graph visualization of the ontology, the GraphViz tool and the OWL-Viz plug-in
were used. GraphViz is available at http://www.graphviz.org/ and the OWL-Viz plug-
in is a component of the Protégé OWL plug-in from protégé.stanford.edu.
The installation of the Protégé tool is simple; after following the installation procedures
that appear on the screen, the editing tool is ready for use. For visualization, the
GraphViz Tool should be installed (follow screen instructions) and the OWL-Viz plugin
should configured to be used, this is done in the Protégé editor by clicking on Project Æ
Configure… and selecting the OWL-Viz Tab, and clicking on the OK button.
Racer is a .exe file, which should be run with Protégé or when classifying the ontology is
required. RacerPro can only be used upon registration and upon obtaining a license.
Two types of files for the generic wireless authentication ontology, namely a file with an
extension of .owl, which is the file described in the Web Ontology Language and a file
with an extension of .pprj, which is the protégé project file.
To load the .pprj file, simply click on File Æ Open and choose the file from the
appropriate directory.
To load the .owl file, click on File Æ Build New Project and then select the owl file from
the appropriate directory.
An Ontology for Generic Wireless Authentication 103
The following describes some of the problems encountered while developing the
ontology:
It was not possible to define an enumerated class. The complete ontology was
inconsistent upon the execution of the reasoner. The reason for the inconsistent
ontology was because of the definition of two enumerated classes as follows:
The f1AuCInput class, which was an enumerated class containing the inputs of the f1
algorithm on the AuC side. And the f1USIMInput class, which was an enumerated class
containing the inputs of the f1 algorithm on the USIM side. The intention of this was to
define a union of the f1 algorithm inputs, which takes the value of either the enumerated
class f1AuCInput class, or the enumerated class f1USIMInput.
Upon classification of the ontology (the execution of the reasoner), the ontology was
classified as an OWL-FULL ontology, and not as an OWL-DL ontology, therefore the
whole ontology was classified as inconsistent.
An Ontology for Generic Wireless Authentication 104
The ontology became consistent again after the removal of the enumerated classes.
A private user identity, consists of a user name, the “@” sign and the realm
(username@realm). Restrictions for the PrivateUserIdentity class have been defined, to
identify the parts belonging to a private user identity. The following expressions are some
hasPart Realm. When defining an additional restriction, stating that the “@” sign is also
inconsistency in the ontology occurred. This inconsistency stated that the ontology was
classified as an OWL-FULL ontology, and not as an OWL-DL ontology.
Figure 27: Defining a value for an Object Property - OWL FULL Error
Several inconsistencies appeared in the ontology when trying to define classes with the
someValuesFrom restriction.
For example, an inconsistency occurred, when defining that the PEAP class has an
authentication type that can be either password based, or challenge response based
authentication types, using the someValuesFrom restriction.
challenge response base classes, the PEAP class was no longer inconsistent. PEAP(∀
The same rule holds when trying to define that the f1 algorithm can be stored in either
the AuC or the HSS. f1(∃ isStoredIn (AuC ⊔ HSS), this rule returns an inconsistency.
Therefore, it was defined that the f1 algorithm is stored in BOTH the AuC and the HSS.
This type of error also occurred, if classes were declared as disjoint from each other.
When removing the disjointness of classes, it was possible to define some restrictions
with the someValuesFrom restriction. An example of which is given;
The A3 and f2 algorithms generate the responses XRES and RES on the AuC and USIM
side respectively. When defining that the A3 algorithm takes either XRES, or RES as its
output value, via the following expression; A3(∃ hasOutput XRES ⊔ RES) the A3 class
was consistent. However, when defining the same rule for the f1 algorithm; f1(∃
hasOutput XRES ⊔ RES) an inconsistency in both the A3 and f1 algorithm classes arose.
This was because the A3 and f1 algorithms were declared as disjoint from each other.
When removing the disjointness of the A3 and f1 algorithm, the reasoner did not classify
these classes as inconsistent. However, an A3 algorithm is not an f1 algorithm; therefore
they must be defined as disjoint.
The definition that a subscriber can have only one private user identity, and one or more
public user identities, was not possible without returning any inconsistencies.
Another attempt, was to define that each multimedia service is assigned to exactly one
public service identity, the following rule was defined; MultimediaService(=
hasPublicServiceIdentity =1) this rule did not hold true as well, and resulted in an
inconsistency.
An Ontology for Generic Wireless Authentication 107
6.1 Summary
This thesis addressed the issues of the current status in telecommunication networks
today, and discussed an approach of how to better restructure telecommunication
networks, in order to achieve less complexity and better data management. It also
addressed the separation of data, from the applications and proposed a common view
and understanding of physically and logically storing the data. In particular subscriber
data, which today, is distributed among several network nodes, and is not accessible by all
applications. Therefore, the Next Generation Profile Register was introduced as one
method of restructuring telecommunication networks today.
Providing a logical description of subscriber data was the motivation of this thesis. The
domains concerned for modelling the subscriber data, were the authentication specific
data of a certain subscriber in GSM, UMTS and WLAN networks.
The analysis of GSM, UMTS and WLAN networks was performed, especially in terms of
authentication, and in terms of what parameters of a subscriber is stored, and in which
profile registers.
In order to describe the data, it was also necessary to understand the relationships
between subscriber data, stored in the registers. It was also necessary to provide a
meaning for each term by defining rules.
defining restrictions for each class, indicating how classes are related to each other and
which individuals can belong to a certain class.
The ontology provides a logical description of the data, stored in profile registers of
GSM, UMTS and WLAN networks in one logical view.
Testing of the ontology was performed using a reasoning tool named Racer, which was
used to classify the ontology, and to check for inconsistencies in the ontology.
Using OWL to describe data provides better expressivity of data in comparison to other
modelling techniques. It also enables the re-use and sharing of data among domains, and
enables an easier translation of data between systems. This simplifies the complexity of
managing data between systems in current networks today, and solves the problem of
closed vendor specific systems. It also enables an easier integration of data from several
other domains and for the integration of future networks.
The ontology describes authentication specific data for GSM, UMTS and WLAN data.
However, subscriber data stored in WLAN networks needs to be further analysed,
further defined, and further described in the ontology. The relationships between the
concepts also need to be verified from an external point of view, and several discussions
upon the approach for defining the ontology from a domain expert point of view needs
to be performed [49].
Description of other types of data, in the above mentioned domains also needs to be
integrated into the ontology. E.g. data related to specific applications, location
management, etc…
An Ontology for Generic Wireless Authentication 109
The following figure illustrates the future view of the ontology with the integration of
several other domains:
CRM
Billing Admin
WLAN Bluetooth
GSM/UMTS
Other domains other than the ones previously mentioned include Bluetooth networks,
description and integration of TTYPE services, which describe the type of mobile device
a subscriber has (the type of screen; color, black and white, size, etc…). This is used to
determine what type of device a subscriber owns, in order to push multimedia services to
the subscriber. Other domains include, but are not limited to administrational data,
Customer Relationship Management (CRM) data, and Billing data.
Ontologies are mainly used and widespread in the bio-medical sector, where several
ontologies in this field have been developed, for the use of describing the human
anatomy and biological terms. Several other ontologies have been defined, which include
but are not limited to the following; ontologies for ethology, which describe the
behaviour of animals [63], ontologies for describing mathematical terms, ontologies that
describe the different parts of a camera, and also an ontology defined by the National
Cancer Institute, which is an NCI Thesaurus. More examples of ontologies can be found
in [64].
An Ontology for Generic Wireless Authentication 110
References
[3] Overview of the Global System for Mobile Communications, Report, John Scourias,
http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html, 9th September 2005.
[5] Valtteri Niemi and Kaisa Nyberg, UMTS Security, John Wiley & Sons, Ltd., 2003.
[6] GSM and UMTS Security, Presentation, Peter Howard, Vodafone Group R&D,
http://www.isg.rhul.ac.uk/msc/teaching/sc3/sec3slides/SC3-2004-7.pdf, 9th September
2005.
[7] EAP Methods for 802.11 Wireless LAN Security, Online-Education Tutorial,
International Engineering Consortium,
http://www.iec.org/online/tutorials/eap_methods/index.html, 9th September 2005.
[8] Designing a Secure WLAN with the HP-UX AAA RADIUS Server, Whitepaper,
Hewlett-Packard Development Company, L.P., http://docs.hp.com/en/WLANs-
AAA/WLANs-AAA.pdf, 9th September 2005.
[11] Numbering Plans Guide, E.212: International Identification Plan for Mobile
Terminals and Mobile Users, Article, SpraakMaker Telecom,
http://www.numberingplans.com/index.php?goto=guide&topic=E212, 9th September
2005.
An Ontology for Generic Wireless Authentication 111
[14] GSM Interception, White Paper, Lauri Pesonen, Helsinki University of Technology,
http://www.dia.unisa.it/professori/ads/corso-security/www/CORSO-
9900/a5/Netsec/netsec.html, 9th September 2005.
[15] Digital Cellular Telecommunications System (Phase 2+); Security Related Network
Functions (GSM 03.20 version 6.1.0 Release 1997), Technical Specification, ETSI,
Valbonne – France, http://www.3gpp.org/ftp/Specs/archive/03_series/03.20/, 9th
September 2005.
[17] Overview of the Universal Mobile Telecommunication System (Draft, July 2002),
Draft Overview, UMTSWorld.com,
http://www.umtsworld.com/technology/overview.htm, 9th September 2004.
[18] GSM and UMTS Technology System Architecture, Article, Mobileguru Ltd.,
http://www.mobileguru.co.uk/Mobile_Technology_globe.html, 9th September 2005.
[19] Security Mechanisms in UMTS, Paper, Stefan Pütz, Roland Schmitz, Tobias Martin,
http://fb1.hdm-stuttgart.de/skripte/Internetsecurity_2/Papers/UMTS-
SecurityMechanisms.pdf, 9th September 2005.
[20] Security in UMTS – Integrity, Paper, Telenor R&D, Runar Langnes, Tom E.
Aamodt, Trond Friisø, Geir Køien, Øyvind Eilertsen,
http://www.telenor.com/rd/pub/not01/sec_UMTS.PDF, 9th September 2005.
[24] 3rd Generation Partnership Project; Technical Specification Group Services and
System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 5), Technical
Specification, Valbonne – France,
http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/, 9th September 2005.
[28] Cisco SAFE: Wireless LAN Security in Depth – Version 2, White Paper, Sean
Convery, Darrin Miller, Sri Sundaralingam, Mark Doering, Pej Roshan, Stacey Albert,
Bruce McMurdo, Jason Halpern, Cisco Systems Inc., San Jose, California, USA,
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solution
s_white_paper09186a008009c8b3.shtml, 9th September 2005.
[29] A Comprehensive Review of 802.11 Wireless LAN Security and the Cisco Wireless
Security Suite, White Paper, Cisco Systems Inc.,
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_white_paper091
86a00800b469f.shtml, 9th September 2005.
[31] Wi-Fi Protected Access, WPA2 and IEEE 802.11, Questions and Answers, Cisco
Systems Inc.,
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item090
0aecd801e3e59.shtml, 9th September 2005.
[33] EAP Methods for 802.11 Wireless LAN Security, Online-Education Tutorial,
International Engineering Consortium,
http://www.iec.org/online/tutorials/eap_methods/, 9th September 2005.
An Ontology for Generic Wireless Authentication 113
[34] Remote Authentication Dial In User Service (RADIUS), RFC 2138, C. Rigney
Livingston, A. Rubens Merit, W. Simpson Daydreamer, S. Willens Livingston, The
Internet Engineering Taskforce, http://www.ietf.org/rfc/rfc2138.txt, 9th September
2005.
[35] Using RADIUS for WLAN Authentication, Part 1, Article, Lisa Phifer,
http://www.wi-fiplanet.com/tutorials/article.php/3114511, 9th September 2005.
[39] X.509 Certificates and Certificate Revocation Lists (CRLs), Article, Sun
Microsystems Inc., http://java.sun.com/j2se/1.3/docs/guide/security/cert3.html, 9th
September 2005.
[40] The Semantic Web, Article, Tim Berners Lee, James Hendler and Ora Lassila,
Scientific American, May 17, 2001,
http://www.scientificamerican.com/print_version.cfm?articleID=00048144-10D2-
1C70-84A9809EC588EF21, 12th September 2005.
[46] Using Ontologies, Enabling Knowledge Sharing and Reuse on the Semantic Web,
Technical Report, Jos de Bruijn, Digital Enterprise Research Institute, Austria,
http://www.deri.at/publications/techpapers/documents/DERI-TR-2003-10-29.pdf,
12th September 2005.
[49] Ontology Development 101: A Guide to Creating your First Ontology, Publication,
Natalya F. Noy and Deborah L. McGuinness, Stanford University, Stanford CA.,
http://protege.stanford.edu/publications/ontology_development/ontology101-noy-
mcguinness.html, 12th September 2005.
[50] Dieter Fensel, Ontologies: A Silver Bullet for Knowledge Management and
Electronic Commerce, Springer-Verlag Berlin Heidelberg 2004.
[52] OWL Web Ontology Language Guide, Recommendation, Michael K. Smith, Chris
Welty, Deborah L. McGuinness, W3C, http://www.w3.org/TR/owl-guide/, 12th
September 2005.
[53] A Practical Guide to Building OWL Ontologies Using the Protégé-OWL Plugin and
CO-ODE Tools, Edition 1.0, Guide, Matthew Horridge, Holger Knublauch, Alan
Rector, Robert Stevens, Chris Wroe, The University of Manchester, Stanford University,
http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf, 12th September
2005.
[55] The Protégé OWL Plugin: An Open Development Environment for Semantic Web
Applications, Publication, Holger Knublauch, Ray. W. Fergerson, Natalya F. Noy and
Mark A. Musen, Stanford Medical Informatics, Stanford School of Medicine, Stanford –
CA., http://protege.stanford.edu/plugins/owl/publications/ISWC2004-protege-
owl.pdf, 12th September 2005.
[56] RacerPro User’s Guide, Version 1.8, User Guide, Racer Systems GmbH & Co. KG,
www.racer-systems.com, 12th September 2005.
An Ontology for Generic Wireless Authentication 115
[58] Predicate Logic Terms and Symbols, Peter Suber, Earlham College, Course Material,
www.earlham.edu/~peters/courses/log/terms3.htm, 19th September 2005.
[60] Basic Description Logics, Course Material, Franz Baader, Werner Nutt,
www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf, 19th September 2005.
[64] Protégé OWL Plugin – Ontology editor for the Semantic Web, List of Ontologies,
http://protege.stanford.edu/plugins/owl/owl-library/index.html, 30th September 2005.
An Ontology for Generic Wireless Authentication 116
Abbreviations
CA Certifying Authority
CC Country Code
CK Cipher Key
CN Core Network
CRM Customer Relationship Management
CS Circuit Switched
‘
D
DL Description Logics
DRNC Drifting Radio Network Controller
K Secret Key
Kc Cipher Key
Ki Secret Key
PC Personal Computer
P-CSCF Proxy Call Session Control Function
PDA Personal Digital Assistant
PEAP Protected Extensible Authentication Protocol
PIN Personal Identification Number
PKI Public Key Infrastructure
PLMN Public Land Mobile Network
PPRJ Protégé Project Extension
PS Packet Switched
PSTN Public Switched Telephone Network
P-TMSI Packet-Temporary Mobile Subscriber Identity
Appendix A
IPAddress
UserName
Key DerivedKey AK
AMF
AUTN
IK
Kc
MAC
MAC_RAND
MAC_XRES
RES
XMAC
XRES
GeneratedKey RAND
SQN
StaticKey Ki
PrivateKey
PublicKey
Network GSM n/a
IMS
UMTS
WLAN
Number FixedTelephoneNumber n/a
HLRNumber
MSISDN
MobileSubscriberIdentificatio
nNumber
SubscriberNumber
IndividualSubscriberNumber
Service BasicService SMS
Speech
MutlimediaService AudioDownload
AudioStream
MMS
VideoDownload
VideoStream
WebBrowsing
SupplementaryService CallBarring
CallDivert
CallWaiting
ConferenceCall
CustomerCareBilling
DataService
UserData AccountHolder n/a
AccountNumber
BankCity
BankCode
BankCountry
City
Country
FirstName
An Ontology for Generic Wireless Authentication 122
HouseNumber
LastName
Password
PostalCode
SessionDuration
State
StreetName
Subscriber n/a n/a
An Ontology for Generic Wireless Authentication 123
Appendix B
The following appendix lists the properties and the inverse of each property if applicable:
hasIdentity isIdentityOf
hasInput isInputOf
hasIntegrityKey isIntegrityKeyOf
hasIssuerName isIssuerNameOf
hasMessageAuthenticationCode isMessageAuthenticationCodeOf
hasMultimediaService isMultimediaServiceOf
hasNetworkIdentity isNetworkIdentityOf
hasNumber isNumberOf
hasOutput isOutputOf
hasPart isPartOf
hasPassword isPasswordOf
hasPrivateUserIdentity isPrivateUserIdentityOf
hasPublicKey isPublicKeyOf
hasPublicServiceIdentity isPublicServiceIdentityOf
hasPublicUserIdentity isPublicUserIdentityOf
hasQuintets isQuintetsOf
hasRandNumber isRandNumberOf
hasRandomMessageAuthenticationCode isRandomMessageAuthenticationCodeOf
hasResponse isResponseOf
hasSecretKey isSecretKeyOf
hasSequenceNumber isSequenceNumberOf
hasSerialNumber isSerialNumberOf
hasSessionKey isSessionKeyOf
hasSignature isSignatureOf
hasSignatureAlgoritm isSignatureAlgoritmOf
hasSubject isSubjectOf
hasSubscriber isSubscriberOf
An Ontology for Generic Wireless Authentication 124
hasSupplementaryService isSupplementaryServiceOf
hasTriplets isTripletsOf
hasUserName isUserNameOf
hasValidityFrom isValidityFromFieldOf
hasValidityUntil isValdityToFieldOf
hasVersion isVersionOf
isAssociatedWith n/a
isSubscribedTo n/a
isStoredIn stores