Transcript PANA

Protocol for Carrying Authentication
for Network Access (PANA)
Presented by:
Manal Houri
James Clarence Phillips
Seng Hong Ngo
Eric Kephart
November 19, 2005
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved by
PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved by
PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
What is PANA?
• The goal of PANA is to define a protocol that allows clients
to authenticate themselves to the access network using IP
protocols.
• This protocol allows a client to interact with a site's back-end
AAA infrastructure to gain access without needing to
understand the AAA infrastructure protocols that are in use.
• Such interactions can take place without a link-layer
specific mechanism: PANA would be applicable to both
multi-access and point-to-point links.
• PANA provides support for various authentication methods,
dynamic service provider selection, and roaming clients.
PANA Normal Scenario
•
A client wishing to get access to the network must
carry on multiple steps:
1. It needs to discover the IP address of the PANA
authentication agent (PAA) and then
2. execute an authentication protocol to authenticate
itself to the network.
3. Once the client is authenticated, there might be other
messages exchanged during the lifetime of the
network access.
PANA Main Elements
• Client Access Device: A network element (e.g., notebook
computer, PDA) that requires access to a provider's network.
• Network Access Server (NAS): Network device that provides
access to the network.
• PANA Client (PaC): An entity in the edge subnet that seeks to
obtain network access from a PANA authentication agent within
a network.
• PANA Authentication Agent (PAA): An entity whose
responsibility is to authenticate the PANA client and to grant
network access service to the client's device.
PANA Main Elements
• Authentication Server (AS): An entity that authenticates the
PANA client. It may be co-located with the PANA authentication
agent or part of the back-end infrastructure.
• Device Identifier (DI): The identifier used by the network to
control and police the network access of a client. At most one
PANA client should be associated with a DI on a PANA
authentication agent.
• Enforcement Point (EP): A node capable of filtering packets
sent by the PANA client by using the DI information authorized
by PANA authentication agent.
PANA Usage Scenario
• PANA is to be used in an environment where no a priori trust
relationship or security association between the PaC and other
nodes, (such as the PAA and EP) exist.
• The link between PaC and PAA may be a shared medium
(e.g.,Ethernet) or may not be a shared medium (e.g., DSL
network).
• All the PaCs may be authenticated to the access network at
layer 2 and share a security association with a layer 2
authentication agent. Yet, The PaCs still don't trust each
other.
• Any PaC can pretend to be a PAA, spoof IP addresses, and launch
various other attacks.
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved by
PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
PANA & EAP
• EAP already supports most of the PANA requirements
• PANA MUST identify which specific security protocol(s) or
mechanism(s) it can carry (the "payload").
• EAP is a candidate protocol that satisfies many requirements for
authentication.
• PANA would be a carrier protocol for EAP.
PANA & EAP
PANA & EAP
PANA & EAP
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved
by PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
PANA General Requirements
•
•
•
•
•
•
Authentication
Network
Interaction with other protocols
Performance
Congestion control
Denial of service attacks
PANA General Requirements
• Authentication
• Authentication of client
• Authorization, Accounting, and Access Control
• Authentication backend
• Identifiers
• Network
• Interaction with other protocols
• Performance
• Congestion control
• Denial of service attacks
PANA General Requirements - Authentication
• Authentication of Client
• PANA MUST enable authentication of PaCs for network
access.
• A PaC's identity can be authenticated by verifying the
credentials (e.g.,identifier) supplied by one of the users
of the device (or the device itself).
• PANA MUST only grant network access service to the
device identified by the DI
PANA General Requirements – Authentication (cont’d)
• Authentication of Client
• Both the PaC and the PAA MUST be able to perform mutual
authentication for network access.
• Providing only the capability of a PAA authenticating the PaC is
not sufficient.
• PANA MUST be capable of carrying out both periodic and ondemand re-authentication.
• Both the PaC and the PAA MUST be able to initiate both the initial
authentication and the re-authentication process.
PANA General Requirements – Authentication (cont’d)
• Authorization, Accounting, and Access Control
• After a device is authenticated by using PANA, it MUST be authorized for
"network access."
• PANA is to verify the authorization of a PaC so that PaC's device
may send and receive any IP packets.
• It may also be possible to provide finer granularity authorization,
such as authorization for QoS or individual services.
•
Providing access control functionality in the network is outside the scope
of PANA.
• Client access authentication SHOULD be followed by access
control to make sure only authenticated and authorized clients can
send and receive IP packets via the access network.
PANA General Requirements – Authentication (cont’d)
• Authentication Backend
• PANA protocol MUST NOT make any assumptions on
the backend authentication protocol or mechanisms.
• A PAA MAY interact with backend AAA infrastructures (such
as RADIUS or Diameter), but it is not a requirement.
PANA General Requirements – Authentication (cont’d)
• Identifiers
• PANA SHOULD allow various types of identifiers to be used
as the DI (e.g., IP address, link-layer address, port number of
a switch, etc.).
• A PAA MUST be able to create a binding between the PaCI and
the associated DI upon successful PANA exchange. This can be
achieved by PANA communicating the PaCI and DI to the PAA
during the protocol exchange.
PANA General Requirements
• Authentication
• Authentication of client
• Authorization, Accounting, and Access Control
• Authentication backend
• Identifiers
• Network
•
•
•
•
Multi-access
Disconnect Indication
Location of PAA
Secure Channel
• Interaction with other protocols
• Performance
• Congestion control
• Denial of service attacks
PANA General Requirements – Network
• Multi-access
• PANA MUST support PaCs with multiple interfaces, and
networks with multiple routers on multi-access links.
• PANA MUST NOT assume that the PaC has only one
network interface, that the access network has only one first
hop router, or that the PaC is using a point-to-point link.
PANA General Requirements – Network (cont’d)
• Disconnect Indication
• PANA MUST NOT assume that the link is connection-oriented. Links may
not provide disconnect indication.
• Such notification is desirable in order for the PAA to clean up resources when a
client moves away from the network (e.g., inform the enforcement points that the
client is no longer connected).
• PANA SHOULD have a mechanism to provide disconnect indication.
• PANA MUST be capable of securing disconnect messages in order to prevent
malicious nodes from leveraging this extension for DoS attacks.
• This mechanism MUST also allow a PaC to be notified about the discontinuation
of the network access service.
• Access discontinuation can occur due to various reasons such as network
systems going down or a change in the access policy.
• In case the clients cannot send explicit disconnect messages to the PAA, it can
still detect their departure by relying on periodic authentication requests.
PANA General Requirements – Network (cont’d)
• Location of PAA
• The PAA and PaC MUST be exactly one IP hop away from each other.
• That is, there must be no IP routers between the two.
• This does not mean they are on the same physical link. Bridging and
tunneling techniques can place two nodes just exactly one IP hop away from
each other although they might be connected to separate physical links.
• A PaC may or may not be pre-configured with the IP address of PAA.
• Therefore the PANA protocol MUST define a dynamic discovery method.
• Given that the PAA is one hop away from the PaC, there are a number of
discovery techniques that could be used (e.g., multicast or anycast) by the PaC
to find out the address of the PAA.
PANA General Requirements – Network (cont’d)
• Secure Channel
• PANA MUST NOT assume the presence of a secure
channel between the PaC and the PAA.
• PANA MUST be able to provide authentication especially in
networks which are not protected against eavesdropping
and spoofing.
• PANA MUST enable protection against replay attacks on
both PaCs and PAAs.
• This requirement partially relies on the EAP protocol and the
EAP methods carried over PANA.
PANA General Requirements – Interaction with other
protocols
• PANA MUST be able to co-exist and MUST NOT
unintentionally interfere with various mobility management
protocols, such as:
• Mobile IPv4
• Mobile IPv6,
• and other standard protocols like IPv6 stateless
address auto-configuration,
• and DHCP.
PANA General Requirements – Performance
• PANA design SHOULD efficiently handle the
authentication process in order to gain network access
with minimum latency.
• For example, it may minimize the protocol signaling by
creating local security associations.
PANA General Requirements – Congestion Control
• PANA MUST provide congestion control for the
protocol messaging.
• The network congestion generated can be avoided
by using techniques like delayed initialization and
exponential back off.
PANA General Requirements – Denial of Service attacks
• PANA MUST be robust against a class of DoS attacks
such as blind masquerade attacks through IP spoofing.
• These attacks would swamp the PAA, causing it to spend
resources and prevent network access by legitimate clients.
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved
by PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
PANA Trust Relationships
• PANA authentication involves:
• a client (PaC),
• a PANA agent (PAA),
• an Authentication server (AS), AAA server that resides
in the home realm of the PaC,
• and an Enforcement point (EP).
PANA Trust Relationships (Cont’d)
• The entities that have a priori trust relationships before PANA
begins are:
• PAA and AS
• PAA and EP
• PaC and AS
• These entities belong to the same administrative domain and
share a trust relationship.
PANA Trust Relationships (Cont’d)
• The entities that don’t have any trust relationship before PANA
are:
• PaC and PAA: The PaC and PAA normally belong to two
different administrative domains.
• PaC and EP: The EP belongs to the same administrative
domain as the PAA. Hence, the PaC and EP do not
necessarily share a trust relationship initially.
PANA threat scenarios
• First, the PaC needs to discover the PAA.
• This involves either sending solicitations or waiting for
advertisements.
• Once it has discovered the PAA, the two will enter
authentication exchange.
• Once the access is granted, the PaC will most likely exchange
data with other nodes in the Internet.
• These steps are vulnerable to man-in-the-middle (MITM), denial
of service (DoS), and service theft attacks.
PANA threat scenarios – PAA Discovery
• The PaC needs to discover the PAA.
• This involves either sending solicitations or waiting for advertisements.
• Possible threat scenario:
• A malicious node can pretend to be a PAA by sending a spoofed
advertisement.
• The advertisement may be used to include information other than the
discovery of the PAA itself.
• This can lead to a bidding down attack: a malicious node can send a
spoofed advertisement with capabilities that indicate authentication
methods less secure than those that the real PAA supports.
• Thereby the PaC will be fooled into negotiating an authentication method
less secure than would otherwise be available.
PANA threat scenarios – Requirement 1
PANA MUST not assume that the discovery
process is protected.
PANA threat scenarios – success or failure indications
• Possible threat scenario:
• An attacker can send a false authentication success or failure message
to the PaC.
• By sending a false failure message, the attacker can prevent the client
from accessing the network.
• By sending a false success message, the attacker can prematurely end
the authentication exchange, effectively denying service for the PaC.
• This attack is possible if the success or failure indication is not protected
by using a security association between the PaC and the PAA.
PANA threat scenarios – Requirement 2
PANA MUST be able to mutually authenticate the PaC and PAA.
PANA MUST be able to establish keys between the PaC and PAA to
protect the PANA messages.
PANA threat scenarios – Man in the middle attack (MITM)
• Possible threat scenario:
• A malicious node can claim to be the PAA to the real PaC
and claim to be the PaC to the real PAA.
• This is a man-in-the-middle (MITM) attack:
• the PaC is fooled to think that it is communicating with
the real PAA and,
• the PAA is fooled to think that it is communicating with the
real PaC.
• In these attacks, the server first authenticates to the client.
• As the client has not proven its identity yet, the server acts
as the man-in-the-middle, tunneling the identity of the
legitimate client to gain access to the network.
PANA threat scenarios – Requirement 3
Use cryptographically bound methods to avoid MITM attacks
PANA threat scenarios – Replay attack
• Possible threat scenario:
• 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.
PANA threat scenarios – Requirement 4
PANA MUST be able to protect itself against replay attacks.
PANA threat scenarios – Device Identifier attack
•
Possible threat scenario:
• When the client is successfully authenticated, the PAA sends access
control information to the EP for granting access to the network.
• The access control information typically contains the device identifier of
the PaC
• The attacker can gain unauthorized access into the network by taking the
following steps:
• An attacker pretends to be a PAA and sends advertisements. The PaC
is 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 also
does the same on return packets.
• 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.
PANA threat scenarios – Requirement 5
PANA MUST be able to protect the device identifier against spoofing when it is
exchanged between the PaC and PAA.
PANA threat scenarios – PaC leaving the network
•
Possible threat scenario:
• When the PaC leaves the network, it can inform the PAA before
disconnecting from the network so that the resources used by PaC
can be accounted properly.
• The PAA may also choose to revoke the access anytime it deems
necessary.
• The following are possible threats:
• A malicious node can pretend to be a PAA and revoke the
access to PaC.
• A malicious node can pretend to be a real PaC and transmit a
disconnect message.
• The PaC can leave the network without notifying the PAA or EP
(e.g., the Ethernet cable is unplugged, system crash). An
attacker can pretend to be the PaC and start using the network.
PANA threat scenarios – Requirement 6
PANA MUST be able to protect disconnect and revocation
messages.
PANA MUST NOT depend on the PaC sending a disconnect
message.
PANA threat scenarios – Service Theft
• Possible threat scenario:
• An attacker can gain unauthorized access into the network by stealing
the service from another client.
• Once the real PaC is successfully authenticated, the 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 the IP and MAC addresses.
• An attacker can spoof both the IP and MAC addresses of an authorized client to
gain unauthorized access. The attacker can launch this attack easily by just
sniffing the wire for IP and MAC addresses. This lets the attacker use the
network without any authorization, getting a free service.
• The PaC can leave the network without notifying the PAA or EP (e.g., the
Ethernet cable is unplugged, system crash). An attacker can pretend to be the
PaC and start using the network.
PANA threat scenarios – Requirement 7
• PANA MUST securely bind the authenticated session to the device
identifier of the client, to prevent service theft.
• PANA MUST be able to bootstrap a shared secret between the PaC and
PAA that can be further used to set up a security association between
the PaC and EP to provide cryptographic protection against service
theft.
PANA threat scenarios – PAA-EP Communication
• Possible threat scenario:
• After a successful authentication, the PAA needs to communicate the
access control information of the PaC to the EP so that the PaC will be
allowed to access the network.
• The information communicated would contain at least the device
identifier of the PaC.
• If strong security is needed, the PAA will communicate a shared secret
known only to the PaC and PAA, for setting up a security association
between the PaC and EP.
• The following are possible threats:
•
An attacker can eavesdrop to learn the information communicated between
the PAA and EP. The attacker can further use this information to spoof the
real PaC and also to set up security association for gaining access to the
network.
• An attacker can pretend to be a PAA and send false information to an EP to
gain access to the network. In the case of stronger security, the attacker has
to send its own device identifier and also a shared secret, so that the EP will
let the attacker access the network.
PANA threat scenarios – Requirement 8
If the communication between the PAA and EP is protected,
these threats are absent.
Agenda
• What is PANA?
• Relating PANA to EAP
• What are the general requirements to be achieved
by PANA?
• What are the threat analysis and security
requirements to be achieved by PANA?
• PANA mobility optimizations
PANA Mobility Optimizations
• The objective of the proposed optimizations aim at
reducing protocol latency and signaling associated with
PANA-based network access AAA.
PANA Mobility Optimizations
• A PaC using PANA MUST execute full EAP/PANA upon inter-subnet
movement.
• In case seamless mobility is desirable, having to execute full EAP
authentication with a AAA server would incur undesirable latency.
• Some extensions to the base PANA specification are required to
eliminate the need to execute EAP each time the PaC performs an
inter-PAA handover.
•
A scheme is needed that allows creation of a new PANA session with a new
PAA based on an existing session with another PAA:
• Generation of a new PANA session without requiring the execution of EAPbased authentication.
• Instead, a context-transfer-based scheme is used to bring in relevant state
information from the previous PAA to the new PAA.
PANA Mobility Optimizations-Framework
PaC
newPAA
prePAA
Live PANA session
1
2
3
4
5
X moves from subnet 1 to
subnet 2
PDI
PSR
PSA
CT-req
6
CT-resp
7
PBR
8
9
PBA