AAA Diameter Application Third-Party Architecture

advertisement
2005 IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications
Third-Party AAA Architecture and
Diameter Application for 4GWW
New
Fintan McEvoy, Ivan Ganchev, Mairtin O'Droma
Department of Electronic and Computer Engineering
University of Limerick
Limerick, IRELAND
(ivan.ganchev, fintan.mcevoy, mairtin.odroma) @ ul.ie
Abstract- This paper' proposes a new third-party AAA (3PAAA) supporting architecture, with which to serve a more
Consumer-based Business Model (CBM) for fourth generation
wireless world (4GWW). A new Diameter 3P-AAA application is
suggested as a base signaling protocol solution option to serve this
architecture. The command and response messages necessary for
this application are identified and elaborated.
Index Terms- Always Best Connected and Served (ABC&S),
Third-Party Authentication, Authorization and Accounting (3PAAA), Consumer-based Business Model (CBM), Diameter
protocol, 4G wireless world (4GWW), context transfer.
I. INTRODUCTION
Optical backbone, IPv6 and Mobile Terminals (MT) are
three basic elements that will likely characterise
communication networks in the foreseeable future. Within this
environment a Mobile User (MU) will desire to be always best
connected and served (ABC&S). Such a dynamic system will
demand seamless user mobility and flexible user
authentication, authorization and accounting (AAA). However
the Subscriber-based Business Models (SBM) used in wireless
networks today place the User Home Access Network
Provider (UHANP) at the center as both the effective manager
of all the user's wireless communication activities and the
supplier of part of these wireless communication services.
These models do not fully benefit the user who desires to be
ABC&S, always getting the best value for money and having
access to unlimited services. The need to have administrative
and management support in place, and a full support for the
provision of services and network access before being able to
start seeking 'home user accounts', also constrains new
UHANPs from entering the market. University of Limerick
researchers have suggested the need for a new Consumerbased Business Model (CBM) wireless networking
i This publication has emanated from research conducted with the
financial support of Science Foundation freland under the Basic
Research Grant Ref. No. 041BR/E0082.
2 www.anwire.org
978-3-8007-2909-8/05/$20.00 ©2005 IEEE
infrastructure, [2]. This proposal has been taken up by
ANWIRE2 (Academic Network for Wireless Internet Research
in Europe) and incorporated into their proposal for future
wireless networking architecture, GAIA, [1, 2]. This new
wireless networking paradigm gets around problems such as
those already mentioned.
At the heart of this new CBM model is the new third-party
AAA service provider (3P-AAA SP), (Figure 1). The Mobile
User (MU) has an agreement with the 3P-AAA SP, much like
s/he would have with a credit card company. All billing
information for the MU is filtered through the 3P-AAA SP. As
can be seen in the model, all other service providers (xSP,
VASP) and access network providers (ANP) have a prearranged business agreement (B.A.) that 3P-AAA SP will
handle all billing.
Figure 1: CBM with a 3P-AAA SP at the centre
In existing mobile wireless networks, the security profile of
users is handled within an AAA framework. The AAA server
is located in the access network, and an AAA signaling
protocol is used between the AAA server, the current access
router and the mobile host (MH).
In future 4G networks, the main issue will be to reuse this
existing AAA framework in the heterogeneous communication
environment by introducing a 3P-AAA management system as
illustrated in the CBM model. This will allow easy and
1984
2005 IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications
automatic AAA of users in a heterogeneous environment
comprising different access network providers exploiting
different access network technologies.
In the past AAA and mobility operations have often been
carried out as separate operations. In reality these activities are
interdependent. If a MH moves into a new network it must be
authenticated and authorized for that network. It has been
observed that round trip times (RTTs) can be reduced if the
two operations are knitted together [3]. In our architectural
framework, mobility information is piggybacked on AAA
messages.
The AAA signaling protocol to support 3P-AAA
management system suggested in this paper, and in [13], is a
new Diameter 3P-AAA application. This paper clearly defines
the messages used in such an application to handle user
mobility, user security and user privacy.
II. MOBILITY & AAA IN 4GWW
Various emerging protocols may play a part in the fourth
generation wireless world (4GWW), e.g. Mobile IPv6
(MIPv6) [4], Hierarchical MIPv6 (HMIPv6) [5] and the
Diameter protocol [6]. Used alone each of these protocols
have their own strengths and weaknesses, however, a hybrid of
all these protocols may emphasize their various strengths and
eliminate their individual weaknesses.
MIPv6: This is a network layer protocol invented by IETF
to allow mobile devices to move between networks while
maintaining reachability and on-going connections between
mobile terminal (MT) and correspondent nodes (CNs) [4].
This is achieved by sending Binding Update (BU) packages to
the Home Agent (HA) and CNs upon movement from one
domain to another. There is a significant delay from time of
MH movement into a new domain to MH completed
registration with the home domain. For this reason it is
desirable to perform BUs only when absolutely necessary.
HMIPv6:
When using MIPv6, if a MH changes its
attachment point, even if remaining in the same domain, the
process of BUs still has to take place. Consequently the IETF
has introduced Hierarchical Mobile IPv6 (HMIPv6) as an
extension to the MIPv6 protocol. HMIPv6 uses the idea of a
local Mobility Anchor Point (MAP) within foreign domains to
reduce signaling requirements.
Diameter: In recent years the IETF has been developing a
new AAA protocol, called 'Diameter' [6], with the intention
of it becoming the successor of the RADIUS protocol [7].
Diameter is completely backwards compatible with RADIUS
and retains the basic RADIUS format but attempts to fix all its
various deficiencies. The Diameter standard consists of a base
protocol that can be extended in order to allow new access
methods. To date IETF's AAA working group has defined the
Diameter base protocol [6] and some extension applications
http://www.unik.no/personer/paalee/
978-3-8007-2909-8/05/$20.00 ©2005 IEEE
such as the Extensible Authentication Protocol (EAP) [8],
NAS [9] and MIPv4 applications [10]. All basic functionality
common to all applications and services is implemented in the
base protocol while all additional functionality is defined
within the different applications. The base protocol assumes a
peer-to-peer communications model as opposed to the clientserver model used by RADIUS. In Diameter command /
response pairs are used for communication and TCP and SCTP
for reliable transport. The base protocol design, among other
features, incorporates a large attribute-value pairs (AVP)
space, support for vendor AVPs and commands, reliability
provided by underlying SCTP, a well-defined failover scheme,
support for unsolicited messages to clients, integrity and
confidentiality at the AVP level and end-to-end security.
For our new 3P-AAA management architecture, described
below, we consider the development of a new Diameter 3PAAA application described in Section IV. All Diameter nodes
will run this application on top of a full implementation of
Diameter base protocol. As mentioned in the introduction, it
has been noted that combining the tasks of mobility and AAA
can reduce RTTs. MIPv6 supported by HMIPv6 is to be used
to enable mobility, therefore, this new Diameter 3P-AAA
application needs to define relevant MIPv6, HMIPv6
command / response messages.
III. NEW 3P-AAA MANAGEMENT ARCHITECTURE
Figure 2 depicts the proposed 3P-AAA architectural
framework. Access technology is arbitrary, e.g. WLAN,
2G/2.5G/3G etc. but the core structure remains the same. All
traffic is IPv6 based. Every MT is enabled with HMIPv6.
Every MU owns a smart card (inserted into the MT
currently used), containing a user access profile with details
such as: the users' network access identifier (NAI) [11], access
network preferences, and authentication and authorization
details - all these essential pieces of information for a MU to
enter and use any access network.
y0
/MAP 1 \
AR1
\
AR2
~~3P-AAAS
3\
MAP92\
AR3
k'
MT
Figure 2: 3P-AAA architectural framework
Any movement of the MT within the local domain is
supported by HMIPv6. The MAP structure (MAP I/ MAP2 /
3P-MAP) makes it possible to avoid the heavy signaling
associated with MIPv6. All MAPs also function as routers,
however, not all routers serve as MAPs (e.g. Access Routers -
1 985
ARI, AR2, AR3). The 3P-MAP also functions
3P-AAA
client, which uses the Diameter 3P-AAA application for all
security, accounting and inter-domain mobility operations.
3P-AAA Server (3P-AAAS), also enabled with Diameter
3P-AAA application, will answer all 3P-AAA requests from
3P-MAP. It will examine the users NAI. It may be the case
that the request must be redirected to another server on the
next hierarchical level up. This type of hierarchical setup is
discussed in the next section. In the case where 3P-AAA
server does contain the user account for the MU it will perform
any operations requested or forward any requested
conficguration information according to local policy. 3P-AAA
server may need to contact other configuration or policy
servers in this process. It will also inform the 3P-MAP on how
to deal with requests that cannot be authenticated.
as a
3P-AAA Hierarchy
Figure 2 above depicts the 3P-AAA architectural framework as
having one single 3P-AAA central server. This is suitable for
small-scale adoption of the scheme but for global large-scale
introduction, a hierarchy of such 3P-AAA servers would likely
exist. In figure 3, such a hierarchy is illustrated, showing
separate 3P-AAA servers in use on Local, Regional, National,
and International level.
LocalMAPLoaMALclMP
Local
MP
Loc:al
LOcal
(AAA client)
LocalMA
Lo al
(AAA client)
(AAA client)
(AAA client)
Figure 3: 3P-AAA hierarchy
All
users
enroll
with
International
3P-AAA
server
(Enrollment Entity). For each user the International 3P-AAA
Enrollment Entity issues users a smart card and accompanying
PIN.
Many
National,
Regional
and
Local
3P-AAA
outgoing data packets and to store binding update information
for MTs when requested by paired 3P-AAA servers. Regional
and Local MAPs incorporate an AAA client. These MAPs can
demand an accounting session for incoming or outgoing
packets for any user.
All billing information for a user is centralized. In this case
billing information is stored by the International 3P-AAA
server. Accounting information is collected by the individual
Local 3P-AAA servers and forwarded to the international
server via regional and national servers.
Context transfer
One important area that has not been mentioned thus far is that
of context transfer. Recently it was recognized within IETF
that a new protocol is needed to transfer state information
between edge mobility devices. This protocol would enable a
MT to regain full service more quickly after handoff. IETF
formed the SEAMOBY WG that in turn identified certain
services as candidates for context transfer. Included among
them was AAA. SEAMOBY has defined a Context Transfer
Protocol (CTP) [12] to carry AAA and other service state
information between nodes. In addition to SEAMOBY's work
it is also recognized that carrying out such context transfer in a
proactive manner would be useful [14]. Without a doubt such
ability can benefit a user in reaching the goal or being ABC&S
within our 3P-AAA hierarchy. For this reason our Diameter
3P-AAA application also incorporates context transfer
functionality. SEAMOBY only defines CTP for operation
between AR, however, from study it seems apparent that
operation between 3P-AAA servers would require a similar set
of messages. These messages are defined in the next section.
IV. NEW DIAMETER 3P-AAA APPLICATION
In the case where a usage scenario is not able to fit into an
existing Diameter application, a new Diameter application
needs to be defined, in particular for a 3P-AAA management
scheme. Some of the basic 3P-AAA management functionality
can be performed by Diameter base protocol but new messages
and attributes need to be defined for authentication,
authorization (AA) and mobility, context transfer, user privacy
functions and accounting. Table 1 suggests the commands and
responses that need to be defined for this new Diameter 3PAAA application.
servers
(Acquirers) exist. They authenticate user clients when a valid
PIN is received for the smart card inserted. Local 3P-AAA
servers receive AAA requests from users currently residing in
adjoining
access
networks
(ANs).
If
informnation
needed
to
satisfy a certain request is not available at the local 3P-AAA
server, this server forwards the request to the 3P-AAA server
at
a regional level, and so on up, if necessary, to the national
and
international levels until sufficient
satisfy this request.
The basic task of each MAP is
information
is found to
to route incoming and
1986
Tablel: New Proposed Diameter Messages
Use
Message
AA and Mobility Messages
3P-AA-MH- Access request with a Binding Update (BU)
request piggybacked.
Request
Sent in reply to a 3P-AA-MH-Re quest. It
3P-AA-MH- indicates whether access request and BU
were successful. If successful it may also
Answer
carry configuration info.
2005 IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications
3P-MAP-
Sent by a 3P-AAA server to the local MAP
to request a BU for a MT.
3P-MAPBinding-
Sent in reply to a 3P-MAP-Binding-Request.
It must indicate whether binding was
successful or not.
BindingRequest
Answer
AAA servers and 3P-MAPs exist. Figure 4 illustrates a
network access scenario. UserA is from England and wishes to
have access to services in Limerick AN.
Context Transfer Messages [12]
Context Transfer Activate Request (CTAR) is
3P-CTAA
3P-CPD
3P-CTDR
3P-CTC
3P-CTReq
Privacy
Response
Limerick
Limerick
Munster
Router
3P-MAP
3P-AAAS
3P-AAAS
f
originally sent by the MT in the direction of
3P-MAP; forwarded to 3P-AAA server by
3P-MAP.
Context Transfer Activate Acknowledge
(CTAA) can be used to acknowledge CTAR.
Context Transfer Data (CTD) is used to
send AAA context between 3P-AAA servers.
Context Transfer Data Reply (CTDR) is
used to indicate success or failure in transfer
of AAA context.
Context Transfer Cancel (CTC) is used by
3P-AAA server to cancel the process, if
transfer of context cannot be done in a timely
fashion.
If MT is already in the new domain when
sending 3P-CTAR, this message is sent by
3P-AAA server in new domain to request
AAA context from 3P-AAA server in old
Ireland
3P3-AAAS
Inter.
Inter.
3P-AAAS
-.----
LCoA
_ ..
Access
equest
__!3P-
Pro
.._._._._.
-Mobile-H
ed toward
st-Reques
Message
Intenation
3P-AAA
3-
In
trnational P-AAA iss ies
MAP-Bin0 tg-Reques
ternationa MAP rep) SI
MAP-Bind sg-Answei
.Access
.
$eply
-
A-mobile-h ,st-Answet Message
oxied tow
ds Local 3F -AAA
I-
Figure 4: 3P-AAA register example
Upon entering Limerick AN UserA must first configure
Regional Care of Address (RCoA) and Local CoA (LCoA).
UserA then directs an Access Request towards Limerick 3P-
Privacy Messages
Privacy
Access
MT
Ci nfiguratio of
IH) fIPRCoA ndi
domain.
Request
UserA
Sent by 3P-MAP to request an adjustment or
privacy settinrs for MU.
Indicates success or failure in adjustment of
privacy settings for MU.
It worth noticing that there is no need for new accounting
be defined as the Accounting Request and
Accounting Response messages already defined in the
Diameter base protocol are sufficient [6].
New AVPs will need to be defined for every message
including the abovementioned accounting messages. This
topic, however, is outside the scope of this paper.
In the modem Internet age user privacy has become a
controversial issue. The Privacy Request and Privacy
Response messages are envisaged as working, similar to online
instant messaging application privacy settings. For example a
user will be able to request to be 'invisible' for a certain time
period.
MAP. Limerick 3P-MAP compiles access and mobile
registration information into 3P-AA-Mobile-Host-Request
message. Since UserA's access information has to be obtained
from Intemational 3P-AAA server, the message is proxied in
this direction. If the International 3P-AAA server is satisfied
with UserA's access information, UserA's current location is
registered (MAP-Binding-Request/Answer). A reply is then
proxied in UserA's direction. With this AA process completed
UserA can now begin accessing services available.
messages to
Example Usage Scenario
Assume that a hierarchical system such as illustrated in
Figure 3 exists internationally and is to be set up in Ireland.
Ireland can be broken down into four regions: Munster,
Leinster, Connaught, and Ulster. Each region can be broken
down into localities. Munster consists of Clare, Limerick,
Waterford, Tipperary, Cork, and Kerry. Within each of the
individual localities a local 3P-AAA server and 3P-MAP are
placed to service users. Additionally regional and national 3P-
978-3-8007-2909-8/05/$20.00 ©2005 IEEE
V. CONCLUSION
This paper has presented development considerations of a new
third-party authentication, authorization and accounting (3PAAA) management architecture for a 4GWW and proposes a
preliminary solution for a new signaling hybrid 3P-AAA
protocol. The solution is constructed on the foundations of
existing protocols such as MIPv6, HMIPv6, CTP and
Diameter.
A new Diameter 3P-AAA application has been identified as
a solution to support this signaling protocol. Messages to
handle AA and mobility, context transfer and privacy have
been defined. Further study is needed to fully determine these
new messages. In particular attribute-value pairs (AVPs) need
to be defined.
The ideas presented in this paper are preliminary. They
address core issues that arise in the implementation of future
wireless networking based on 3P-AAA service providers,
which are not themselves access network providers, so as to
enable the consumer-based business model (CBM) paradigm
to evolve.
1 987
2005 IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications
REFERENCES
[1] N. Alonistioti, N. Passas, A. Kaloxylos, H. Chaouchi, M.
Siebert, M. O'Droma, I. Ganchev, and C. B. Faouzi,
"Business Model and generic Architecture for Integrated
Systems and Services: The ANWIRE approach (white
paper)", presented at In Proc. CD of the WWRF 8bis
meeting, 8 pages, Beijing, China, Feb. 2004.
[2] M. O'Droma and I. Ganchev., "Techno-Business Models
for 4G", presented at In Proc. of the International Forum
on 4th Generation Mobile Communications, Pp. 3.5.1-30,
King's College London, London. May 2004.
[3] P. Engelstad, T. Haslestad, and F. Paint, "Authenticated
access for IPv6 supported mobility", presented at
Proceedings of IEEE Symposium on Computers and
Communications (ISCC'2003), Kemer-Antalya, Turkey,
June 30 - July 3, 2003.
[4] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support
in IPv6", RFC3775, June 2004.
[5] H. Soliman, F. C. Catelluccia, K. E. Malki, and L.
Bellier, "Hierarchical Mobile IPv6 mobility management
(HMIPv6)", "draft-ietf-mipshop-hmipv6-04.txt", Dec.
2004.
[6] P. Calhoun, J. Loughney, E. Guttman, G. Zom, and J.
Arkko, "Diameter Base Protocol", RFC 3588, Sep.
2003.
[7] C. Rigney, A. Rubens, W. Simpson, and S. Willens,
"Remote Authentication Dial In User Service
(RADIUS)", RFC2865, Apr. 1997.
[8] E. P. Eronen, T. Hiller, and G. Zom, "Diameter
Extensible Authentication Protocol (EAP) Application",
"draft-ietf-aaa-eap-l0.txt", Nov. 2004.
[9] P. R. Calhoun, G. Zorn, D. Spence, and D. Mitton,
"Diameter Network Access Server Application," "draftietf-aaa-diameter-nasreq-17.txt", July 2004.
[10] P. R. Calhoun, T. Johansson, C. E. Perkins, T. Hiller, and
P. J. McCann, "Diameter Mobile IPv4 Application,"
"draft-ietf-aaa-diameter-mobileip-20.txt", Aug. 2004.
[11] B. a. M. B. Aboba, "The Network Access Identifier",
RFC 2486, Jan. 1999.
[12] M. Nakhjiri, C. Perkins, R. Koodli, and J. Loughney,
"Context Transfer Protocol," "draft-ietf-seamoby-ctp1 .txt", Aug. 2004.
[13] I. Ganchev, F. McEvoy, M. O'Droma. "New 3P-AAA
Architectural Framework and Supporting, Diameter
on
TRANSACTIONS
WSEAS
Application".
COMMUNICATIONS, Issue 4, Vol. 4, Pp. 176-185.
ISSN: 1109-2742. Apr. 2005.
[14] H. Duong, A. Dadej, S. Gordon, "Proactive context
transfer in WLAN-based access networks", In proc. of
the 2nd ACM international workshop on Wireless mobile
applications and services on WLAN hotspots,
Philadelphia, PA, USA. 2004.
978-3-8007-2909-8/05/$20.00 ©2005 IEEE
1 988
Download