AERONAUTICAL COMMUNICATIONS PANEL (ACP) 4 MEETING OF THE WORKING GROUP OF THE WHOLE

fishglugΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

121 εμφανίσεις



AERONAUTICAL COMMUNICATIONS PANEL (ACP)


4
th

MEETING OF
THE WORKING GROUP OF THE WHOLE



Montreal, Canada

14
September

-

16
September

2011



Agenda Item
5
:

Future work



AAA Framework

for the Future Data Link S
ystems:
The

case for AeroMACS



(Presented by
Nikos Fistas, EUROCONTROL)


(Prepared by R. Agrone, SELEXELSAG)



SUMMARY

This worki
ng paper
addresses the need to agree on an appropriate AAA
framework for the future data link systems. It focuses on the case of
AeroMACS and
analyses the
WiMAX
®

AAA Framework
,

highlighting the
open points to solve
in order to progress
the standardization

of the AeroMACS
AAA framework
.

ACTION

The meeting is asked to add the
development
of the appropriate AAA
framework
for the future data link systems
in the
work program of the
Aeronautical

Communication Panel (ACP).






International Civil Aviation Organization


WORKING PAPER

ACP
-
WGW
04
/
WP
-
18

0
7

09

2011



ACP
-
WGW
04
/WP
-
18


-

2
-

1.

Introduction

Under the SESAR activ
ities
,

three
new data link systems are being considered to support the future
requirements. For all these links features of an appropriate AAA (Authentication, Authorization and
Accounting) will be required. In particular,
a common

AAA Framework is require
d to guarantee
and
facilitate the
worldwide compatible implementation of the future air/ground communication
infrastructure.

In the context of AeroMACS standardisation process, as the first future air/ground communication
infrastructure protocol planned t
o be implemented, different
schemes

are currently discussed and nee
d
to
be agreed on a worldwide basis

to facilitate interoperability
.

The present document discusses several implementation issues and elaborates a possible AeroMACS
initial Mobile Station (M
S) network procedure comprising MS
-
to
-
Network Extensible Authentication
Protocol (EAP


IETF RFC 3748) process and multiple Domain authentications.


This paper was developed as contribution under the activities
in Europe of
the SESAR P15.2.7 (Airport
Surfa
ce
Data link
) Project and the FP7 project SANDRA (
Seamless Aeronautical Networking through
integration of Data links, Radios, and Antennas)

supporting the development of the required standards for
AeroMACS
.


2.

AAA scheme for the new data links

The Future Co
mmunications Infrastructure for the aeronautical environment will be based on the IP
-
protocol. As it is an open protocol procedures for authentication, authorization and accounting needs to be
standardised on a worldwide basis before getting into operation
. Moreover these procedures have to be
independent from the specific data link used allowing
centralisation of the
user information, avoiding
duplication of information, and simplifying the integration of new data links.

Therefore a
common AAA Framework is

required to guarantee for a worldwide compatible
implementation of the future air/groun
d communication infrastructure.

In the context of AeroMACS (WIMAX) standardisation process, as the first future air/ground
communication infrastructure protocol planned

to be implemented, different schemes are currently
discussed and need to be agreed on a worldwide basis.

In appendix A of this paper the WIMAX Forum
AAA scheme is ex
p
lained and its application to AeroMACS is been
discussed
.

Agreement for the AAA scheme fo
r AeroMACS is required to be achieved as soon as possible in order to
progress the development of the required AeroMACS standards. However, it is proposed that the AAA
scheme agreed for AeroMACS is also considered as the system to support the other new dat
a links
(LDACS and future SATCOM) which are expected to be considered for standardisation in the future.


3.

ACTION BY THE MEETING

The meeting is invited to take
note of the information of this working paper and add the task of
developing an agreed AAA framew
ork for AeroMACS
in the scope of WGS and to identify the best way
ahead for the consideration of the issue also for the
other new systems
in the future.

ACP
-
WGW
0
4
/WP
-
18


-

3
-

Appendix A: WIMAX AAA Framework and AeroMACS


WiMAX
®

AAA Framework

AAA
stand
s
for
authentication, auth
orization and accounting.

In the telecommunications networks the
se

words are
associated with
the following

functions:



Authentication.

It refers to the process where an entity
(e.g. a Mobile Station)
is authenticated
from the
network
by providing evidence
that it holds a specific identity such as an identifier associated with
credentials (e.g. password, digital
certificates
).



Authorization. This function determines whether a particular entity is authorized to perform a given activity

in a network,

typically

inherited from authentication when logging on to an application or service.



Accounting.
It refers to the tracking of
network resource

consumption

by users making activities
for the
purpose of capacity and trend analysis, cost allocation,
billing
.


The Authentication function assumes that t
he
entity
to authenticate
is

provisioned with

one or more credentials.
There are two types of credentials. A device credential is used for authenticating the terminal device to the network.
A
user

credential is used for authenticating the
user

of the access service to the network. A device credential

could
also be used as a
user

credential. That is possible when the
user

is uniquely identified (e.g. using the MAC address
of the device). In that special case, a single credential provisioned in the device can be used for authenticating both
the device a
nd the
user

at the same time. Credentials may come in different forms, such as username
-
password pair,
SIM card, X.509 certificates, etc.


The WiMAX® AAA framework is based on IETF specifications (RFC2865 and RFC 2866)

and
the WiMAX®
Forum standards suppor
t only the Extensible Authentication Protocol (EAP
-

RFC 3748) like authentication method
although

the

IEEE 802.16
-
2009 supports also RSA

methods
.


In the successive figure are
presented

the WMF entities engaged in the AAA activities.





ASN

CSN

CSN

Visited NSP

Home NSP

NAP
R
2

R
2

R
3

R
1

R
5

control plane

bearer plane

legend of lines

R
3

MS

Figure
1
:
WiMAX® AAA framework
entities


Access Service Network (ASN).

ASN is defined as a complete set of network functions needed to provide radio
access to a WiMAX
user
. ASN comprises network elements such as one or m
ore Base Station(s), and one or more
ASN Gateway (s).


Connectivity Service Network (CSN).

CSN is defined as a set of network functions that provide IP connectivity
services to the WiMAX
user
(s).


ACP
-
WGW
04
/WP
-
18


-

4
-

Network Access Provider (NAP).

NAP is a business entity t
hat provides WiMAX radio access infrastructure to one
or more WiMAX Network Service Providers (NSPs). A NAP could implement this infrastructure using one ASN.


Network Service Provider (NSP).

NSP is a business entity that provides IP connectivity and WiM
AX services to
WiMAX
user
s compliant with the Service Level Agreement it establishes with WiMAX
user
s. To provide these
services, an NSP establishes contractual agreements with one or more NAPs. Additionally, an NSP MAY also
establish roaming agreements wi
th other NSPs and contractual agreements with third
-
party application providers
(e.g., ASP or ISPs) for providing WiMAX services to
user
s.

From a WIMAX
user

standpoint, an NSP MAY be
classified as Home NSP (H
-
NSP or H
-
CSN) or Visited NSP (V
-
NSP or V
-
CSN).


The WiMAX® AAA network access authentication procedure
is used for authorizing the MS to receive the
WiMAX® access service. The procedure involves authentication of
user

and optionally device credentials.
The
functional blocks that are involved in the aut
hentication procedure are presented below.


Entity

Function

MS

Acts as the EAP peer.

NAS

Consists of the EAP authenticator and is the receiver of service authorization attributes. It resides
in the ASN (ASN
-
GW).


VAAA

The AAA proxy that resides in the

V
-
CSN.

HAAA

The AAA server
that
resides in the H
-
CSN. The EAP authentication server typically resides
within this AAA server. The AAA server has access to the user profiles and is also involved in
the authentication of the mobility operations.


Othe
r AAA proxies such as those in
transit

networks are not considered. It is assumed that
transit

proxies are trusted
and act in a pass
-
through fashion and do not modify the RADIUS packets other than modifications made for routing
purposes.
After successful n
etwork access authentication, the
H
AAA delivers autho
rization attributes to the NAS.

Each EAP authentication involves executing an EAP method (e.g., EAP
-
TLS, EAP
-
TTLS, EAP
-
AKA).

There are three EAP methods foreseen in the
WiMAX® AAA framework
:




EAP
-
TLS

fo
r device authentication based on X.509 certificates

(RFC 52
16).




EAP
-
TTLS for user authentication

(RFC5281)
.




EAP
-
AKA for user authentication

(RFC
4187
)
.


EAP
-
TLS

In the
WiMAX® AAA framework

w
hether or not to perform
d
evice
a
uthentication using EAP
-
TLS is
up to the
operator's policy
.

The

EAP
-
TLS conversation will typically begin with the authenticator

(NAS) and the peer (MS) negotiating EAP.
The

authenticator
will then typically send an EAP
-
Request/Identity packet

to the peer, and the peer will respond
wit
h an EAP
-
Response/Identity packet to the authenticator, containing the peer's user
-
Id.

From this point forward,
while nominally the EAP conversation occurs

between the EAP authenticator and

the peer, the authenticator could

act

as a pass
-
through device, wi
th the EAP packets received from the peer

being encapsulated for transmission to a
backend authentication

server

(AAA server).

During the successive phase of the EAP method the peer will send the
own X.509 certificate to the server and the server could sen
d the own X.509 certificate to the peer
,

if mutual
authentication is enabled.

The core of this method is that there is certificate X.509 installed in the
MS

and is what gives EAP
-
TLS its
authentication strength. A compromised password is not enough to brea
k into EAP
-
TLS enabled systems because
the intruder still needs to have the peer
-
side private key.

The disadvantage
s to support X.509 certificate are

that:



I
t is necessary a Certification Authority to validate them.

ACP
-
WGW
0
4
/WP
-
18


-

5
-



The certificates expire and must be chan
ged



The certificates must be purchased.

In particular the procedure to securely distribute, change and revoke the certificates can be cumbersome and prevent
an easy deployment of the terminals.


EAP
-
TTLS

When it is used, the MS and AAA SHALL support TTLS

version 0 and MS
-
CHAPv2

as a tunneled authentication
protocol. When EAP
-
TTLS is used, the
user

credential

shall
be the identifier and password used for MSCHAPv2.

EAP
-
TTLS is an EAP method that

encapsulates a TLS session, consisting of

a han
dshake phase an
d a data phase.
During the handshake phase, the server is authenticated to the client (or client and server are

mutually authenticated)
using standard TLS procedures and keying

material is generated in order to create a cryptographically secure

tunnel
for
information exchange

in the subsequent data phase.
During the data phase, the client is authenticated to the
server (or client

and server ar
e mutually authenticated) using
an arbitrary authentication mechanism encapsulated
within the secure tunnel

(
the WMF

requires

the
MS
-
CHAPv2

mechanism
).


With this method the client is not required to be authenticated via a certificate to the server. This greatly simplifies
the setup procedure as a certificate does not need to be installed on every client.


EAP
-
AKA

The
EAP
-
AKA is a mechanism for authentication and session key distribution that uses the 3rd generation
Authentication and Key Agreement mechanism,

specified for Universal Mobile Telecommu
nications System
(UMTS) and
CDMA2000
.
AKA is based on challenge
-
response

mechanisms and symmetric cryptography

and it

typically runs in a UMTS Subscriber Identity Module (USIM) or a CDMA2000 (Removable) User Identity Module
((R)UIM).

EAP
-
AKA works in the following manner:



The identity module and the H
-
CSN have agreed on a secr
et key beforehand.



The actual authentication process starts by having the HAAA produce an authentication vector, based on
the secret key and a sequence number. The authentication vector contains a random part RAND, an
authenticator part AUTN used for au
thenticating the network to the identity module, an expected result part
XRES, a 128
-
bit session key for integrity check IK, and a 128
-
bit session key for encryption CK.



The RAND and the AUTN are delivered to the identity module in the MS.



The identity mod
ule verifies the AUTN, again based on the secret key and the sequence number. If this
process is successful (the AUTN is valid and the sequence number used to generate AUTN is within the
correct range), the identity module produces an authentication resul
t RES and sends it to the home
environment.



The
HAAA

verifies the correct result from the identity module. If the result is correct, IK and CK can be
used to protect further communications between the identity module and the
HAAA
.

EAP
-
AKA supports directly

mutual authentication between HAAA and MS but requires that in each devices it is
installed an USIM.

The most important advantage of using
U
SIM for

authentication is that they may be used with different devices
(e.g.
MS)
without losing the

information st
ored on them
.

EAP
-
AKA’

ACP
-
WGW
04
/WP
-
18


-

6
-

EAP
-
AKA’
is an extension to EAP
-
AKA mechanism that aims at limiting the effects of a compromised access
network nodes and devices. The goal is met by defining a new key derivation function that binds the keys derived to
the name of t
he access network.

EAP
-
AKA’ is particularly interesting for WiFi or WiMAX systems, where user’s mobility cannot ensure the use of
a trusted access infrastructure.

The use of EAP
-
AKA’ over EAP
-
AKA in AeroMACS is mainly dependent on threats evaluation. Usin
g EAP
-
AKA’
could be unnecessary if the assumption that AeroMACS infrastructures are controlled and trusted holds.



AeroMACS

AAA Framework

The AeroMACS AAA framework is based on the
WiMAX® AAA

one.
The Open Points
to solve to drive the
standardization of t
he AeroMACS AAA framework

are the Authentication Method to use and the presence of
Multiple Domains that could deliver services to the AeroMACS MS.


Authentication Method
s

In the
SESAR
AeroMACS S
ystem
R
equirement
D
ocument

is indicated that AeroMACS support
s the WiMAX®
AAA framework with the following notes:



It is proposed to stick to the WiMAX forum profiles and thus we do not consider device authentication.
Nevertheless the need for user and device authentication will be investigated in SESAR as well as th
e
methodology to implement device authentication.



RSA is not currently supported by the WiMAX Forum, only EAP is supported. However RSA is more
robust and could be preferred to EAP depending on the results of the Security analysis, which will be
conducted
in the frame of SESAR.


The first bullet highlights the main issue for the definition of the AeroMACS AAA framework. In the WiMAX
networks, much like in the 3GPP ones, it is possible to buy a MS from the Operator or from a store and to use it with
the cred
entials agreed with the Operator. For this reason solutions like EAP
-
TTLS in which the subscriber need only
use the own credentials to access to the networks irrespective of the terminal (e.g. the mobile phone market) are
preferable. EAP
-
AKA is as well a p
erfectly valid system, as from an operational point of view the user will acquire
from the Operator an USIM, effectively providing User’s authentication to the Operator. The EAP
-
AKA seems as
well more robust as the User will not risk to loose or forget the

authentication data, and the Operator can bind any
number of USIMs to a single User.


For AeroMACS AAA framework the
main advantages to use EAP
-
AKA are:



It is possible to change the
U
SIM
/(R)UIM

without changing the

software

of the MS
.



It is possible to

change the security algorithm without changing the
software

of the MS but only changing the
USIM/(R)UIM
.



A MS without
USIM/(R)UIM

is not able to enter in the AeroMACS network.



It is possible to develop the MS in a way that if it is stolen or if someone tr
ies to extract the
USIM/(R)UIM
, MS
and
USIM/(R)UIM

will
become

unusable (anti tampering protection).



Multiple Domains

An AeroMACS MS could receive services from different Application Domains and it is necessary that the MS is
authenticated from each of t
hem.

The MS is

authenticated by its Home CSN
using the standard WiMAX Forum
procedure and in this way it is able to use services supplied directly by the Home CSN.

The WMF Fo
rum
procedures do not consider
additional authentication procedures for services s
upplied from ot
her Application
Domains. In this paragraph
is described a possible solution to solve this issue.

The s
uccessive figure describes
a possible
AeroMACS
initial
MS network
procedure comprising

MS
-
to
-
Network
EAP authentication process

and
multipl
e Domain authentications.


ACP
-
WGW
0
4
/WP
-
18


-

7
-

MS
(
1
)
DL channel acquisition
,
MAC
synchronisation
(
DL
-
MAP
)
and obtaining
UL channel parameters
(
2
)
Initial Ranging and PHY adjustments
process
(
RNG
-
REQ
/
RSP
)
(
8
)
EAP Authentication Method
(
e
.
g
.
EAP
-
TTLS
,
EAP
-
TLS
,
EAP
-
AKA
)
(
9
)
EAP Success is
indicated and security
context is acquired
(
5
)
PKMv
2
-
RSP
/
EAP Transfer
(
EAP Request
/
Identity
)
(
6
)
PKMv
2
-
REQ
/
EAP
-
Transfer
(
EAP Response
/
Identity
-
NAI
)
(
11
)
PKMv
2
-
RSP
/
EAP
-
Transfer
(
EAP Success
)
(
14
)
PKMv
2
-
RSP
/
SA
-
TEK
-
Challenge
(
15
)
PKMv
2
-
REQ
/
SA
-
TEK
-
Request
(
16
)
PKMv
2
-
RSP
/
SA
-
TEK
-
Response
(
17
)
PKMv
2
-
REQ
/
Key
-
Request
(
18
)
PKMv
2
-
RSP
/
Key
-
Reply
(
4
)
AuthRelay
_
EAP
_
Transfer
(
EAP Payload
:
EAP Request
/
Identity
)
(
7
)
AuthRelay
_
EAP
_
Transfer
(
EAP Response
/
Identity
-
NAI
)
(
12
)
Key
_
Change
_
Directive
(
AK Context
)
(
13
)
Key
_
Change
_
Ack
(
10
)
AuthRelay
_
EAP
_
Transfer
(
EAP Payload
,
EAP
-
Success
)
(
21
)
IP Address Allocation
Authenticator
/
ASN
-
GW
Visited
-

AAA
Server
Home
-

AAA Server
DHPC
Server
Domain X
AAA
BS

(
22
)
Domain X Authentication procedure

(
23
)
Domain Y Authentication procedure
Domain Y
AAA
(
3
)
MS Pre Attachment Procedure
(
SBC
-
REQ
/
RSP
,
MS
_
PreAttachment
_
Req
/
RSP
/
ACK
)
(
19
)
MS Registration Procedure
(
20
)
Data Path Establishment


AeroMACS MS Network Entry starts:

STEP 1


DL channel acquisition, MAC synchronization and obtaining UL channel parameters.

STEP 2


Initial Ranging round trips,
RNG
-
REQ/ RNG
-
RSP message exchange.

ACP
-
WGW
04
/WP
-
18


-

8
-

STEP 3


Pre
-
Attachment
procedure. MS starts Basic Capabilities negotiation where MS and BS among other parameters
negotiate the PKM protocol version and Authorization Policy.

STEP 4


The Authenticator (in ASN/ASN GW) initiates EAP authentication procedure with MS. The trigger for it, i
t’s the
successful end of the MS Pre
-
Attachment
procedure
.

STEP 5


The BS relays the EAP Request
/ Identity
to the MS.

STEP 6


MS responds with EAP Response/ Identity message providing
Identity
.

STEP 7


BS relays EAP payload received to the Authenticator over Authentication Rel
ay protocol.

STEP 8


The

Authenticator analyses the Identity
provided by the MS
.

Depending on the domain the MS could be locally
authenticated (the MS is in its Home Network) or not (the MS is in a Visited Network). If the MS is in a Visited
Network EAP
payload
are

forwarded to the MS’ Home AAA server via the Visited AAA server.

In order to deliver
the EAP payload to the AAA server, the Authenticator forwards the EAP message via a collocated AAA client using

RADIUS Access
-
Request message
.

The EAP authentication p
rocess (tunneling EAP authentication method) is performed between the MS and the
Authentication server
via the Authenticator in ASN/
ASN
-
GW. BS provides “relay” of EAP payload from PKMv2
EAP
-
Transfer messages to AR_EAP_Transfer and vice versa.

The Authentic
ator in ASN/ASN
-
GW acts in pass
through mode and forwards the EAP messages received as a payload from the BS in AR_EAP_Transfer messages to
the AAA server using RADIUS Access
-
Request messages and vice versa
.
There can be multiple EAP message
exchanges betw
een the MS and AAA server.

EAP peers (supplicant in MS and authentication server) negotiate the EAP method (e.g
.

EAP
-
AKA, EAP
-
TTLS,
EAP
-
TLS) and perform it
.

STEP 9


The Authenticator receives indication about the successful completion of EAP
-
based authentication,

the MS
authorization profile and the required security context.

STEP 10


The Authenticator forwards EAP results (EAP
-
Success or EAP
-
Failure message) to BS.

STEP 11


The BS relays EAP payload to the MS in PKMv2 EAP
-
Transfer/ PKM
-
RSP message. This message indicates the
res
ults of EAP authentication round to the Supplicant in the MS. The BS continues waiting for the explicit indication
of EAP authentication completion from the Authenticator.

STEP 12


The Authenticator in ASN/ASN
-
GW sends
Key_Change_Directive

message to the BS to ind
icate completion of the
EAP authentication process.

ACP
-
WGW
0
4
/WP
-
18


-

9
-

STEP 13


BS receiving
Key_Change_Directive

from Authenticator will acknowledge it by
Key_Change_Ack

message.

STEP 14, 15, 16

PKMv2 3
-
way handshake (SA
-
TEK
-
Challenge/Request/Response exchange) is conducted between

BS and MS to
verify the AK to be used and to establish the Security Association(s) pre
-
provisioned for the MS

STEP 17, 18

MS acquires the valid TEK keys using PKMv2 Key
-
Request/ Reply exchange between MS and BS for each SA

STEP 19


When PKMv2 3
-
way handshake is c
ompleted, MS proceeds with 802.16e Registration procedure by sending REG
-
REQ message. This message will carry the MS supported capabilities (such as CS

capabilities, Mobility parameters
and Handover support, etc.).

STEP 20


The ASN
-
GW starts to configure the BS an
d the MS using the MS

QoS profile received
by the Home AAA at step
9
.

The
BS

verifies whether there are sufficient radio resources and it decides whether the request should be accepted
or not. In case of acceptance,
the configuration

is sent to the MS
.
MS
accepts or rejects the
configuration

according
to
the standard.

At this step all the Service Flows are configured and ready, irrespective of the application
domains associated with them.

STEP 21


IP address allocation

procedure
.

When the MS will have a valid IP ad
dress all
Services Flows associated with
services directl
y provided by the Home CSN could

be immediately used.

STEP 22


Application
-
level Services
a
uthentication procedure between MS and Domain X AAA
1
.
W
hen this procedure is
properly terminated
all Service Flows a
ssociate with services provided by Domain
X

CSN could be used.

STEP 23


Application
-
level Services
a
uthentication

procedure between MS and Domain Y AAA
2
.
W
hen this procedure is
properly terminated
all
Service Flows associate with services provided by Domain Y CSN
could be used.

About the last
two
step
s
, we shall remark that Application
-
level Services (e.g., VoIP, APC flows, etc.) can require
an AAA procedure. Those are functionally and logically disjoint from the AeroMACS AAA. Any Service is free,
with this regard,

to “trust” the lower level Authentication or to require a new authentication in order to be used,
eventually with a CSN different then the one authenticating the AeroMACS device. This approach is fully compliant
with the current Internet approach, where t
he Authentication to the access network does not necessarily imply the
authentication to the services provided by other application
-
level service providers.


In brief the main advantages of this solution are:

-

For each MS
s

the Service Flows configuration
is

centralized in the Home AAA.

-

Each Application Domains, different from the Home, can choose the own authentication method
transparently respect to the other Domains.







1

This procedure is out of scope for AeroMACS

2

This procedure is out of scope for Aero
MACS