PANA Working Group
Internet Draft <Mohan
Parthasarathy>
Document: draft-ietf-pana-threats-01.txt <Tahoe Networks>
Expires: June 2003 January 2003
PANA Threat Analysis and security requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet Draft expires June 2003
Abstract
The PANA (Protocol for carrying authentication for Network Access)
working group is developing methods for authenticating clients to the
access network using IP based protocols. This document discusses the
threats in general without referring to a specific authentication
protocol. The security requirements arising out of these threats will
be used as additional input to the PANA WG for designing the IP based
network access protocol.
<Parthasarathy> Expires June 2003 [Page 1]
PANA threat analysis January 2003
Table of Contents
1.0 Introduction..................................................2
2.0 Keywords......................................................2
3.0 Terminology and Definitions.................................3
4.0 Usage Scenarios.............................................4
5.0 Assumptions.................................................4
6.0 Types of Attacks............................................5
7.0 Threat Scenarios............................................5
7.1 PAA Discovery..............................................5
7.2 Authentication.............................................6
7.3 PaC leaving the network....................................8
7.4 Service theft..............................................9
7.5 Miscellaneous attacks......................................9
8.0 Summary of Requirements....................................10
9.0 Security Considerations....................................11
10.0 Normative References......................................11
11.0 Informative References....................................11
Acknowledgments..................................................12
Revision Log.....................................................12
Author's Addresses...............................................12
1.0 Introduction
The PANA (Protocol for carrying authentication for Network Access)
working group is developing methods for authenticating clients to the
access network using IP based protocols. This document discusses the
threats in general without referring to a specific authentication
protocol.
There are multiple steps involved for any client wishing to get
access to the network. First, it needs to discover the IP address of
the PANA authentication agent (PAA) and then authenticate itself to
the network using the PANA protocol. Once the client is
authenticated, there might be other messages exchanged during the
lifetime of the network access. This document discusses the threats
present in these steps without referring to a specific authentication
protocol. It does not discuss any solutions for the threats. The
requirements arising out of these threats will be used as input to
the PANA WG.
2.0 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
<Parthasarathy> Expires June 2003 [Page 2]
PANA threat analysis January 2003
3.0 Terminology and Definitions
Device
A network element(notebook computers, PDAs, etc.,) that requires
access to a provider's network.
Identity
The information used to identify the user. It is used for
authenticating the PaC. Identity could be e.g., NAI [NAI]
Edge Subnet or link
The immediate IP subnet that is available to an interface of the
device for network access.
Access/Edge Router
A router that is present in the edge subnet.
Enforcement Point (EP)
A node that is capable of filtering packets sent by the PaC to the
Access/edge router using the DI information authorized by PAA.
PANA Client (PaC)
An entity in the edge subnet who is wishing to obtain network access
from a PANA authentication agent within a network. A PANA client is
associated with a device and a set of credentials to prove its
identity within the scope of PANA.
PANA Authentication Agent (PAA)
An entity in the edge subnet whose responsibility is to authenticate
the PANA client (PaC) and grant network access service to the device.
Authentication Server (AS)
An entity that authenticates the PaC which may be co-located with PAA
or part of the back-end infrastructure.
Device Identifier (DI)
<Parthasarathy> Expires June 2003 [Page 3]
PANA threat analysis January 2003
The identifier used by the network as a handle to control and police
the network access of a client. Depending on the access technology,
identifier might contain any of IP address, link-layer address,
switch port number, etc. of a device. PANA authentication agent keeps
a table for binding device identifiers to the PANA clients. At most
one PANA client should be associated with a DI on a PANA
authentication agent.
4.0 Usage Scenarios
PANA is expected to be used in environments where the nodes trust the
operator of the network to provide the service but do not trust the
other nodes in the network e.g., Public access networks, Hotel,
Airport. In these environments, one may observe the following.
o The link between PaC and PAA may not a shared medium e.g. DSL
network.
o The link between PaC and PAA may be a shared medium e.g.,
Ethernet.
o All the PaCs may be authenticated to the access network at
layer 2 already e.g., 3GPP2 CDMA network. Note that the
clients still dont trust each other.
o PaCs may already share a security association with layer 2
authentication agent e.g., Access Point in 802.11, that
provides per-packet authentication and encryption. Note that
the clients still dont trust each other.
The scenarios mentioned above affect the threat model of PANA. This
document discusses the various threats in the context of the above
network access scenarios for a better understanding of the threats.
5.0 Assumptions
The communication paths involved in the discovery and authentication
are as follows.
1) The path between PaC and PAA
2) The path between PAA and EP
3) The path between PAA and AS
If PAA and EP are co-located, the path is already secured. Even when
they are not co-located, the network operators can setup a security
association between PAA and EP to secure the traffic between PAA and
EP. Hence it is assumed that path (2) is secure.
The authentication server could be co-located in the same network as
PAA or with the back-end system. In either case, this document
assumes that there exists a security association between PAA and
<Parthasarathy> Expires June 2003 [Page 4]
PANA threat analysis January 2003
back-end system. Without this, it is not possible to authenticate
users securely. In the current deployment e.g. NAS and RADIUS, path
(3) is secured.
Thus, this document considers threats only for path (1).
6.0 Types of Attacks
The PANA authentication client (PaC) needs to discover the PAA first.
This involves either sending solicitations or waiting for
advertisements. Once it has discovered the PAA, it will lead to
authentication exchange with PAA. Once the access is granted, PaC
will most likely exchange data with other nodes in the Internet. All
of these are vulnerable to attack. Attacker in the path between PaC
and PAA can launch the following attacks.
1) Denial of Service (DoS) attacks, in which a malicious node
(PaC) prevents communication between other PaCs and PAA.
This includes resource exhaustion attacks etc.
2) Man In The Middle (MITM) attacks, which include
interception, insertion, deletion, modification, replaying,
reflection back at the sender and redirecting messages.
3) Service theft, Stealing the service of an authorized client
without authenticating to the network.
7.0 Threat Scenarios
7.1 PAA Discovery
PaC is in the process of discovering the PAA. Agents are normally
discovered by sending solicitations or receiving advertisements.
Following are the possible threats.
T7.1.1: A malicious node can pretend to be a PAA by sending a spoofed
advertisement.
T7.1.2: A malicious node can send a spoofed advertisement with
capabilities that indicate less secure authentication methods than
what the real PAA supports, thereby fooling the PaC into negotiating
a less secure authentication method than what would otherwise be
available. This is a bidding down attack.
T7.1.3: A malicious node can send solicitations to learn more
information about networks which might help the attacker to launch
some known attacks e.g., PAA supports weak authentication suite.
<Parthasarathy> Expires June 2003 [Page 5]
PANA threat analysis January 2003
It may not be possible protect the discovery process because the
security association between PaC and PAA does not exist prior to
authentication and hence there is no way of protecting the discovery.
If mutual authentication is performed i.e., client to AS and AS to
client, via the PAA, the successful authentication response from the
AS can be used to validate the authenticity of the PAA. This works
because of the assumption that PAA and the AS share a security
association. In such cases, a node pretending to be a PAA can be
detected at the end. Note that this does not prevent DoS attacks
where the rogue PAA does not send any responses back to the client.
In existing dial-up networks, the clients authenticate to the network
but generally do not verify the authenticity of the messages coming
from NAS. This mostly works because the link between the device and
the NAS is not shared with other nodes (assuming that nobody tampers
with the physical link) and clients trust the NAS to provide the
service, without which the network operator will not make any profit.
As the nodes in the network cannot directly communicate with other
nodes, spoofing is avoided. In this environment, as the PaC may
assume that the other end of the point-to-point link is the PAA,
spoofing attacks are not present.
In environments where the link is shared, any node can pretend to be
a PAA. Even the nodes that are authenticated at layer 2, can pretend
to be a PAA and hence the threat is still present in such networks.
Requirement 1
PANA MUST not assume that the discovery process is protected.
7.2 Authentication
PaC is in the process of authenticating to the PAA.
7.2.1 Spoofing success or failure
An attacker can send falsified authentication success or failure to
the PaC. By sending false failure, the attacker can prevent the
client from accessing the network. By sending false success, the
attacker can prematurely end the authentication exchange effectively
denying service for the PaC.
If the link is not shared, it may be hard to launch this attack as
the attacker needs to inject this packet at the right time and the
PaC can always reject packets coming from any other source address
other than the PAA.
<Parthasarathy> Expires June 2003 [Page 6]
PANA threat analysis January 2003
If the link is shared, it is easy to spoof these packets. If layer 2
provides per-packet encryption, it might make it hard for the
attacker to guess the success/failure packet that the client would
accept. Even if the node is already authenticated at layer 2, it can
still pretend to be a PAA and spoof the success or failure.
This attack is possible whenever the authentication is one way where
the client is providing its credentials for accessing the network but
it never verifies the credentials of the server.
7.2.2 MiTM attack
A malicious node can claim to be PAA to the real PaC and claim to be
PaC to the real PAA. This is a MiTM attack where the PaC is fooled to
think that it is communicating with real PAA and the real PAA is
fooled to think that it is communicating with real PaC.
Requirement 2
When the PaC and PAA mutually authenticate each other i.e the AS
verifies the identities of PaC and PaC verify the identity of the AS,
this attack can be averted.
7.2.3 Replay Attack
A malicious node can replay the messages that caused authentication
failure or success at a later time to create false failures or
success. The attacker can also potentially replay other messages of
the PANA protocol to deny service to the PaC.
This threat is absent if the link is not a shared medium. If the link
is shared, then the attacker can replay old messages to deny service
to the client.
If the packets are encrypted at layer 2, it will make it hard for the
attacker to learn the unencrypted (i.e., original) packet that needs
to be replayed. Even if layer 2 provides per-packet integrity, the
attacker can still replay the PANA messages (layer 3) for denying
service to the client.
Requirement 3
PANA MUST be resistant to replay attacks.
7.2.4 Device Identifier attack
When the client is successfully authenticated, PAA sends access
control information to EP for granting access to the network. The
access control information typically contains the device identifier
<Parthasarathy> Expires June 2003 [Page 7]
PANA threat analysis January 2003
of the PaC, which is obtained from the IP headers and MAC headers of
the packets exchanged during the authentication process. The attacker
can gain unauthorized access into the network using the following
steps.
. An attacker pretends to be a PAA and sends advertisements. PaC
gets fooled and starts exchanging packets with the attacker.
. The attacker modifies the IP source address on the packet,
adjusts the UDP/TCP checksum and forwards the packet to the real
PAA. It does the same on return packets also.
. When the real PaC is successfully authenticated, the attacker
gains access to the network as the packets contained the IP
address (and potentially the MAC address also) of the attacker.
This threat is absent if the link is not a shared medium. If the
layer 2 provides per-packet protection, then it is not possible to
change the MAC address and hence this threat may be absent in such
cases if EP filters both on IP and MAC address. If the link is
shared, it is easy to launch this attack.
Requirement 4
PANA MUST be able to protect against Device Identifier attack.
7.3 PaC leaving the network
When the PaC leaves the network, it needs to inform the PAA before
disconnecting from the network so that the resources used by PaC can
be accounted properly. PAA may also choose to revoke the access any
time if it deems necessary. Disconnect and revocation messages needs
to be protected to avoid the following attacks.
T7.3.1: A malicious node can pretend to be a PAA and revoke the
access to PaC.
T7.3.2: A malicious node can pretend to be a real PaC and disconnect
from the network.
This threat is absent if the link between PaC and PAA is not a shared
medium.
If the link is shared, any node on the link can spoof the disconnect
message. Even if the layer 2 has per-packet authentication, the
attacker can pretend to be a PaC e.g. by spoofing the IP address, and
disconnect from the network. Similarly, any node can pretend to be a
PAA and revoke the access to the PaC.
Requirement 5
<Parthasarathy> Expires June 2003 [Page 8]
PANA threat analysis January 2003
PANA MUST be able to protect disconnect and revocation messages.
7.4 Service theft
An attacker can gain unauthorized access into the network by stealing
the service of authenticated/authorized client. Once the PaC is
successfully authenticated, EP will have filters in place to prevent
unauthorized access into the network. The filters will be based on
something that will be carried on every packet. For example, the
filter could be based on IP and MAC address where the packets will be
dropped unless the packets coming with certain IP address match the
MAC address also. Following are the possible threats.
T7.4.1: Attacker can spoof both the IP and MAC address to gain
unauthorized access. The attacker just gets a free ride using the
network access of some other client.
T7.4.2: Attacker can spoof both the IP and MAC address of any client
and inject data packets into its data stream.
These threats are absent in links that are not shared as simple
ingress filtering can prevent one node from impersonating as another
node.
If the link between PaC and PAA is shared, it is easy to launch this
attack. If layer 2 provides per-packet protection, it can prevent the
users from gaining unauthorized access. But it cannot prevent the
nodes from using the IP address of some other node. Hence, the
attacker can still inject false data.
If the PaC is using a secure VPN service e.g. using IPsec, IPsec
already provides per-packet data origin authentication and integrity.
In this case, it prevents the attacker from injecting false data. But
the attacker can still gain unauthorized access.
Requirement 6
PANA MUST be able to provide sufficient access control information
like IP address, MAC address, keys etc., to EP, which in turn can
prevent unauthorized users from gaining access to the network.
7.5 Miscellaneous attacks
T7.5.1: Attacker can bombard the PAA with lots of authentication
requests. This can lead to DoS attack, if the resources needed for
<Parthasarathy> Expires June 2003 [Page 9]
PANA threat analysis January 2003
discarding the request are more than what is needed for
authenticating a real PaC. In general, there is always the need to
forward the request to the backend AS for authentication. This
implies that the PAA may have to allocate resources to store some
state about the PaC locally, before it receives the response from the
backend AS. This can deplete resources locally if the PAA is
bombarded with requests.
Requirement 6
PANA MUST be resistant to DoS attacks.
T7.5.2: PaC acquires IP address before PANA authentication begins
using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6
[PANAREQ]. If IP addresses are assigned before authentication, it
opens up the possibility of DoS attack where malicious nodes can
deplete the IP addresses by assigning multiple IP addresses. This
threat does not apply to IPv6 if stateless auto-configuration
[ADDRCONF] is used. If stateful mechanism is used in IPv6 e.g.,
DHCPv6, then this attack is still possible. Address depletion attack
is not specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If
PANA assumes that the client has an IP address already, it opens up
the network to the DoS attack where addresses could be depleted.
Requirement 7
PANA should not assume that the PaC has acquired an IP address before
PANA begins.
8.0 Summary of Requirements
o PANA MUST not assume that the discovery process is protected.
o PaC and PAA MUST mutually authenticate each other to prevent
MiTM attacks.
o PANA MUST protect against Device Identifier attack.
o PANA MUST be able to protect disconnect and revocation
messages.
o PANA MUST be able to provide sufficient access control
information like IP address, MAC address, keys etc., to EP,
which in turn can prevent unauthorized users from gaining
access to the network.
<Parthasarathy> Expires June 2003 [Page 10]
PANA threat analysis January 2003
o PANA SHOULD not assume that the PaC has acquired an IP address
(through other means) before PANA begins.
o PANA MUST be resistant to DoS attacks.
9.0 Security Considerations
This draft discusses various threats when using PAA for
authenticating network access. This will be taken as input by PANA WG
for designing the IP based authentication protocol.
10.0 Normative References
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2. [PANAUS] Yoshihiro Ohba et. al, Problem Space and Usage Scenarios
for PANA, draft-ietf-pana-usage-scenarios-03.txt
3. [PANAREQ] A. Yegin et al., Protocol for Carrying Authentication
for Network Access (PANA) Requirements and Terminology, draft-
ietf-pana-requirements-04.txt
4. [ADDRCONF] Susan Thomson et.al IPv6 Stateless Address
Configuration, RFC2462.
5. [DHCP-AUTH] R. Droms, et. al Authentication for DHCP messages,
RFC3118.
6. [KEYWORDS] S. Bradner, Key words for use in RFCS to indicate
requirement levels, RFC 2119, March 1997
11.0 Informative References
7. Bernard Aboba, Pros and Cons of Upper Layer Network Access,
BURP BOF.
8. Arunesh Mishra, William A. Arbaugh, An Initial Security Analysis
of the IEEE 802.1x Standard
9. IEEE. Standard for port based network access control. IEEE Draft
P802.1X
<Parthasarathy> Expires June 2003 [Page 11]
PANA threat analysis January 2003
10.[NAI] B. Aboba, M. Beadles, The Network Access Identifier
Acknowledgments
Thanks to Alper Yegin and Basavaraj Patil for the initial feedback on
this document. Pekka Nikkander provided comments that helped clarify
this document and also helped identify some threats. Michael Thomas
pointed out the missing replay attack and helped clarify the
document. Device identifier attack came out of the discussion with
Yoshihiro Ohba.
Revision Log
These are the changes between revision 00 and 01.
-Removed unused terms from section 3.0
-Removed identity protection as a threat after feedback from
Atlanta IETF55 meeting.
-Renamed the section Attacks on Normal data communication to
Service theft. Removed confidentiality mentioned in that
section.
-Clarified text in lots of places.
- Added device identifier attack.
Author's Addresses
Mohan Parthasarathy
Tahoe Networks
3052 Orchard Drive
San Jose, CA 95134
Email: mohanp@tahoenetworks.com
<Parthasarathy> Expires June 2003 [Page 12]
