Authentication & Authorization and Accounting (AAA) in Telecommunications Industry

Authentication
Authorization
Accounting
(AAA)
in
Telecommunications
Industry
Mojtaba HOUSHMAND
IT‐VAS Solutions Consultant & Trainer

AAA in Telecommunications Industry
Page | 2

Authentication & Authorization and Accounting (AAA)
in Telecommunications Industry
Mojtaba HOUSHMAND
IT‐VAS Solutions Consultant & Trainer
         https://www.linkedin.com/in/mojtaba‐houshmand‐280212128?trk=hp‐identity‐name
         mojtaba.houshmand@gmail.com
         (+98) 937 0241246

Released Date: 2017 – Feb
Initial Version: 1.0

Page | 3

Table of Contents

(1) Introduction - Network Overview........................................................................................ 6
1.1 Open System Interconnection Model (OSI) ......................................................................... 6
1.2 OSI Model............................................................................................................................. 6
1.3 TCP/IP Model....................................................................................................................... 7
(2) AAA Fundamentals & Functionalities................................................................................. 8
2.1 Authentication & Authorization ........................................................................................... 9
2.2 Accounting............................................................................................................................ 9
(3) AAA Information............................................................................................................... 10
3.1 WiMAX AAA..................................................................................................................... 10
3.2 Fixed AAA.......................................................................................................................... 10
(4) Usage of AAA servers in CDMA networks ...................................................................... 10
(5) AAA Server Structure........................................................................................................ 11
5.1 Service Control Point (SCP)............................................................................................... 11
5.2 Service Control Center (SCC) ............................................................................................ 11
5.3 Service Management System (SMS) .................................................................................. 11
(6) AAA Logical Topology..................................................................................................... 12
(7) AAA IP-CS/Eth-CS Solutions........................................................................................... 13
(8) AAA Message Flow........................................................................................................... 14
8.1 AAA Message Flow Diagram............................................................................................. 14
8.2 AAA Process Flow ............................................................................................................. 14
(9) Dynamic Authorization Extensions................................................................................... 15
9.1 Disconnect Message (DM) ................................................................................................. 15
9.2 Change of Authorization Message (CoA)........................................................................... 15
(10) Hotline Service................................................................................................................... 16
(11) Authentication Methods..................................................................................................... 17
(12) Extensible Authentication Protocol (EAP)........................................................................ 17
12.1 EAP Methods.................................................................................................................... 18
12.2 EAP-TLS Authentication Protocol ................................................................................... 18
12.2.1 EAP-TLS Message Flow (ETH-CS Solution)........................................................... 19
12.2.2 EAP-TLS Process Flow............................................................................................. 19
12.2.3 EAP-TLS Packet Flow Description........................................................................... 20

Page | 4

12.3 EAP-TTLS Authentication Protocol................................................................................. 26
12.3.1 EAP-TTLS Message Flow (IP-CS Solution)............................................................. 27
12.3.2 EAP-TTLS Process Flow........................................................................................... 27
12.3.3 EAP-TTLS Packet Flow Description......................................................................... 28
12.4 EAP-SIM Authentication Protocol ................................................................................... 33
12.5 EAP Authentication and Key Agreement (EAP-AKA).................................................... 34
12.6 Point to Point Protocol (PPP)............................................................................................ 34
12.7 Secure Sockets Layer (SSL) ............................................................................................. 35
12.8 Certificate Services........................................................................................................... 35
(13) RADIUS Protocol.............................................................................................................. 36
13.1 RADIUS Packet Format ................................................................................................... 36
13.2 RADIUS Packet Types ..................................................................................................... 37
13.3 Attribute Value Pairs (AVP)............................................................................................. 40
13.4 Accounting Status Type.................................................................................................... 41
13.5 Vendor Specific Attributes (VSAs) .................................................................................. 42
(14) Diameter Protocol.............................................................................................................. 43
14.1 Credit Control Messages................................................................................................... 43
14.1.1 Credit Control Request (CCR) Command................................................................. 44
14.1.2 Credit Control Answer (CCA) Command ................................................................. 44
14.2 Credit Control Application Overview............................................................................... 44
4.3 Credit Control AVP Table .................................................................................................. 46
(15) Prepaid Subscribers Flow .................................................................................................. 47
15.1 Prepaid Subscribers Message Flow .................................................................................. 47
15.2 Prepaid Subscribers Process Flow Description................................................................. 47
(16) Postpaid Subscribers Flow................................................................................................. 49
16.1 Postpaid Subscribers Message Flow................................................................................. 49
16.2 Postpaid Subscribers Process Flow Description............................................................... 49
(17) Call Detail Record (CDR).................................................................................................. 50
(18) CPE Configuration............................................................................................................. 50
18.1 Bridge Mode ..................................................................................................................... 50
18.2 Router Mode ..................................................................................................................... 50
(19) FreeRADIUS Application.................................................................................................. 51
19.1 Strengths ........................................................................................................................... 51
19.2 Weaknesses....................................................................................................................... 52

Page | 5

(20) Request for Comments (RFC) ........................................................................................... 52
20.1 RADIUS’s RFCs............................................................................................................... 53
20.2 Diameter’s RFCs............................................................................................................... 54
20.3 Extensible Authentication Protocol’s RFCs ..................................................................... 54
(21) GLOSSARY ...................................................................................................................... 55
(22) References.......................................................................................................................... 57

Page | 6

(1) Introduction - Network Overview
1.1 Open System Interconnection Model (OSI)

1.2 OSI Model
The recommendation X.200 describes seven layers, labeled 1 to 7. Layer 1 is the lowest layer in
this model.

Page | 7

1.3 TCP/IP Model
The Internet protocol suite is the conceptual model and set of communications protocols used
on the Internet and similar computer networks. It is commonly known as TCP/IP because the
most commonly‐used protocols in the suite are Transmission Control Protocol (TCP) and Internet
Protocol (IP).
The Internet protocol suite provides end‐to‐end data communication specifying how data should
be packetized, addressed, transmitted, routed and received.

Page | 8

(2) AAA Fundamentals & Functionalities
The basic application of AAA is presented in Session Layer (L5) and combined with Tunnel
Transport Layer Security (TLS or TTLS) of Presentation Layer (L6) which is using RADIUS &
Diameter Protocols of Application Layer (L7) of OSI model (Complex!).
 Authentication
 Authorization
 Accounting
AAA server is a server program that handles user requests for access to computer resources and,
for an enterprise, provides authentication, authorization, and accounting (AAA) services. The AAA
server typically interacts with network access and gateway servers and with databases and
directories containing user information. The current standard by which devices or applications
communicate with an AAA server is the Remote Authentication Dial‐In User Service (RADIUS).
The sequence of AAA Levels are Important to starting the procedures and getting success in each
steps is mandatory.
As the first process, Authentication provides a way of identifying a user, typically by having the
user enter a valid user name and valid password before access is granted. The process of
authentication is based on each user having a unique set of criteria for gaining access. The AAA
server compares a user's authentication credentials with other user credentials stored in a
database. If the credentials match, the user is granted access to the network. If the credentials
are at variance, authentication fails and network access is denied.
Following authentication, a user must gain Authorization for doing certain tasks. After logging
into a system, for instance, the user may try to issue commands. The authorization process
determines whether the user has the authority to issue such commands. Simply put,
authorization is the process of enforcing policies: determining what types or qualities of activities,
resources, or services a user is permitted. Usually, authorization occurs within the context of
authentication. Once you have authenticated a user, they may be authorized for different types
of access or activity.
The final plank in the AAA framework is Accounting, which measures the resources a user
consumes during access. This can include the amount of system time or the amount of data a
user has sent and/or received during a session. Accounting is carried out by logging of session
statistics and usage information and is used for authorization control, billing, trend analysis,
resource utilization, and capacity planning activities.

Page | 9

2.1 Authentication & Authorization
The user or machine sends a request to a Network Access Server (NAS) to gain access to a
particular network resource using access credentials. The credentials are passed to the NAS
device via the link‐layer protocol ‐ for example, Point‐to‐Point Protocol (PPP) in the case of many
dial‐up or DSL providers or posted in an HTTPS secure web form.
This request includes access credentials, typically in the form of username and password or
security certificate provided by the user. Additionally, the request may contain other information
which the NAS knows about the user, such as its network address or phone number, and
information regarding the user's physical point of attachment to the NAS.
The RADIUS server checks that the information is correct using authentication schemes such as
PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, other
information related to the request, such as the user's network address or phone number, account
status, and specific network service access privileges. Historically, RADIUS servers checked the
user's information against a locally stored flat file database. Modern RADIUS servers can do this,
or can refer to external sources commonly SQL, Kerberos, LDAP, or Active Directory servers to
verify the user's credentials.
Authentication and authorization characteristics in RADIUS are described in RFC 2865 while
accounting is described by RFC 2866.

2.2 Accounting
When network access is granted to the user by the NAS, an Accounting Start (a RADIUS
Accounting Request packet containing an Acct‐Status‐Type attribute with the value "start") is
sent by the NAS to the RADIUS server to signal the start of the user's network access. "Start"
records typically contain the user's identification, network address, point of attachment and a
unique session identifier.
Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct‐
Status‐Type attribute with the value "interim‐update") may be sent by the NAS to the RADIUS
server, to update it on the status of an active session. "Interim" records typically convey the
current session duration and information on current data usage.
Diameter Protocol is using for Accounting task which is customized RADIUS Protocol for Credit
Control Function.
Accounting is described in RFC 2866.

Page | 10

(3) AAA Information
AAA Servers depend on requirements & needs, can be deployed in 2 solutions for different
purpose:
 WiMAX AAA
 Fixed AAA
3.1 WiMAX AAA
WiMAX AAA will be authenticated CPE (WiMAX Modem) MAC Addresses & WiMAX ID Account
as Usernames & Password of user account in Layer 3 solution which is called IP‐CS Solution.
3.2 Fixed AAA
Fixed AAA will be Authenticated MAC Address of WiMAX Modem CPEs only at first and Username
and Password of subscribers through Captive Portal in the following. Due to first step, this
solution is called Eth‐CS because of Layer 2 Authentication. To Authenticate the Username and
Password in next step, WiMAX AAA is needed.

(4) Usage of AAA servers in CDMA networks
AAA servers in CDMA data networks are entities that provide Internet Protocol (IP) functionality
to support the functions of authentication, authorization and accounting. The AAA server in the
CDMA wireless data network architecture is similar to the HLR in the CDMA wireless voice
network architecture. Types of AAA servers:
Access Network AAA (AN‐AAA) – Communicates with the RNC in the Access Network (AN) to
enable authentication and authorization functions to be performed at the AN. The interface
between AN and AN‐AAA is known as the A12 interface.
Broker AAA (B‐AAA) – Acts as an intermediary to proxy AAA traffic between roaming partner
networks (i.e. between the H‐AAA server in the home network and V‐AAA server in the serving
network). B‐AAA servers are used in CRX networks to enable CRX providers to offer billing
settlement functions.
Home AAA (H‐AAA) – The AAA server in the roamer's home network. The H‐AAA is similar to the
HLR in voice. The H‐AAA stores user profile information, responds to authentication requests,
and collects accounting information.
Visited AAA (V‐AAA) – The AAA server in the visited network from which a roamer is receiving
service. The V‐AAA in the serving network communicates with the H‐AAA in a roamer's home
network. Authentication requests and accounting information are forwarded by the V‐AAA to the
H‐AAA, either directly or through a B‐AAA.

Page | 11

Current AAA servers communicate using the RADIUS protocol. As such, Telecommunications
Industry Association (TIA) specifications refer to AAA servers as RADIUS servers. However, future
AAA servers are expected to use a successor protocol to RADIUS known as Diameter.

(5) AAA Server Structure
The AAA Server consists of three kind of modules to do Authenticate, Authorize and Accounting
for each request.

5.1 Service Control Point (SCP)
This module is an interface between Access Service Network and Charging & Billing systems. 2
common protocol which are used in this Interface are:
RADIUS to connect to ASN‐GW or BRAS as Access Service Network
DIAMETER to connect to Charging & Billing Systems

5.2 Service Control Center (SCC)
Manage and Handle the incoming traffic and Authenticate & Authorize subscribers’ requests with
User Profile Database.
SCP can be a part of SCC module. In Carrier level of Telecommunication Network, SCP will be
separated.

5.3 Service Management System (SMS)
Manage and Handle the Provisioning Tasks and Generating Call Detail Records (CDR) and needed
to have a Web GUI application for User Management in different Level.

Page | 12

(6) AAA Logical Topology
AAA Servers used in WiMAX Technology with different ASN‐Gateways and Online Charging
System and different Protocols Interfaces is shown as below:

Page | 13

(7) AAA IP-CS/Eth-CS Solutions
AAA Servers used in WiMAX Technology with different ASN‐Gateways and Online Charging
System and different Protocols Interfaces in 2 WiMAX & Fixed solutions together is shown as
below:

Page | 14

(8) AAA Message Flow
8.1 AAA Message Flow Diagram

8.2 AAA Process Flow
Step 1: The user terminal sends wants to connect to network so CPE Modem in first step is needed
to authenticate by AAA servers through NAS (BRAS or ASN‐GW).
Step 2: NAS also play DHCP role usually in networks and assign the IP Address to the CPE Modem.
Step 3: The MAC Address of CPE Modem authenticate by WiMAX AAA at first and in following
Fixed AAA through Web Captive Portal will authenticate account of service by subscribers’ action
or WiMAX AAA will authenticate the account automatically without subscribers’ action.
Step 4: AAA Servers will authorize the subscribers based on their service and registered tariff
plans on Charging system.
Step 5: AAA servers start and keep interactive accounting message with NAS and meanwhile ask
Charging system to continue the calculation of usage quota accordingly so subscribers can
browse and enjoy the Internet in this step.

Page | 15

(9) Dynamic Authorization Extensions
This extension helps to create a feedback loop from the RADIUS server to the NAS. This in effect
swaps the roles of the client and server. The RADIUS server becomes a client to the NAS. Dynamic
authorization allows for the RADIUS server to inform the NAS about changes that have to be
made to a user's existing session on the NAS. There are two popular applications of this extension
which are described in RFC5176.
9.1 Disconnect Message (DM)
Also known as a Packet of Disconnect (POD), this is used to disconnect an existing user's session.
The RADIUS server sends the disconnect request and the NAS has to reply whether the
disconnection was successful or not.
9.2 Change of Authorization Message (CoA)
This message supplies data to change the authorization of an existing user's session. We can now
dynamically change the bandwidth limit per session for instance. This allows us to increase the
per session bandwidth when load on our Internet link decreases. When load on our Internet link
increases we can again decrease the per session bandwidth.
The following table lists the codes and names of the RADIUS packets involved:

CoA‐Request packets contain information for dynamically changing session authorizations.
Typically, this is used to change data filters.  The data filters can be of either the ingress or egress
kind, and are sent in addition to the identification attributes. The port used and packet format
are the same as those for Disconnect‐Request packets.
For either Disconnect‐Request or CoA‐Request packets UDP port 3799 is used as the destination
port.  For responses, the source and destination ports are reversed.  Exactly one RADIUS packet
is encapsulated in the UDP Data field.

The following attributes MAY be sent in a CoA‐Request:

Page | 16

Filter‐ID (11) ‐ Indicates the name of a data filter list to be applied for the session(s).
NAS‐Filter‐Rule (92) ‐  Provides a filter list to be applied for the session(s).

The NAS responds to a CoA‐Request sent by a Dynamic Authorization Client with a CoA‐ACK if the
NAS is able to successfully change the authorizations for the user session(s), or a CoA‐NAK if the
CoA‐Request is unsuccessful.  A NAS MUST respond to a CoA‐Request including a Service‐Type
Attribute with an unsupported value with a CoA‐NAK; an Error‐Cause Attribute with value
“Unsupported Service” SHOULD be included.

(10)Hotline Service
A hotline is a point‐to‐point communications link in which a service is automatically directed to
the preselected destination without any additional action by the user when the service package
goes unavailable.
An example for IT‐Telecommunication companies which are provides Internet, would be a Web
Page that automatically connect to emergency services to show to users the service pack is
finished or expired and needed to renew if you are still interested to serving the Internet. This
Web Page is free of charge service and usually the official website of service provider to introduce
and present different type of services.
Hotline page typically linked to Self‐Care service to give a chance to users to enable the service
again & suggest new Promotions and support Marketing to build up an Online Store or Launch
Survey.
In Addition: You can link the Self‐Care to Hotline Page to present these kind if Information: Service
Package Name, Package Status, Remaining Quota and Quota Usage Information. So through self‐
care the subscribers can renew, extend or charge the account by opening the Local Bank
Addresses for Online Payment way.

Page | 17

(11)Authentication Methods
There are a large number of authentication methods and protocols that can be used, depending
on the application and security requirements. In the following sections, we will discuss:
 The Password Authentication Protocol (PAP)
 Challenge Handshake Authentication Protocol (CHAP)
 Microsoft CHAP (MS‐CHAP)
 Kerberos
 Extensible Authentication Protocol (EAP)
o EAP‐TLS Authentication Protocol
o EAP‐TTLS Authentication Protocol
Basic Protocols:
 PPP
 SSL
 Certificate Service
 RADIUS
 Diameter

(12)Extensible Authentication Protocol (EAP)
Extensible Authentication Protocol, or EAP, is an authentication framework frequently used in
wireless networks and point‐to‐point connections. It is defined in RFC 3748, which made RFC
2284 obsolete, and was updated by RFC 5247.
EAP is an authentication framework for providing the transport and usage of keying material and
parameters generated by EAP methods. There are many methods defined by RFCs and a number
of vendor specific methods and new proposals exist. EAP is not a wire protocol; instead it only
defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP
messages within that protocol's messages.
EAP is in wide use. For example, in IEEE 802.11 (Wi‐Fi) the WPA and WPA2 standards have
adopted IEEE 802.1X with one‐hundred EAP Types as the official authentication mechanisms.
EAP is using different Methods which listed in next slide and will be describe some of them in
following:

Page | 18

12.1 EAP Methods
 Lightweight Extensible Authentication Protocol (LEAP)
 EAP Transport Layer Security (EAP‐TLS)
 EAP‐MD5
 EAP Protected One‐Time Password (EAP‐POTP)
 EAP Pre‐Shared Key (EAP‐PSK)
 EAP Password (EAP‐PWD)
 EAP Tunneled Transport Layer Security (EAP‐TTLS)
 EAP Internet Key Exchange v. 2 (EAP‐IKEv2)
 EAP Flexible Authentication via Secure Tunneling (EAP‐FAST)
 EAP Subscriber Identity Module (EAP‐SIM)
 EAP Authentication and Key Agreement (EAP‐AKA)
 EAP Authentication and Key Agreement prime (EAP‐AKA')
 EAP Generic Token Card (EAP‐GTC)
 EAP Encrypted Key Exchange (EAP‐EKE)

12.2 EAP-TLS Authentication Protocol
EAP‐Tunneled Transport Layer Security (EAP‐TTLS) is an EAP protocol that extends TLS.
EAP‐TTLSv1 utilizes TLS with the Inner Application extension (TLS/IA), as its underlying protocol.
In TLS/IA, the TLS handshake is followed by an exchange of messages with record type Inner
Application, in which an arbitrary exchange of messages between client and server is conducted
under the confidentiality and integrity protection afforded by the TLS handshake. The Inner
Application messages that are exchanged between client and server are encoded as sequences
of Attribute‐Value‐Pairs (AVPs) from the RADIUS/Diameter namespace. Use of the
RADIUS/Diameter namespace provides natural compatibility between TLS/IA applications and
widely deployed AAA infrastructures. This namespace is extensible, allowing new AVPs and, thus,
new applications to be defined as needed, either by standards bodies or by vendors wishing to
define proprietary applications. The AVPs exchanged between client and server typically provide
for client authentication, or mutual client‐server authentication. However, the AVP exchange
accommodates any type of client‐server exchange, not just authentication, though
authentication may often be the prerequisite that allows other exchanges to proceed. For
example, EAP‐TTLSv1 may be used to verify endpoint integrity, provision keying material for use
in separate data channel communications (e.g. IPsec), provide client credentials for single sign‐
on, and so on.
The client can, but does not have to be authenticated via a CA‐signed PKI certificate to the server.
This greatly simplifies the setup procedure since a certificate is not needed on every client. After
the server is securely authenticated to the client via its CA certificate and optionally the client to

Page | 19

the server, the server can then use the established secure connection ("tunnel") to authenticate
the client. It can use an existing and widely deployed authentication protocol and infrastructure,
incorporating legacy password mechanisms and authentication databases, while the secure
tunnel provides protection from eavesdropping and man‐in‐the‐middle attack.
12.2.1 EAP-TLS Message Flow (ETH-CS Solution)

12.2.2 EAP-TLS Process Flow
The process of the EAP‐TLS authentication is described as follows:
Step 1 to step 2: The user terminal sends the Request message with identity in EAP attribute, AAA
receives the EAP authentication request message for the first time and delivers the
authentication type (EAP‐TTLS) to the user terminal.
Step 3 to step 4: If the EAP authentication type that the MS supports is different from the
authentication type that the AAA delivers, for example EAP‐TLS, the user terminal and the AAA
negotiate the authentication type. Otherwise, proceed to step 5.

Page | 20

Step 5 to step 6: The user terminal sends the Request message with ClientHello in EAP
authentication. After receiving the EAP‐TLS authentication request, the AAA send the
ServerHello/server certificate/ServerHelloDone to the user terminal.
Step 7 to step 8: The user terminal authenticates the certificate of AAA, if it’s ok, the user terminal
sends device certificate to AAA and AAA authenticate the device certificate.
Step 9 to step 10: The AAA receives the message requesting to end the handshake (with no data
in EAP attribute). Then the AAA delivers the master secret key (MSK).
12.2.3 EAP-TLS Packet Flow Description
The First Message:
The access request from ASN‐GW to AAA, the type should be Identity.

Page | 21

The access challenge from AAA to ASN‐GW, the type would be like below.

The Second Message:
The access request from ASN‐GW to AAA, for ETH‐CS, the EAP‐TLS will be used by MS and AAA,
so MS will send the below message.

Page | 22

The access challenge from AAA to ASN‐GW, the will be like below, the message means AAA
support EAP‐TLS.

The Third Message:
The access request from ASN‐GW to AAA, the MS send ClientHello message in EAP to AAA:

The access challenge from AAA to ASN‐GW, AAA send the ServerHello message, certificate,
certificate request and Server Hello Done to ASN‐GW. If the certificate is bigger, the message
may be divided into two or more EAP parts. In this example, the message is divided into two
parts, it means AAA will send two Radius message to MS, please see the 4th
message. If MS
receives the message, it will check the red part, and if it is 0xC0, it means it should waits for
another EAP fragment.

Page | 23

The Forth Message:
The access request from ASN‐GW to AAA, if MS find there are other EAP fragments in last
Challenge message, it will send a null message in EAP attribute as below to AAA.

The access challenge from AAA to ASN‐GW, AAA send another EAP fragment in Radius message.
The red part in picture means it’s the last EAP fragment:

Page | 24

The Fifth Message:
The access request from ASN‐GW to AAA, the MS authenticate the AAA’s certificate
successfully, and send the device certificate to AAA.

The access challenge from AAA to ASN‐GW, AAA authenticate the MS’s certificate successfully
and send the response message:

Page | 25

The Sixth Message:
The access request from ASN‐GW to AAA, it’s the last request message with no data in EAP
attribute:

The access accept from AAA to ASN‐GW, AAA send the access accept message with the
attributes of template to ASN‐GW, it means the authentication is ended.

Page | 26

12.3 EAP-TTLS Authentication Protocol
EAP‐Tunneled Transport Layer Security (EAP‐TTLS) is an EAP protocol that extends TLS.
EAP‐TTLSv1 utilizes TLS with the Inner Application extension (TLS/IA), as its underlying protocol.
In TLS/IA, the TLS handshake is followed by an exchange of messages with record type Inner
Application, in which an arbitrary exchange of messages between client and server is conducted
under the confidentiality and integrity protection afforded by the TLS handshake. The Inner
Application messages that are exchanged between client and server are encoded as sequences
of Attribute‐Value‐Pairs (AVPs) from the RADIUS/Diameter namespace. Use of the
RADIUS/Diameter namespace provides natural compatibility between TLS/IA applications and
widely deployed AAA infrastructures. This namespace is extensible, allowing new AVPs and, thus,
new applications to be defined as needed, either by standards bodies or by vendors wishing to
define proprietary applications. The AVPs exchanged between client and server typically provide
for client authentication, or mutual client‐server authentication. However, the AVP exchange
accommodates any type of client‐server exchange, not just authentication, though
authentication may often be the prerequisite that allows other exchanges to proceed. For
example, EAP‐TTLSv1 may be used to verify endpoint integrity, provision keying material for use
in separate data channel communications (e.g. IPsec), provide client credentials for single sign‐
on, and so on.
The client can, but does not have to be authenticated via a CA‐signed PKI certificate to the server.
This greatly simplifies the setup procedure since a certificate is not needed on every client. After
the server is securely authenticated to the client via its CA certificate and optionally the client to
the server, the server can then use the established secure connection ("tunnel") to authenticate
the client. It can use an existing and widely deployed authentication protocol and infrastructure,

Page | 27

incorporating legacy password mechanisms and authentication databases, while the secure
tunnel provides protection from eavesdropping and man‐in‐the‐middle attack.
12.3.1 EAP-TTLS Message Flow (IP-CS Solution)

12.3.2 EAP-TTLS Process Flow
The process of the EAP‐TTLS authentication is described as follows:
Step 1 to step 2: The AAA receives the EAP authentication request message for the first time and
delivers the authentication type and authentication mode according to configurations.

Page | 28

Step 3: If the EAP authentication type that the user terminal supports is different from the
authentication type that the AAA delivers, the user terminal and the AAA negotiate the
authentication type. Otherwise, proceed to step 4.
Step 4 to step 5: The user terminal sends the EAP authentication request according to its
supported EAP authentication type. After receiving the EAP‐TTLS authentication request, the AAA
performs the EAP‐TTLS authentication.
Step 6 to step 7: After the user terminal and AAA check the certificates of each other, the security
tunnel is set up successfully.
Step 8 to step 9: The AAA receives the MS‐CHAP‐V2 authentication request and checks the
password.
Step 10 to step 11: The AAA receives TTLS/TLS: no data authentication request, checks the
information such as the user information and template, and then delivers the MSK.

12.3.3 EAP-TTLS Packet Flow Description
The First Message:
The access request from ASN‐GW to AAA, the type should be Identity.

The access challenge from AAA to ASN‐GW, the type would be like below.

Page | 29

The Second Message:
The access request from ASN‐GW to AAA, for IP‐CS, the EAP‐TLLS will be used by MS and AAA,
so MS will send ClientHello message to AAA.

The access challenge from AAA to ASN‐GW, AAA send the ServerHello message, certificate and
Server Hello Done to ASN‐GW. If the certificate is bigger, the message may be divided into two
or more EAP parts. In this example, the message has only one fragment.  If the authmode is
configured the both direction authentication on AAA, the certificate request will be included in
EAP attribute, and then the next message from MS will send device certificate to AAA.

Page | 30

The Third Message:
The access request from ASN‐GW to AAA, the MS will authenticate the certificate firstly, after
that the MS will check if it need send the device certificate to AAA from the last response
message. If no need, the MS will send the below message to AAA.

Page | 31

The access challenge from AAA to ASN‐GW, AAA response the below message:

The Forth Message:
The access request from ASN‐GW to AAA, the MS will send the Application Data in EAP
attribute to AAA. In this step, the real username and password will be included in Application
Data, but they will be encrypted, so we can’t see them in package.

The access challenge from AAA to ASN‐GW, after AAA receives the username and password,
AAA will authenticate them. If the username, password and MSID are not correct, AAA will
response with Reject message. If it’s correct, AAA will response with Application Data as below.

Page | 32

The Fifth Message:
The access request from ASN‐GW to AAA, it’s the last request message with no data in EAP
attribute:

The access accept from AAA to ASN‐GW, AAA send the access accept message with the
attributes of template to ASN‐GW, it means the authentication is ended.

Page | 33

12.4 EAP-SIM Authentication Protocol
EAP for GSM Subscriber Identity Module (EAP‐SIM) is used for authentication and session key
distribution using the Subscriber Identity Module (SIM) from the Global System for Mobile
Communications (GSM).
GSM cellular networks use a subscriber identity module (SIM) card to carry out user
authentication. EAP‐SIM use a SIM authentication algorithm between the client and
Authentication, Authorization and Accounting (AAA) server providing mutual authentication
between the client and the network.
In EAP‐SIM the communication between the SIM card and the Authentication Centre (AuC)
replaces the need for a pre‐established password between the client and the AAA server.
The EAP‐SIM mechanism specifies enhancements to GSM authentication and key agreement
whereby multiple authentication triplets can be combined to create authentication responses
and session keys of greater strength than the individual GSM triplets. The mechanism also
includes network authentication, user anonymity support, result indications, and a fast re‐
authentication procedure.
EAP‐SIM is described in RFC 4186.

Page | 34

12.5 EAP Authentication and Key Agreement (EAP-AKA)
EAP for UMTS Authentication and Key Agreement is used for authentication and session key
distribution using the Universal Mobile Telecommunications System (UMTS) UMTS Subscriber
Identity Module (USIM). EAP AKA is defined in RFC 4187 which specifies an Extensible
Authentication Protocol (EAP) mechanism for authentication and session key distribution that
uses the 3rd generation Authentication and Key Agreement mechanism, specified for Universal
Mobile Telecommunications System (UMTS) in [TS33.102] and for CDMA2000 in [S.S0055‐A].
UMTS and CDMA2000 are global 3rd generation mobile network standards that use the same
AKA mechanism.
Subscribers of mobile networks are identified with the International Mobile Subscriber Identity
(IMSI) [TS23.003].  The IMSI is a string of not more than 15 digits.  It is composed of a Mobile
Country Code (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and a Mobile
Subscriber Identification Number (MSIN) of not more than 10 digits.  MCC and MNC uniquely
identify the GSM operator and help identify the AuC from which the authentication vectors need
to be retrieved for this subscriber.
Internet AAA protocols identify users with the Network Access Identifier (NAI) [RFC4282].  When
used in a roaming environment, the NAI is composed of a username and a realm, separated with
"@" (username@realm).  The username portion identifies the subscriber within the realm.

12.6 Point to Point Protocol (PPP)
In computer networking, Point‐to‐Point Protocol (PPP) is a data link protocol used to establish a
direct connection between two nodes. It can provide connection authentication,
transmission encryption (using ECP, RFC 1968), and compression.
PPP is used over many types of physical networks including serial cable, phone line, trunk
line, cellular telephone, specialized radio links, and fiber optic links such as SONET. PPP is also
used over Internet access connections. Internet service providers (ISPs) have used PPP for
customer dial‐up access to the Internet, since IP packets cannot be transmitted over
a modem line on their own, without some data link protocol. Two derivatives of PPP, Point‐to‐
Point Protocol over Ethernet (PPPoE) and Point‐to‐Point Protocol over ATM (PPPoA), are used
most commonly by Internet Service Providers (ISPs) to establish a Digital Subscriber Line (DSL)
Internet service connection with customers.
PPP Abstract RFC1661:
The Point‐to‐Point Protocol (PPP) provides a standard method for transporting multi‐protocol
datagrams over point‐to‐point links.  PPP is comprised of three main components:
      1. A method for encapsulating multi‐protocol datagrams.

Page | 35

      2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data‐link
connection.
      3. A family of Network Control Protocols (NCPs) for establishing and configuring different
network‐layer protocols.

12.7 Secure Sockets Layer (SSL)
The SSL protocol is another Internet standard, often used to provide secure access to Web sites,
using a combination of public key technology and secret key technology. Secret key encryption
(also called symmetric encryption) is faster, but asymmetric public key encryption provides for
better authentication, so SSL is designed to benefit from the advantages of both. It is supported
by Microsoft, Netscape, and other major browsers, and by most Web server software, such as IIS
and Apache. SSL operates at the application layer of the DoD networking model. This means
applications must be written to use it, unlike other security protocols (such as IPsec) that operate
at lower layers. The Transport Layer Security (TLS) Internet standard is based on SSL.SSL
authentication is based on digital certificates that allow Web servers and clients to verify each
other’s identities before they establish a connection. (This is called mutual authentication.) Thus,
two types of certificates are used: client certificates and server certificates.

12.8 Certificate Services
Digital certificates consist of data that is used for authentication and securing of communications,
especially on unsecured networks (for example, the Internet). Certificates associate a public key
to a user or other entity (a computer or service) that has the corresponding private key.
Certificates are issued by certification authorities (CAs), which are trusted entities that “vouch
for” the identity of the user or computer. The CA digitally signs the certificates it issues, using its
private key. The certificates are only valid for a specified time period; when a certificate expires,
a new one must be issued. The issuing authority can also revoke certificates. Certificate services
are part of a network’s Public Key Infrastructure (PKI). Standards for the most commonly used
certificates are based on the X.509 specifications.

Page | 36

(13)RADIUS Protocol

Remote Authentication Dial‐In User Service (RADIUS) is a networking protocol that provides
centralized Authentication, Authorization, and Accounting (AAA or Triple A) management for
users who connect and use a network service. RADIUS was developed by Livingston Enterprises,
Inc. in 1991 as an access server authentication and accounting protocol and later brought into
the Internet Engineering Task Force (IETF) standards.
Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used
by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks,
and integrated e‐mail services.
RADIUS is a client/server protocol that runs in the application layer, and can use either TCP or
UDP as transport. Network access servers, the gateways that control access to a network, usually
contain a RADIUS client component that communicates with the RADIUS server. RADIUS is often
the back‐end of choice for 802.1X authentication as well.
The RADIUS server is usually a background process running on a UNIX or Microsoft Windows
server and is an AAA protocol which manages network access in the following two‐step process,
also known as a AAA transaction. AAA stands for authentication, authorization and accounting.
Authentication and authorization characteristics in RADIUS are described in RFC 2865 while
accounting is described by RFC 2866.

13.1 RADIUS Packet Format
The data between a RADIUS server and a RADIUS client is exchanged in RADIUS packets. The data
fields are transmitted from left to right. In below the RADIUS Packet Diagram is presented.

Each RADIUS packet contains the following information:

Page | 37

Code: Each packet is identified by a code. This field is one octet in size. The value of this code
determines certain characteristics and requirements of the packet. The following table can be
used as a reference to list some of the current defined codes for RADIUS packets:

Knowing these codes is beneficial when working with RADIUS.
Identifier: The identifier field is one octet; it helps the RADIUS server match requests and
responses and detect duplicate requests.
Length: The length field is two octets; it specifies the length of the entire packet.
Authenticator: The authenticator field is 16 octets. The most significant octet is transmitted first;
it is used to authenticate the reply from the RADIUS server. Two types of authenticators are as
follows:
 Request‐Authentication: Available in Access‐Request and Accounting‐Request packets
 Response‐Authenticator: Available in Access‐Accept, Access‐Reject, Access‐Challenge,
and Accounting‐Response packets.

13.2 RADIUS Packet Types
The following list defines the various types of RADIUS packet types that can contain attribute
information:
Access‐Request: Sent from a client to a RADIUS server. The packet contains information that
allows the RADIUS server to determine whether to allow access to a specific network access
server (NAS), which will allow access to the user. Any user performing authentication must
submit an Access‐Request packet. Once an Access‐Request packet is received, the RADIUS server
must forward a reply.

Page | 38

Access‐Accept: Once a RADIUS server receives an Access‐Request packet, it must send an Access‐
Accept packet if all attribute values in the Access‐Request packet are acceptable. Access‐Accept
packets provide the configuration information necessary for the client to provide service to the
user.
Access‐Reject: Once a RADIUS server receives an Access‐Request packet, it must send an Access‐
Reject packet if any of the attribute values are not acceptable.
Access‐Challenge: Once the RADIUS server receives an Access‐Accept packet, it can send the
client an Access‐Challenge packet, which requires a response. If the client does not know how to
respond or if the packets are invalid, the RADIUS server discards the packets. If the client
responds to the packet, a new Access‐Request packet should be sent with the original Access‐
Request packet.
Accounting‐Request: Sent from a client to a RADIUS accounting server, which provides
accounting information. If the RADIUS server successfully records the Accounting‐Request
packet, it must submit an Accounting Response packet.
Accounting‐Response: Sent by the RADIUS accounting server to the client to acknowledge that
the Accounting‐Request has been received and recorded successfully.
The following screenshot shows the Access‐Request packet send from the RADIUS client:

Page | 39

The following screenshot shows the RADIUS server responding to this request with an Access‐
Accept packet:

See the following output from Wireshark that shows a typical accounting transaction. It starts
with an Accounting‐Request from the client:

Page | 40

The server then replies to the client with an Accounting‐Response:

Accounting‐Request packets are also required to include certain AVPs. Let us take a look at
important AVPs used in accounting.

13.3 Attribute Value Pairs (AVP)
AVPs are the workhorse of the RADIUS protocol. AVPs can be categorized as either check or reply
attributes. Check attributes are sent from the client to the server. Reply attributes are sent from
the server to the client.
Attributes serve as carriers of information between the client and server. They are used by the
client to supply information about itself as well as the user connecting through it. They are also
used when the server responds to the client. The client can then use this response to control the
user's connection based on the AVPs received in the server's response.
The RADIUS standard attributes are listed in the following table. For information about other
RADIUS attributes and their use, see Internet Engineering Task Force (IETF) Request for
Comments (RFCs) 2865 and 2866.

Type
Value
Attribute Name
Type
Value
Attribute Name
Type
Value
Attribute Name
1 User‐Name 21 (unassigned) 40 Acct‐Status‐Type
2 User‐Password 22 Framed‐Route 41 Acct‐Delay‐Time
3 CHAP‐Password 23 Framed‐IPX‐Network 42 Acct‐Input‐Octets
4 NAS‐IP‐Address 24 State 43 Acct‐Output‐Octets
5 NAS‐Port 25 Class 44 Acct‐Session‐Id
6 Service‐Type 26 Vendor‐Specific 45 Acct‐Authentic

Page | 41

7 Framed‐Protocol 27 Session‐Timeout 46 Acct‐Session‐Time
8 Framed‐IP‐Address 28 Idle‐Timeout 47 Acct‐Input‐Packets
9 Framed‐IP‐Netmask 29 Termination‐Action 48 Acct‐Output‐Messages
10 Framed‐Routing 30 Called‐Station‐Id 49 Acct‐Terminate‐Cause
11 Filter‐Id 31 Calling‐Station‐Id 50 Acct‐Multi‐Session‐Id
12 Framed‐MTU 32 NAS‐Identifier 51 Acct‐Link‐Count
13 Framed‐Compression 33 Proxy‐State 52 Acct‐Input‐Gigawords
14 Login‐IP‐Host 34 Login‐LAT‐Service 53 Acct‐Output‐Gigawords
15 Login‐Service 35 Login‐LAT‐Node 54 (unassigned)
16 Login‐TCP‐Port 36 Login‐LAT‐Group 55 Event‐Timestamp
17 (unassigned) 37 Framed‐AppleTalk‐Link 60 CHAP‐Challenge
18 Reply‐Message 38 Framed‐AppleTalk‐Network 61 NAS‐Port‐Type
19 Callback‐Number 39 Framed‐AppleTalk‐Zone 62 Port‐Limit
20 Callback‐Id 63 Login‐LAT‐Port

13.4 Accounting Status Type
Acct‐Status‐Type (Type40) packet indicates the status of the user or the NAS. An NAS may send
interim updates on the usage of a certain session. in order to do this the NAS sets the type to
Interim‐Update. This allows us to follow usage trends in approximately real time.
The RADIUS server does not check up on an NAS. If an NAS has informed the RADIUS server about
a newly connected user (status type Start) and thereafter the NAS breaks down completely, the
records on the RADIUS server will still indicate that the user is connected to the NAS when in fact
the user is not. These records are referred to as rogue entries. To reduce rogue entries, it is good
practice for an NAS to send an Accounting‐Off followed by an Accounting‐On packet just after
boot‐up and also an Accounting‐Off packet before shutting down. This action will cause RADIUS
to close all open records for any user connected to the particular NAS allowing a clean start.
Rogue entries are particularly problematic when you limit the number of sessions a user can
have. If the component limiting the sessions of a user makes use of data containing rogue entries
the calculations will not be accurate.
The following decimal to type table can be used as reference for the possible status values:

Page | 42

13.5 Vendor Specific Attributes (VSAs)
The IETF specifies Vendor‐Specific Attributes (VSA) as a method for communicating vendor‐
specific information between NASs and RADIUS servers. VSAs allows vendors to define their own
attributes. The format of the attribute definitions is basically the same as for normal AVPs with
the addition of a vendor field. VSAs are sent as the value of AVP Type 26. This means that VSAs
are an extension of AVPs and carried inside AVPs.
Any Vendor who has a Private Enterprise Number registered with IANA may create their own
Vendor‐Specific Attributes. Support for these VSA's can be added to FreeRADIUS simply by
creating their own dictionary. The NAS will silently ignore any VSAs that are not meant for it.
Some vendors publish their VSAs, but this is not required.
This can then be consulted to determine the capabilities of the RADIUS implementation of their
equipment.

Page | 43

(14)Diameter Protocol

There is also an improved RADIUS protocol called Diameter (A word play—twice as good as
RADIUS). A major reason for this is probably the fact that the many enhancements that Diameter
was supposed to bring are already covered by the various RADIUS extensions. There is, for
instance, the RadSec protocol that transports RADIUS over TCP and TLS. This makes RADIUS scale
better in roaming environments.
A Diameter Application is not a software application but is a protocol based on the Diameter base
protocol defined in RFC 6733 (Obsoletes: RFC 3588). Each application is defined by an application
identifier and can add new command codes and/or new mandatory AVPs (Attribute‐Value Pair).
Adding a new optional AVP does not require a new application.
The Diameter base protocol defines the minimum requirements for an AAA protocol. Diameter
Applications can extend the base protocol by adding new commands, attributes, or both.
Diameter is an authentication, authorization, and accounting protocol for computer networks. It
evolved from and replaces the much less capable RADIUS protocol that preceded it.
Diameter Applications extend the base protocol by adding new commands and/or attributes,
such as those for use with the Extensible Authentication Protocol (EAP).
Diameter security is provided by IPsec or TLS. The IANA has assigned TCP and SCTP port number
3868 to Diameter.
Diameter Credit‐Control Application (DCCA, RFC 4006)

14.1 Credit Control Messages
This section defines new Diameter Message Command‐Code values that MUST be supported by
all Diameter implementations that conform to this specification.  The Command Codes are as
follows:

   Command‐Name               Abbrev.    Code
   ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
   Credit‐Control‐Request        CCR        272
   Credit‐Control‐Answer         CCA        272

Page | 44

14.1.1 Credit Control Request (CCR) Command
The Credit‐Control‐Request message (CCR) is indicated by the command‐code field being set to
272 and the 'R' bit being set in the Command Flags field.  It is used between the Diameter credit‐
control client and the credit‐control server to request credit authorization for a given service.

14.1.2 Credit Control Answer (CCA) Command
The Credit‐Control‐Answer message (CCA) is indicated by the command‐code field being set to
272 and the 'R' bit being cleared in the Command Flags field.  It is used between the credit‐control
server and the Diameter credit‐control client to acknowledge a Credit‐Control‐Request
command.

14.2 Credit Control Application Overview
The credit authorization process takes place before and during service delivery to the end user
and generally requires the user's authentication and authorization before any request is sent to
the credit‐control server.  The credit‐control application defined in this specification supports
two different credit authorization models: credit authorization with money reservation and
credit authorization with direct debiting.  In both models, the credit‐control client requests credit
authorization from the credit‐control server prior to allowing any service to be delivered to the
end user.
In the first model, the credit‐control server rates the request, reserves a suitable amount of
money from the user's account, and returns the corresponding amount of credit resources.  Note
that credit resources may not imply actual monetary credit; credit resources may be granted to
the credit control client in the form of units (e.g., data volume or time) to be metered.
In contrast, credit authorization with direct debiting is a single transaction process wherein the
credit‐control server directly deducts a suitable amount of money from the user's account as
soon as the credit authorization request is received. Upon receipt of a successful credit
authorization answer, the credit‐control client allows service delivery to the end user. This
process is accomplished with the one‐time event.  Session state is not maintained.
The following diagram illustrates the use of authorization/authentication messages to perform
the first interrogation.  The parallel accounting stream is not shown in the figure.

Page | 45

Page | 46

4.3 Credit Control AVP Table
The table in this section is used to represent which credit‐control applications specific AVPs
defined in this document are to be present in the credit‐control messages.

Attribute Name
Command Code
Attribute Name
Command Code
CCR CCA CCR CCA
Acct‐Multi‐Session‐Id 0‐1 0‐1 Origin‐Realm 1 1
Auth‐Application‐Id 1 1 Origin‐State‐Id 0‐1 0‐1
CC‐Correlation‐Id 0‐1 0 Proxy‐Info 0 0
CC‐Session‐Failover 0 0‐1 Redirect‐Host 0 0
CC‐Request‐Number 1 1 Redirect‐Host‐Usage 0 0‐1
CC‐Request‐Type 1 1 Redirect‐Max‐Cache‐Time 0 0‐1
CC‐Sub‐Session‐Id 0‐1 0‐1 Requested‐Action 0‐1 0
Check‐Balance‐Result 0 0‐1 Requested‐Service‐Unit 0‐1 0
Cost‐Information 0 0‐1 Route‐Record 0 0
Credit‐Control‐Failure‐
Handling
0 0‐1 Result‐Code 0 1
Destination‐Host 0‐1 0 Service‐Context‐Id 1 0
Destination‐Realm 1 0 Service‐Identifier 0‐1 0
Direct‐Debiting‐Failure‐
Handling
0 0‐1 Service‐Parameter‐Info 0 0
Event‐Timestamp 0‐1 0‐1 Session‐Id 1 1
Failed‐AVP 0 0 Subscription‐Id 0 0
Final‐Unit‐Indication 0 0‐1 Termination‐Cause 0‐1 0
Granted‐Service‐Unit 0 0‐1 User‐Equipment‐Info 0‐1 0
Multiple‐Services‐
Credit‐Control
0 0 Used‐Service‐Unit 0 0
Multiple‐Services‐
Indicator
0‐1 0 User‐Name 0‐1 0‐1
Origin‐Host 1 1 Validity‐Time 0 0‐1

Page | 47

(15)Prepaid Subscribers Flow
15.1 Prepaid Subscribers Message Flow
(ASN‐GW <‐> AAA <‐> OCS)

15.2 Prepaid Subscribers Process Flow Description
The service process is described as follows:
1. An MS requests the AAA to perform EAP authentication.
2. After the authentication is successful, the AAA sends a CCR (Initial) message to the OCS,
applying for a quota for the MS.
3. The OCS pre‐calculates the service usage available for the MS according to the balance and
charging policy. Then the OCS sends a CCA (Initial) message to the AAA. The CCA (Initial) message
contains the available service usage.
4. The AAA sends an authentication response message to the ASN‐GW according to the reserved
fee and authentication results. The response message contains the QoS information about the
service flow and the available service volume of the MS.

Page | 48

5. If ASN‐GW enable the account message, the ASN‐GW may sends the account request (start)
message to AAA;
6. The AAA write the CDR according to account request message and send account response to
ASN‐GW;
7. After detecting that the service usage of the MS reaches the monitoring value, the ASNGW
sends a request message to the AAA for updating the quota on line.
8. After receiving the request message for updating the quota on line, the AAA sends a CCR
(Update) request message to the OCS, requesting the OCS to calculate the usage and reserve the
quota for the next period.
9. The OCS settles the fee according to the service usage of the subscriber in the last period,
reserves the available service usage for the next period, and sends a CCA (Update) message to
the AAA. The CCA (Update) message contains the service usage available for the subscriber.
10. The AAA sends an authentication response message to the ASN‐GW according to the reserved
fee. The response message contains the service usage available for this service flow.
11. After a period of account message, the ASN‐GW will send account request (interim) to AAA.
ASN‐GW;
13. The subscriber goes offline.
14. If ASN‐GW enable the account message, the ASN‐GW may sends the account request (stop)
message to AAA;
ASN‐GW.
16. The ASN‐GW sends an Online Access Request message to the AAA, requesting the AAA to
stop the MS.
17. The AAA sends a CCR (Term) request message to the OCS for calculating the service usage of
the last period.
18. The OCS calculates the service usage of the last period and sends a CCA (Term) message to
the AAA. The CCA (Term) message contains the calculation result.
19. The AAA returns a response message to the ASN‐GW according to the calculation result,
indicating that the accounting is stopped.

Page | 49

(16)Postpaid Subscribers Flow
16.1 Postpaid Subscribers Message Flow

16.2 Postpaid Subscribers Process Flow Description
The service process is as follows:
1. The EAP‐TTLS authentication is performed between the MS and the AAA.
2. After the authentication is successful, the AAA sends an Access Accept/EAP‐Success message
to the ASN‐GW.
3. The ASN‐GW sends an accounting start message to the AAA.
4. The AAA records the CDR and returns an accounting response message.
5. When the interim accounting period of the service flow is reached, the ASN‐GW sends an
interim accounting message to the AAA.
7. The subscriber powers off the MS and gets disconnected from the Internet.
8. The ASN‐GW sends an accounting stop message to the AAA.

Page | 50

(17)Call Detail Record (CDR)
A Call Detail Record (CDR) is a data record produced by a telephone exchange or other
telecommunications equipment that documents the details of a telephone call or other
telecommunications transaction (e.g., text message) that passes through that facility or device.
The record contains various attributes of the call, such as Start or End Time, Duration Quota,
Volume Quota, Session ID, Completion Status, Source or Destination numbers. It is the
automated equivalent of the paper toll tickets that were written and timed by operators for long‐
distance calls in a manual telephone exchange and Internet Usage in Mobile Telecommunication
Company.
Call detail records serve a variety of functions. For telephone service providers, they are critical
to the production of revenue, in that they provide the basis for the generation of telephone bills.
For law enforcement, call detail records provide a wealth of information that can help to identify
suspects, in that they can reveal details as to an individual's relationships with associates,
communication and behavior patterns, and even location data that can establish the
whereabouts of an individual during the entirety of the call.
Example:

(18)CPE Configuration
By Customer Premises Equipment which is called CPE or Router Modem, and based on the
Modem Firmware options, you can connect to network with two below methods:
 Bridge Mode (Eth‐CS)
 Router Mode (IP‐CS)
18.1 Bridge Mode
In Bridge mode, IP address will be assign to CPE in Network Operator IP address range.
To web browsing, it’s needed to use Captive Portal to login your own Account (CPE Independent).
18.2 Router Mode
In Router mode, IP address will assign to CPE in class c: 192.168.0.1/24 with CPE Inner DHCP
service and CPE provide a NAT network.
After Power CPE on, and Authentication pass, Internet will be available to use automatically.

Page | 51

(19)FreeRADIUS Application
FreeRADIUS is a modular, high performance free RADIUS suite developed and distributed under
the GNU General Public License, version 2, and is free for download and use. The FreeRADIUS
Suite includes a RADIUS server, a BSD‐licensed RADIUS client library, a PAM library, an Apache
module, and numerous additional RADIUS related utilities and development libraries.
In most cases, the word "FreeRADIUS" refers to the free open source RADIUS server from this
suite.
FreeRADIUS is the most popular open source RADIUS server and the most widely deployed
RADIUS server in the world. It supports all common authentication protocols, and the server
comes with a PHP‐based web user administration tool called dialupadmin or daloRADIUS. It is the
basis for many commercial RADIUS products and services, such as embedded systems, RADIUS
appliances that support Network Access Control, and WiMAX. It supplies the AAA needs of many
Fortune‐500 companies, Telco's, and Tier 1 ISPs. It is also widely used in the academic community,
including eduroam. The server is fast, feature‐rich, modular, and scalable.
Modules included with the server core support LDAP, MySQL, PostgreSQL, Oracle, and many
other databases. It supports all popular EAP authentication types, including PEAP and EAP‐TTLS.
More than 100 vendor dictionaries are included, ensuring compatibility with a wide range of NAS
devices.
19.1 Strengths
FreeRADIUS has many strengths, which contributed to its popularity. Let us look at some of them:
Open source: This is not just free as in beer; you are free to adapt, change, expand, and fix
whatever is required. FreeRADIUS is released under the GNU General Public License (GPL).
Modular: FreeRADIUS comes with lots of modules included. You can also create your own
modules to be used by FreeRADIUS. Modules are included for LDAP integration or SQL back‐ends.
There are also Perl and Python modules, which allow you to unleash these two powerful scripting
languages in FreeRADIUS.
Used by the masses: Someone does not get fired for choosing FreeRADIUS. It is easy to get
references from ISPs and large companies who have very large user counts in their FreeRADIUS
deployments. FreeRADIUS conducted a survey to determine the usage and deployment size of
FreeRADIUS. The detailed results of this survey are available on request from them.
Active community: Because FreeRADIUS has such a large user base, chances are someone else
has experienced the same hurdles as you. FreeRADIUS has active mailing lists with searchable
archives.

Page | 52

Available info: The information may not be in one locality, but it is available, and just has to be
found. There are lots of Wiki pages full of detail. There are also man pages and configuration files,
which are well written and easy to follow.
Active development: FreeRADIUS follows the "release early, release often" motto. New
developments around the RADIUS protocol are most likely to be supported first in FreeRADIUS.
You can look forward to one or more new FreeRADIUS releases annually.
Commercial support: The core developers of FreeRADIUS offer commercial support. There are
also various people knowledgeable in FreeRADIUS who should be able to supply paid support.
Network RADIUS SARL has a nice website with more details on paid support:
http://networkradius.com/.
Availability: FreeRADIUS is available for various operating systems. All of the popular Linux
distributions include it as part of their available packages. It is even available for Windows! Under
the downloads page of the FreeRADIUS website there are links to binary packages for various
operating systems.

19.2 Weaknesses
There is no such thing as a perfect piece of software; FreeRADIUS is no exception. Here are some
of its weaknesses:
Complexity: This is the only real weakness. FreeRADIUS offers an all‐inclusive piece of software
with many configuration options. If you are not careful you can end up with a broken system.
Vulnerabilities: A few vulnerabilities were reported in the past but they have been fixed since
then. You can read more about those vulnerabilities and what version of FreeRADIUS contained
them at the following: http://freeradius.org/security.html.

(20)Request for Comments (RFC)
A Request for Comments (RFC) is a type of publication from the Internet Engineering Task Force
(IETF) and the Internet Society (ISOC), the principal technical development and standards‐setting
bodies for the Internet.
An RFC is authored by engineers and computer scientists in the form of a memorandum
describing methods, behaviors, research, or innovations applicable to the working of the Internet
and Internet‐connected systems. It is submitted either for peer review or simply to convey new
concepts, information, or (occasionally) engineering humor. The IETF adopts some of the
proposals published as RFCs as Internet Standards.

Page | 53

Request for Comments documents were invented by Steve Crocker in 1969 to help record
unofficial notes on the development of ARPANET. RFCs have since become official documents of
Internet specifications, communications protocols, procedures, and events.
20.1 RADIUS’s RFCs
RFC Title Date published
RFC 2548 Microsoft Vendor‐specific RADIUS Attributes   Mar‐99
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS   Apr‐00
RFC 2865 Remote Authentication Dial In User Service (RADIUS)   Jun‐00
RFC 2866 RADIUS Accounting   Jun‐00
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support   Jun‐00
RFC 2868 RADIUS Attributes for Tunnel Protocol Support   Jun‐00
RFC 2869 RADIUS Extensions   Jun‐00
RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices   Jul‐00
RFC 3162 RADIUS and IPv6   Aug‐01
RFC 3579 RADIUS Support for EAP   Sep‐03
RFC 3580 IEEE 802.1X RADIUS Usage Guidelines   Sep‐03
RFC 4014
RADIUS Attributes Suboption for the DHCP Relay Agent Information
Option
Feb‐05
RFC 4372 Chargeable User Identity   Jan‐06
RFC 4675 RADIUS Attributes for Virtual LAN and Priority Support   Sep‐06
RFC 4679 DSL Forum Vendor‐Specific RADIUS Attributes   Sep‐06
RFC 4818 RADIUS Delegated‐IPv6‐Prefix Attribute   Apr‐07
RFC 4849 RADIUS Filter Rule Attribute   Apr‐07
RFC 5090 RADIUS Extension for Digest Authentication   Feb‐08
RFC 5176 Dynamic Authorization Extensions to RADIUS   Jan‐08
RFC 5607 RADIUS Authorization for NAS Management   Jul‐09
RFC 5997 Use of Status‐Server Packets in the RADIUS Protocol   Aug‐10
RFC 6218
Cisco Vendor‐Specific RADIUS Attributes for the Delivery of Keying
Material
Apr‐11
RFC 6421
Crypto‐Agility Requirements for Remote Authentication Dial‐In User
Service (RADIUS)
Nov‐11
RFC 6613 RADIUS over TCP   May‐12
RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS   May‐12

Page | 54

20.2 Diameter’s RFCs
RFC 3589
Diameter Command Codes for Third Generation Partnership Project
(3GPP) Release 5.
Sep‐03
RFC 4004 Diameter Mobile IPv4 Application. Aug‐05
RFC 4006 Diameter Credit‐Control Application. Aug‐05
RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application. Aug‐05
RFC 4740 Diameter Session Initiation Protocol (SIP) Application. M. Nov‐06
RFC 5224 Diameter Policy Processing Application. Mar‐08
RFC 5447
Diameter Mobile IPv6: Support for Network Access Server to Diameter
Server Interaction.
Feb‐09
RFC 5516
Diameter Command Code Registration for the Third Generation
Partnership Project (3GPP) Evolved Packet System (EPS).
Apr‐09
RFC 5624 Quality of Service Parameters for Usage with Diameter. Aug‐09
RFC 6733 Diameter Base Protocol. Oct‐12
RFC 6737 The Diameter Capabilities Update Application. Oct‐12
RFC 7155 Diameter Network Access Server Application. Apr‐14

20.3 Extensible Authentication Protocol’s RFCs
RFC2284 PPP Extensible Authentication Protocol (EAP). Mar‐98
RFC2484 PPP LCP Internationalization Configuration Option. Jan‐99
RFC3748 Extensible Authentication Protocol (EAP). Jun‐04
RFC4017
Extensible Authentication Protocol (EAP) Method Requirements for
Wireless LANs.
Mar‐05
RFC4072 Diameter Extensible Authentication Protocol (EAP) Application. Aug‐05
RFC4186
Extensible Authentication Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP‐SIM).
Jan‐06
RFC4187
Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP‐AKA).
Jan‐06
RFC4746
Extensible Authentication Protocol (EAP) Password Authenticated
Exchange.
Nov‐06
RFC5281
Extensible Authentication Protocol Tunneled Transport Layer Security
Authenticated Protocol Version 0 (EAP‐TTLSv0).
Aug‐08
RFC5448
Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP‐AKA').
May‐09
RFC6678
Requirements for a Tunnel‐Based Extensible Authentication Protocol
(EAP) Method.
Jul‐12
RFC7055 A GSS‐API Mechanism for the Extensible Authentication Protocol. Dec‐13
RFC7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1. May‐14
RFC7458
Extensible Authentication Protocol (EAP) Attributes for Wi‐Fi Integration
with the Evolved Packet Core.
Feb‐15

Page | 55

(21)GLOSSARY

3GPP 3rd Generation Partnership Project
AAA Authentication, Authorization and Accounting
AES Advanced Encryption System
AF Application Function
AK Authentication Key
AKA Authentication and Key Agreement
AVP Attribute‐Value Pair
ASN‐GW Access Server Network Gateway
CHAP Challenge Handshake Protocol
DCCA Diameter Credit Control Application
DIAMETER Extension of RADIUS protocol
DPI Deep Packet Inspection
DSC Diameter Signaling Controller
EAP Extensible Authentication Protocol
EAP‐AKA EAP with Authentication and Key Agreement
EAP‐FAST EAP with Flexible Authentication via Secure Tunneling
EAP‐GTC EAP using Generic Token Cards
EAP‐IKEv2 EAP using Internet Key Exchange version 2
EAPOL   EAP over LAN
EAP‐PSK EAP using pre‐shared key
EAP‐SIM EAP using Subscriber Identity Module
EAP‐TLS EAP using Transport Level Security
EMSK Extended Master Session Key
EPC Evolved Packet Core
GGSN Gateway GPRS Serving Node
GSM Global System for Mobile Communications
GSM‐SIM SIM cards used in GSM phones
ID Identification
IEEE Institution of Electrical and Electronics Engineers
IKE Internet Key Exchange
IMS IP Multimedia Subsystem
IPsec IP Security
IPX Novell Netware
KDK Key Derivation Key
LAT Local Area Terminal protocol
LCP Logical Control Protocol
LDAP Lightweight Directory Access Protocol
LM LAN Manager

Page | 56

LTE Long Term Evolution
MAC Media Access Control
MD5 Message Digest 5
MS Mobile Station
MS‐CHAP Microsoft Challenge Handshake Protocol
MTU Maximum Transmission Unite
NAS Network Access Server
NIC Network Interface Card
OMC Operation & Maintenance Center
OCS Online Charging System
PAC Protected Access
PAP Password authentication protocol
PEAP Protected EAP
PIN Personal Identification Number
PPP Point‐to‐Point Protocol
QoS Quality of Service
RADIUS Remote Authentication Dial‐In User Service
RAND Random challenge
RFC Request for Comment
SIM Subscriber identity module
SMPP Short Message Peer to Peer
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
TLS Transport Level Security
TTLS Tunneled Transport Level Security

Page | 57

(22)References

(1) FreeRADIUS (http://wiki.freeradius.org/Home)
(2) ETSI (www.etsi.org)
(3) IETF RFCs (https://ietf.org/)
(4) Wikipedia The Free Encyclopedia (https://www.wikipedia.org/)
(5) http://www.cisco.com
(6) FreeRADIUS Beginner’s Guide (Dirk van der Walt)

Authentication & Authorization and Accounting (AAA) in Telecommunications Industry

More Related Content

What's hot (20)

Similar to Authentication & Authorization and Accounting (AAA) in Telecommunications Industry (20)

Recently uploaded (20)

Authentication & Authorization and Accounting (AAA) in Telecommunications Industry