R&D N 18/2002
Paal Engelstad, Thomas Haslestad
A Study of the suitability for PANA
in the Telenor R&D Project "Net and
Mobility"
Company INTERNAL
http://www.unik.no/personer/paalee
Company INTERNAL
R&D Scientific
Doc.
Title
ISBN
ISSN
Project No
Program
Security Gr.
No. of pages
Date
A Study of the suitability for PANA in the Telenor R&D...
N 18/2002
A Study of the suitability for PANA in the Telenor
R&D Project "Net and Mobility"
0809-1021
TXFM02
Future Wireless World
Company INTERNAL
2002.06.24
Author(s)
Paal Engelstad, Thomas Haslestad
Subject headings
802.11i, 802.11x, PANA, Net and Mobility, Security, Generic Authentication.
Abstract
This paper performs an evaluation of PANA's suitability for the Net and Mobility project in
terms of security, technology, market, specification and timing.
It is argued in this paper that PANA may be able to support the same level (that is within
the scope of PANA) of security as 802.11i, but concrete PANA proposals and solutions
seems too far into the future for implementation and relevance to this project.
Telenor R&D N 18/2002
A Study of the suitability for PANA in the Telenor R&D...
Company INTERNAL
 Telenor Communication AS 2002.06.24
All rights reserved. No part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying, recording, or by any
information storage and retrieval system, without permission in writing from the publisher.
Telenor R&D N 18/2002
Company INTERNAL
A Study of the suitability for PANA in the Telenor R&D...
Contents
1
Introduction ..........................................................................................1
2
A superficial security evaluation of 802.11i.................................2
2.1
2.2
2.2.1
2.2.2
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.4
Definitions and Abbreviations ..................................................................... 2
Architectural and Operational description .................................................... 3
Architectural Description............................................................................ 3
Operational Description .............................................................................. 4
Threat Evaluation associated with attacks on the radio interface .................... 5
Unauthorized access to data ........................................................................ 5
Threats to integrity ..................................................................................... 6
Denial of service attacks ............................................................................. 6
Unauthorised access to services................................................................... 7
Conclusion................................................................................................. 7
3
Evaluation of the Pros and Cons of PANA ..................................8
3.1
3.2
3.3
Pros........................................................................................................... 8
Cons .......................................................................................................... 9
Conclusion................................................................................................10
4
Conclusion..........................................................................................12
Telenor R&D N 18/2002
Company INTERNAL
1
A Study of the suitability for PANA in the Telenor R&D...
Introduction
“Network access technologies for wired and wireless media are evolving rapidly. With the
rapid growth in the number and type of devices and terminals that support IP stacks and
can access the Internet, users can potentially use a single device having the capability of
attaching via different multiple access media and technologies to interface to the network.
The model for providing the users' information to the network for authentication,
authorization or accounting needs to be the same and NOT be tied in to the underlying
access type” –ref. [4]
The above is quoted from the IETF working group PANAs working description. The
charter of PANA (Protocol for carrying Authentication for Network Access) is most
interesting in the perspective of intersystem mobility that is within the scope of the Telenor
R&D’s Net and Mobility project.
This paper performs an evaluation of PANA s suitability for the Net and Mobility project in
terms of security, technology, market, specification and timing.
The first evaluation area has been performed through an investigation of the security
supported by 802.11i with the purpose of identifying the security level to which PANA
needs to support. 802.11i is the chosen telecom protocol based on the assumption that it
meets the security level to which the user and the operator of the future will accept.
The latter areas are treated under a general evaluation of the pros and cons of PANA.
Telenor R&D N 18/2002 - 1
A Study of the suitability for PANA in the Telenor R&D...
2
Company INTERNAL
A superficial security evaluation of 802.11i
This chapter performs a superficial security evaluation of the Draft version D2.0 of 802.11i
in order to identify the security threats to which the standard aims to minimize or remove.
Only Pure RSN security architecture is considered for this evaluation. No further
argumentation given for this statement than the following quote from 802.11i:
“All pre-RSN security mechanisms have been deprecated, as all fail to meet their security
goals. All can be easily compromised with public domain tools downloaded freely from the
Internet. ”
2.1
Definitions and Abbreviations
Key hierarchy:
A sequence of steps that are used to generate from a root key a set of encryption
keys.
Pairwise Transient Key (PTK)
A value that is derived from the PRF using the SNonce and KONonce, and is split up
into as many as five keys (Temporal Encryption Key, two Temporal MIC Keys,
EAPOL-Key, Encryption Key, EAPOL-Key MIC Key) for use by the rest of the
system.
Privacy
The service used to prevent the content of messages from being read by other than
the intended recipients.
Medium access control (MAC) service data unit (MSDU):
Information that is delivered as a unit between MAC service access points (SAPs).
Station (STA):
Any device that contains an IEEE 802.11 conformant medium access control
(MAC) and physical layer (PHY) interface to the wireless medium (WM).
Nonce:
A value that is never reused within a context. The context in this document is
always a cryptographic key, so that a nonce is values used only once with the key.
“Never reused within a context” means exactly that, including over all reinitialisations of the system through all time.
2 - Telenor R&D N 18/2002
Company INTERNAL
2.2
A Study of the suitability for PANA in the Telenor R&D...
Architectural and Operational description
2.2.1 Architectural Description
The Robust Security Network architecture introduces three new components to the 802.11
architecture.
These new components are:
-
802.1x port. The port resides on top of the MAC. All data traffic that flows through
the MAC must pass the port.
-
AA – Authentication Agent resides on top of the .1x port and provides
authentication and key management. The AA utilizes only protocols above .11 &
.1x
-
AS – Authentication Server resides in the DS (Distribution System) and
participates in the authentication of all STAs –either through providing material for
authentication or through performing the actual verification of credentials.
Figure 1 Pure RSN network. Ref. [1]
Telenor R&D N 18/2002 - 3
A Study of the suitability for PANA in the Telenor R&D...
Company INTERNAL
2.2.2 Operational Description
Association State
The association takes place immediately after their RSN capabilities are indicated. The
Association request is transmitted from the MT to the AP indicating its supported
authentication algorithms, unicast and multicast cipher schemes. The AP will respond a
success message with an allocated Association ID and the supported algorithms and cipher
schemes. The Association state will finalize with a confirmation message from MT
containing the chosen authentication algorithm and cipher scheme.
Authentication State
The authentication is performed by upper layer protocols (as negotiated in the association
phase) through deployment of 802.1x. The MAC passes all data packets it receives from
higher layers unconditionally and has therefore delegated the filtering of any unauthorized
traffic to .1x. Any 802.11 Authentication specific frames will be discarded. The
Authentication process will be compliant to rfc2284 (EAP)
Key exchange State
The key exchange algorithm is based upon the 802.1x EAPOL rekey Protocol.
There is proposed three key hierarchies:
- Master key hierarchy (Resides on the radius/diameter server for EAP Keying.)
-
-
Rekeying Hierarchy (Key owner is the AP)
o
Pairwise (Keys used between two STAs)
o
Group (Keys used for “cell-broadcast”)
Per packet key Hierarchy (per TKIP temporal key)
A pairwise EAPOL- key exchange will have the following procedure:
-
Key owner (AP) send a EAPOL-key Message containing a.o. KNonce to the STA
that is unencrypted and not integrity checked.
-
The STA derives PTK based on an own generated value (SNonce) and the given
KNonce and transmits an EAPOL-key message to the AP with SNonce. The
message is still unencrypted but integrity checked.
-
The AP derives the PTK from the message and transmits a new EAPOL-key
message containing a Pairwise KONonce, an integrity check and the key index and
key type to be used.
-
Encryption starts and two more exchanges are performed for later usage.
There are two sets of key formats that maybe used and these are TKIP and AES keys. TKIP
keys are only to be used in an RSN network where Pre-RSN STAs are allowed. Only AES
keys are allowed in a pure RSN.
4 - Telenor R&D N 18/2002
Company INTERNAL
A Study of the suitability for PANA in the Telenor R&D...
Privacy Protection
Advanced Encryption Standard (AES) and Offset Codebook (OCB) mode is the protocol
adopted for privacy protection. Once the key has been derived the 802.11MAC uses the
AES –OCB encapsulation algorithm with the key to protect all unicast MSDU.
The encapsulation algorithm constructs a replay counter in front of the data block and a
MIC (Integrity check) trailing the MSDU data. The MSDU data is encrypted using the
unicast key K derived from the temporal key from the 802.1x key management. THE
DERIVED KEYS ARE PER ASSOCIATION
2.3
Threat Evaluation associated with attacks on the radio interface
The descriptions of threats that are listed below are taken from ref [2].
2.3.1 Unauthorized access to data
T1a
Eavesdropping user traffic: Intruders may eavesdrop user traffic on the radio
interface.
User traffic is protected in the case of unicast MSDUs with AES-OCB Privacy
protocol by the 802.11MAC.
Conclusion: Threat is minimised
T1b
Eavesdropping signalling or control data: Intruders may eavesdrop signalling data
or control data on the radio interface. This may be used to access security management
data or other information, which may be useful in conducting active attacks on the
system.
All MAC and PHY generated signalling data are transmitted in clear text. The initial
key exchange at association is unencrypted. Latter control signalling from layers
above 802.11 MAC is protected.
Authentication parameters are sent in clear text. Dependent upon upper layers to have
security schemes for protection of the permanent identity of the user (STA)
Conclusion: Threat is available
T1c
Masquerading as a communications participant: Intruders may masquerade as a
network element to intercept user traffic, signalling data or control data on the radio
interface.
This is possible if the intruder (maintains equal Master Key) intercepts the
communication right after authentication and before the key exchange mechanism is
initiated. The intruder needs to eavesdrop the communication from the initial
association to be able to derive the correct key.
Conclusion: Threat is available but only in a small time space and only certain
scenarios where the Master Key is not unique for each STA.
T1d
Passive traffic analysis: Intruders may observe the time, rate, length, sources or
destinations of messages on the radio interface to obtain access to information.
Control and management information
Telenor R&D N 18/2002 - 5
A Study of the suitability for PANA in the Telenor R&D...
Company INTERNAL
Conclusion: Threat is available
T1e
Active traffic analysis: Intruders may actively initiate communications sessions and
then obtain access to information through observation of the time, rate, length, sources
or destinations of associated messages on the radio interface.
No conclusion is taken.
2.3.2 Threats to integrity
T2a
Manipulation of user traffic: Intruders may modify, insert, replay or delete user
traffic on the radio interface. This includes both accidental and deliberate
manipulation.
Protection is implemented in MAC with the exemption of the case outlined in T1c.
Conclusion: Threat is minimised
T2b
Manipulation of signalling or control data: Intruders may modify, insert, replay or
delete signalling data or control data on the radio interface. This includes both
accidental and deliberate manipulation.
No conclusion is taken
2.3.3 Denial of service attacks
T3a
Physical intervention: Intruders may prevent user traffic, signalling data and control
data from being transmitted on the radio interface by physical means. An example of
physical intervention is jamming.
This is possible, No Protection
Conclusion: Threat is available
T3b
Protocol intervention: Intruders may prevent user traffic, signalling data or control
data from being transmitted on the radio interface by inducing specific protocol
failures. These protocol failures may themselves be induced by physical means.
This is possible due to lack of signalling protection.
Conclusion: Threat is available
T3c
Denial of service by masquerading as a communications participant: Intruders
may deny service to a legitimate user by preventing user traffic, signalling data or
control data from being transmitted on the radio interface by masquerading as a
network element
This is possible, No Protection towards sending disassociation message to the AP
masquerading as the STA with the allocated Association ID.
Conclusion: Threat is available
6 - Telenor R&D N 18/2002
Company INTERNAL
A Study of the suitability for PANA in the Telenor R&D...
2.3.4 Unauthorised access to services
T4a
Masquerading as another user: An intruder may masquerade as another user
towards the network. The intruder first masquerades as a base station towards the user,
then hijacks his connection after authentication has been performed.
See T1c.
2.4
Conclusion
Based on this evaluation it is reasonable to conclude that 802.11i+802.1x eliminates or
reduces the following threats to the radio interface:
-
Eavesdropping user traffic
-
Manipulation of user traffic
-
Masquerading as another user
-
Masquerading as a communications participant
Telenor R&D N 18/2002 - 7
A Study of the suitability for PANA in the Telenor R&D...
3
Company INTERNAL
Evaluation of the Pros and Cons of PANA
A general evaluation of pros and cons of PANA is required to assess whether PANA is a
protocol suitable for investigation within the Network and Mobility project of Telenor FoU.
The following criteria of evaluation is considered in this evaluation
1. Technology: Does PANA represent a unique technology?
2. Market: Will PANA have a fair chance to succeed in the market place?
3. Specification: Does the PANA effort have a fair chance to develop
successfully into an IETF specification?
4. Timing: How long time will it take before for the technical PANA protocol
to be developed, how long time will it take for it to be successfully
specified in IETF, and how long time will it take for it to reach widespread
deployment in the market place?
The first three criteria address the question of whether the PANA effort has a fair chance to
succeed, while the last criteria addresses the question of whether the PANA protocol may
succeed within a time period that makes it an interesting topic of study for the Network and
Mobility project, which is of limited time scope.
Pros and cons of the PANA protocol are listed below. Each relates to at least one of the four
evaluation criteria and is of different importance. The list of pros and cons finally results in
an overall balanced conclusion.
3.1
•
Pros
The PANA vision is that "PANA will provide link-layer independent authentication"
(and will later be linked to subsequent Authentication.)
o
In a long-term perspective new link layer technologies can be developed
and launched without requiring link layer specific authentication
mechanisms be specified. Without PANA, on the contrary, new
authentication mechanisms and procedures must be de veloped and
specified for each and every new link-layer technology launched.
•
PANA simplifies roaming between different access technologies, because the
authentication protocol is IP based and independent of the access technology.
•
Mobile IPv4 allows a user to authenticate with a Foreign Agent to be authorized access,
while there are no Foreign Agents present in Mobile IPv6 to accommodate similar
functionality. PANA may address this shortcoming of Mobile IPv6.
•
The PANA-effort has broad support among the Internet Area Directors of IETF, it is in
line with the well-known policy of IETF that link-layer functionality that may be
addressed by IP -based technology should be solved by IP-protocols, and not by linklayer protocols.
8 - Telenor R&D N 18/2002
Company INTERNAL
3.2
A Study of the suitability for PANA in the Telenor R&D...
Cons
•
Some critics claim that "the most important link-layers (PPP, WLAN, etc.) have
already workable authentication mechanism specified." PANA is therefore not of
immediate interest, but is interesting in a long-term perspective as new link-layer
technologies are being launched.
•
Some critics claim that "the most important link-layer solutions (PPP, WLAN, etc.)
have already also specified workable authorization mechanisms, which require
authentication being performed first." Thus, many existing link-layer solutions may not
switch from link-layer-based to IP -based (i.e. PANA-based) authentication, before
subsequent IP-based authorization is also available. PANA may address subsequent IP based authentication later.
•
o
Thus, link-layer solutions requiring fine-grained authorization may not
switch to PANA in a short-term perspective, but have to wait for a
considerable period of time before the authorization solution is also
present. (J. Carlson, emphasized this point in the list discussion: "Once
again, I'm very confused about what it means to divorce authentication
services from the fine-grained authorizations that these authentications
often imply...")
o
Some anticipate that many ISPs may share WLAN access points. Since
popular WLAN technologies like 802.11b have 3 channels and the
opportunity for frequency reuse is reduced. In such a setting, it is important
that different users are authorized access to different ISP's networks.
Many PANA scenarios imply that PANA requires support from additional protocols, in
addition to the IP-based authentication solution mentioned above. Some of these
protocols will probably require considerable time and effort to be developed.
o
•
For example, if the PANA Authentication Agent (PAA) is not required to
be located on the access point, then a new control protocol (e.g. MIDCOM)
must be develop to allow the PAA to manage access control. It may take
time before such a protocol be fully specified. If, on the contrary, PAA is
required to be located on the access point, PANA will not offer the
advantage of multi-hop authentic ation, which is a benefit that often follows
from moving functionality from the link-layer to the IP-layer.
Some critics claim that "PANA is not link-layer independent"
o
For many reasons, including some deriving from security considerations,
the PANA-authentication will include a device identifier, for example, to
link IP-authentication with a link-layer address (or identity) used at the
authenticating device - ref [3]. (The device identifier was proposed as a
result of the list discussion regarding user-authentication versus device
authentication.) It is therefore fair to say that PANA is not completely
link-layer-transparent.
o
It is difficult to envision how the device-identifier can be included in
existing authentication mechanisms. If PANA is to develop new
authentication mechanisms, on the other hand, this may be a tremendous
task requiring much time and effort.
o
PANA may easily end up with the worst-case solution requiring link-layer
authentication always being undertaken, making PANA into a rather
redundant protocol.
Telenor R&D N 18/2002 - 9
A Study of the suitability for PANA in the Telenor R&D...
•
Company INTERNAL
General technical challenges
o
Discussions on the PANA mailing list over the last 6 months reveal a broad
range of technical challenges - most of these are briefly outlined above with respect to lower layer technology, security aspects, interface with
AAA, access control, the use of a device identifier, etc. Although these
challenges are solvable, the list discussion shows that solutions may take
longer time to develop than anticipated. 6 months ago, many people in the
PANA group thought that PANA could simply be addressed by simply
encapsulating an existing authentication mechanism in an EAP-header, sent
using UDP or ICMP. Thus, 6 months ago many people anticipated the
PANA protocol being developed and specified during the summer of 2002,
but it turned out that a more complicated solution is required to address all
shortcomings mentioned above. One has now learned that this work may
take longer time.
•
During the IETF meeting in Minneapolis March 2002, PANA met resistance from
some influential persons. Glen Zorn is an example of one of the security gurus and Pat
Calhoun is an example of one of the authentication gurus strongly apposing the
PANA effort. PANA also met resistance from people working in the PPP-group,
although this was anticipated since PANA may compete directly with PPP-based
mechanisms (i.e. 'not-invented-here' syndrome). Resistance from influential IETF
personalities makes the PANA work more difficult to carry out.
•
The group of active PANA participants is very small, making the PANA work
longer time to be carried out.
3.3
o
Moreover, a survey on the PANA list revealed that few vendors and
implementers are not participating actively in the PANA effort.
o
Furthermore, the interest of the PANA list has decreased considerably after
the IETF meeting in Minneapolis. Some months have passed with only a
few mails on the list.
o
The character of the list discussion has changed dramatically after IETF in
Minneapolis. Before the meeting, people on the list developed a
requirement document, proposed solutions, prepared a framework
document, and anticipated a solution being agreed upon shortly. After the
meeting, on the other hand, the group has created a FAQ to explain their
charter, and has started to work on the charter, and buried existing
proposals. Thus, the group's work is back to the initial point where it was
December 2001.
Conclusion
1) The PANA vision is good, and a PANA protocol may serve Telenor well in cases
where Telenor provides roaming between different network technologies.
2) However, it will take considerably long time before the PANA protocol will be
developed as detailed above:
a. Technical challenges needs time to be solved
b. Competition from existing link-layer solutions will delay the success in the
market place of a PANA protocol.
10 - Telenor R&D N 18/2002
Company INTERNAL
A Study of the suitability for PANA in the Telenor R&D...
c. Resent de velopment in IETF indicates that it will take considerable time
before a PANA protocol will reach specification level of for example an
RFC proposed standard. In fact, it seems it will take considerable time
before we see a couple of workable solution on the table.
Due to the limited time frame of the Network and Mobility project, one should not waste
time on the PANA effort at this point in time. It is unclear what kind of protocol the PANA
group will end up with, and it will probably take considerable time before this is clarified.
Until then, the project may monitor the work of the PANA group, but should focus on tasks
that can be considered and tackled during the shorter time frame of the project.
Telenor R&D N 18/2002 - 11
A Study of the suitability for PANA in the Telenor R&D...
4
Company INTERNAL
Conclusion
The level of security identified within 802.11i that is related to authentication is most
certainly feasible to achieve in a generic higher-level authentication protocol such as
PANA. The basic assumption in the introduction of this paper of having 802.11i as the
benchmark for the security level to which the user and the operator of the future will accept
is questionable after the outcome of the security evaluation. This is mainly due to the lack
of protection of signaling data.
The evaluation of pros and cons of PANA showed that it is unclear what kind of protocol
the PANA group will end up with, and it will probably take considerable time before this is
clarified in IETF. Due to the limited time frame and resources of the Network and Mobility
project, one should not waste time and effort on the PANA effort at this point in time.
Instead the project may monitor the work of the PANA group, but should focus on tasks
that can be considered and tackled during the shorter time frame of the project.
Thus, the final conclusion based on the intention of this paper is that PANA will most
certainly be interesting for the future but in relation to this project it is considered to be
incompatible in time horizon.
References
[1] IEEE Std 802.11i/D2.0, March 2002. “Draft Supplement to STANDARD FOR
Telecommunications and Information Exchange Between Systems - LAN /MAN
Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and
physical layer (PHY) specifications: Specification for Enhanced Security”
[2] 3GPP, 3G TS 21.133 v3.1.0(1999-12). ”3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Security; Security Threats and
Requirements doc”
[3] Yegin et Al., "Protocol for Carrying Authentication for Network Access (PANA)
Requirements and Terminology", draft-ietf-pana-requirements-00.txt, Work-inprogress, IETF, 2002.
[4] Yegin, Basavaraj, PANA Working Group Charter,
http://www.ietf.org/html.charters/pana-charter.html (25.06.02)
12 - Telenor R&D N 18/2002