Protocol for Carrying Authentication for Network Access (PANA)

1. Protocol for Carrying Authentication for Network Access (PANA) Presented by: Manal Houri James Clarence Phillips Seng Hong Ngo Eric Kephart November 19, 2005

2. 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

3. 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

4. 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 bothmulti-access and point-to-point links. • PANA provides support for various authentication methods, dynamic service provider selection, and roaming clients.

5. PANA Normal Scenario • A client wishing to get access to the network must carry on multiple steps: • It needs to discover the IP address of the PANA authentication agent (PAA) and then • execute an authentication protocol to authenticate itself to the network. • Once the client is authenticated, there might be other messages exchanged during the lifetime of the network access.

6. 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.

7. 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.

8. 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.

9. 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

10. 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.

11. PANA & EAP

12. PANA & EAP

13. PANA & EAP

14. 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

15. PANA General Requirements • Authentication • Network • Interaction with other protocols • Performance • Congestion control • Denial of service attacks

16. 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

17. 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

18. 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 on-demand re-authentication. • Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process.

19. 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.

20. 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.

21. 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.

22. 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

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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

32. 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).

33. 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.

34. 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.

35. 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.

36. 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.

37. PANA threat scenarios – Requirement 1 PANA MUST not assume that the discovery process is protected.

38. 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.

39. 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.

40. 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.

41. PANA threat scenarios – Requirement 3 Use cryptographically bound methods to avoid MITM attacks

42. 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.

43. PANA threat scenarios – Requirement 4 PANA MUST be able to protect itself against replay attacks.

44. 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.

45. 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.

46. 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.

47. 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.

48. 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.

49. 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.

50. 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.