PANA FAQ version 1.6, 12/08/2007 ======================= 1. What is PANA? PANA (Protocol for carrying Authentication for Network Access) is an IETF protocol for authenticating clients for Internet/intranet access. It runs between the client device requesting the service and the NAS (Network Access Server) on the access network. Successful PANA authentication authorizes the client to receive IP forwarding service from the network. [If you were looking for information on a little Illinois town, a building security company, nutrition and activity advocates from Pennsylvania, or equality of human and animal life, you hit the wrong "PANA" FAQ.] 2. What is the relation between PANA and EAP? PANA carries EAP to perform authentication between the client and the access network. In other words, PANA is a transport to EAP. Other EAP transports include PPP, IEEE 802.1X, IEEE 802.16e PKMv2, and IKEv2. 3. When do I need PANA? Note that PANA carries EAP above IP. Therefore it is applicable to any L2 that can carry IP (i.e., L2 agnostic). You need PANA if: - The access network's L2 technology lacks a standard client authentication protocol. E.g.: IP over ATM in DSL networks. - NAS is located on a node unreachable by L2 transport. E.g.: Bridged Ethernet networks (IEEE 802.1X needs to terminate on the same segment). E.g.: Various enterprise networks where some domains host their own NAS for controlling access of hosts from other domains. - You want to use single network access AAA protocol despite multiplicity of L2 types in your access networks (i.e., aiming an "All IP" architecture). - You want to perform pre-authentication across subnets [see Q&A#18] - You are still using PPP and desire to get rid of it as soon as you find a replacement for its authentication functionality. E.g.: DSL network evolution away from PPP. - You need an extensible framework that can naturally grow in many directions [see Q&A#5]. - The AAA performance is critical, especially in the face of mobility [see Q&A#19] 4. Isn't the L2 the only place you can ever have adequate network access security? A security framework that relies on a L3 client-network authentication (e.g., PANA) can yield same level of security (i.e., secure L2 channel) as a pure L2 solution. PANA is used for client-network authentication phase (Phase 1a in Figure 2 of http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-04.txt). While that step is performed over L3, the following secure association phase (2a) can be performed over either L2 or L3. Therefore, deployments needing a secure L2 channel establishment can do so by using PANA. On the other hand, note that there are deployments that are satisfied by a pure (1a and 2a) L3 solution as well (e.g., VPN-based security on WiFi networks in various enterprise deployments). 5. Why is PANA framework considered "extensible"? PANA framework is extensible in multiple directions. - The EAP layer allows use of "any authentication" method with PANA. (upward extensibility) - Running above IP provides applicability to "any L2". (downward extensibility) - Support for standard and vendor-specific AVPs in the message formating allows horizontal extensibility. 6. In what environments can I use PANA? In any environment that you can run IP. It can be used with: - Mobile, nomadic, or fixed networks. - Wired or wireless networks. - Hosts or even mobile routers connecting to access networks. - Any L2 technology (WiFi, WiMAX, cdma2000, Ethernet, ATM, GPRS, etc.) - IPv4 and IPv6. - Physically secured networks (yes, you still need client authentication -- think DSL), or unsecured wireless networks in public locations. 7. If I can already use PPP or 802.1X in my network, do I still need to use PANA? For the most basic EAP-based authentication functionality, no. Please see Q&A#3 for possible reasons you might consider using PANA in such networks. 8. Now that IKEv2 can carry EAP and it already runs above IP, did we really need a protocol like PANA? IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining IPsec security associations. It is not designed for Internet/intranet access authentication. Turning it into one requires removing extra parts (e.g., IPsec SA and D-H are not always needed) while adding some others (see RFC4058). Though it can be hacked into one, building a standards-based solution on IKE is not a good idea. Currently IKEv1-based VPN solutions are used in some enterprise WiFi networks. As a stop-gap solution, this non-interoperable proprietary solution does not match what PANA offers. 9. What does the PANA framework look like? RADIUS/ NAS Diameter/ +-----+ PANA +-----+ LDAP +-----+ | PaC |<----------------->| PAA |<---------------->| AS | +-----+ +-----+ +-----+ ^ ^ | | | +-----+ | +-------->| EP |<--------+ Provisioning Secure +-----+ Association The client implementation is called PaC (PANA Client). PaC resides on the same node as EAP peer. The server implementation is called PAA (PANA Authentication Agent). PAA resides on the NAS along with EAP authenticator or authentication server (AS), and AAA (e.g., RADIUS) client. The NAS can be hosted on any node in the access network in PANA framework (e.g., BRAS in DSL; PDSN in 3GPP2; AP, access controller, or access router in WiFi, or even multiple hops away from PaC.) EP (Enforcement Point) is an element that is in charge of per-packet access control. This functionality is traditionally bundled in the NAS, which can be separated in PANA framework implementations. The NAS provisions access control information (e.g., filters) to the EP. The protocol used depends on the architecture (e.g., R6 in WiMAX, Rp in 3GPP2, etc.). There can be multiple EPs under the control of one NAS. EPs can reside on APs, routers, bridges, etc. A secure association protocol is run between PaC and EP following a successful PANA authentication in networks where lower-layer per-packet security can only be established after client authentication (e.g., no physical security). The protocol used for that purpose depends on the L2 technology (e.g., IEEE 802.11i 4-way handshake, IEEE 802.16e PKMv2 3-way handshake), or can be the L2-agnostic protocol IKE. PAA may be optionally co-located with EP or AS. 10. What does the protocol stack look like? +----------+ +----------+ |EAP_method| |EAP_method| +----------+ +----------+----------+ +----------+ | EAP | | EAP | EAP | | EAP | +==========+ +==========+----------+ +----------+ | PANA | | PANA | RADIUS | | RADIUS | +==========+ +==========+----------+ +----------+ | UDP | | UDP | UDP | | UDP | +----------+ +----------+----------+ +----------+ | IP | | IP | IP | | IP | +----------+ +----------+----------+ +----------+ | L1/L2 | | L1/L2 | L1/L2 | | L1/L2 | +----------+ +----------+----------+ +----------+ PaC PAA (NAS) AS <----------- access network ----------------><-Internet-><--home AAA-> domain 11. Does PANA rely on RADIUS? No. Not all deployments need to separate NAS from AS. Even when they are separated, other standard (e.g., Diameter, LDAP) or proprietary protocols can be used between the two. 12. What does a high-level protocol flow look like? PaC EP PAA AS | L2 connect | | | |<------------->| | | | | | | IP address o | | | config. | PANA | | AAA | |<------------------------------>|<-------------->| | | Provisioning | | (Optional) | |<-------------->| | IP address o | | | re-config. | Sec.Assoc. | | | |<------------->| | | | | | | | Data traffic | | | |<-----------------> | | | | | | 13. What is "Secure Association"? If the channel below IP (L1,L2) is not protected against eavesdropping and spoofing prior to running PANA, a secure association protocol (e.g., IKE or 802.11i 4-way handshake) needs to be executed after PANA. That protocol takes EAP/PANA-generated keys to produce per-packet authentication and encryption keys to be used on IP data packets. That step can be omitted if a secure channel is already in place even before running PANA (e.g., physically secured DSL, and cryptographically secured cdma2000 links). Running a separate secure assocation protocol after client-network authentication is a commonly used technique (see IEEE 802.11i). 13.1. What is the significance of the chosen secure association protocol? For a totally L2 agnostic (All IP) solution, IKE is recommended to build IPsec SA for per-packet security following PANA authentication. An alternative is to have a hybrid solution, where client-network authentication is performed by L2-agnostic PANA, but the secure-association is L2 specific. E.g.: running IEEE 802.11i WPA-PSK mode after PANA. 13.2. What is the difference between this usage of IKE and what is discussed in Q&A#8? In this model, IKE is not used for client-network authentication, but simply for building IPsec SA once these two entities are authenticated. Even if you are using IKEv2, you would not carry EAP over IKEv2, but on PANA in this model. IKE will operate on pre-shared key mode. 13.3. Why would I want to use hybrid solution? Why not simply use native L2-only scheme (if there is one)? The hybrid model preserves the benefits of using PANA while yielding L2 per-packet security. 14. Are there any special EAP, RADIUS, DIAMETER, IKE, IPsec considerations for using them with PANA framework? No. PANA works with standards without breaking or having to extend them. It is a standard "EAP lower layer" per RFC 3748's definition, and readily plugs into well established EAP/RADIUS/Diameter framework. 15. Why do I need to configure an IP address on the PaC before PANA? PANA runs as a UDP-based application. The node (PaC) needs to have an IP address before sending and receiving UDP packets. 15.1. Where can the PaC get such an IP address? There are multiple ways to configure an IP address for PANA usage. - Using an IPv4 zeroconfigration (link-local) address. See RFC3927. - using an IPv6 link-local address. - Configuring a DHCP address. This address may have any one of these attributes: short-leased, temporary, private (non-routable). - Using a preconfigured IP address (limited number of deployments have that). 15.2. Now that the unauthenticated PaC has an IP address, isn't this a security hole? Can't the unauthenticated PaC start its end2end communication, hence effectively "stealing IP service?" No. PaC configuring an IP address does not mean that it gains unlimited access to the network. EP ensures that only limited types of packets (e.g, PANA, DHCP, ARP, ND, router discovery) are allowed until the successful completion of PANA. 15.3. Doesn't allocating an IP address before authentication open the doors for an IP address depletion-based DoS attack? Such a DoS attack qualifies as a "brute force attack" as it needs to deplete more than 16 million addresses (think 10/8 allocated by DHCP) -- if not more (think 2^64 IPv6 link-local addresses). Detection and prevention of this threat should be handled along with other attacks that aims choking down the access network (e.g., radio jamming, message blasting, etc.). In this class of attacks, neither allocating IP address strengthens, nor not allocating remedies the threat. For example, even if the access network were using EAP/L2, such as IEEE 802.1X, which does not require an IP address to run, the attacker can still deplete resources on the NAS by repeated attempts of engaging in EAP. Each EAP session created on the NAS consumes resources. 15.4. An operator may still not want to give away its premium IP address resources, or the IP address assignment might depend on the authenticated identity of the client. How does PANA framework handle that? The IP address assigned prior to PANA can be a temporary, private or link-local address (not premium address). Upon successful PANA authentication, the last PANA message notifies the client that it should re-configure a new IP address. The IP address configured by PaC after PANA can be a premium IP address that depends on the client identity. 16. What does a full-blown PANA call flow look like? PaC PAA | Client Initiation | +------------------------------> | | Auth-Req (Start) | | <------------------------------+ | Auth-Ans (Ack) | +------------------------------> | | Auth-Req (EAP ID req) | | <------------------------------+ | Auth-Ans (Ack) | +------------------------------> | | Auth-Req (EAP ID resp) | +------------------------------> | | Auth-Ans (Ack) | | <------------------------------+ | Auth-Req (EAP MD5 chal) | | <------------------------------+ | Auth-Ans (Ack) | +------------------------------> | | Auth-Req (EAP MD5 resp) | +------------------------------> | | Auth-Ans (Ack) | | <------------------------------+ | Auth-Req (Complete,EAP Success)| | <------------------------------+ | Auth-Ans (Ack) | +------------------------------> | | | * Now PaC is authorized to send/receive IP traffic This call illustrates running EAP-MD5 over EAP/PANA. PAA to AS interaction is not shown (assume they are co-located). 17. Can this call flow be abbreivated? Yes. PaC PAA | Auth-Req (Start,EAP MD5 chal) | | <------------------------------+ | Auth-Ans (EAP MD5 resp) | +------------------------------> | | Auth-Req (Complete,EAP Success)| | <------------------------------+ | Auth-Ans (Ack) | +------------------------------> | | | * Now PaC is authorized to send/receive IP traffic This short flow was possible due to: - Access network's ability to detect new PaC and send an unsolicited Start message. - PANA design's ability to start EAP exchange with the first Auth-Req message. - PANA design's ability to carry EAP messages on Answer messages (which are otherwise simple acknowledgements). - EAP-MD5 method's ability to piggyback client ID discovery on challenge-response exchange. Note: PAA may choose to grant access as soon as it transmits EAP Success payload. I.e., waiting for Ack is not mandatory. 18. What is PANA pre-authentication? Since PANA can run across multiple routers, it can be used to pre-authenticate with potential target NAS(es) before the handover takes place. The host can choose to use PANA only for pre-authentication, while relying on other L2 security protocols/mechanisms for anything else. See draft-ietf-pana-preauth-02.txt. 19. What kind of performance optimizations are offered by PANA framework? Several types and levels of optimizations are made possible in this framework. - The NAS can be located deeper in the access network compared to what can normally be done with L2 protocols. NAS located on access router or further deeper instead of on L2 access point (AP) allows single run of EAP/PANA to access any one of the L2 APs managed by the same NAS. Hence, inter-AP handovers do not require any other AAA execution. - Even when the PaC performs a inter-NAS (inter-PAA) handover, the context-transfer-based PANA optimization allows using on-going PANA session, effectively eliminating the need to run the lengthy EAP authentication with the remote AS. - PANA pre-authentication allows pre-handover authorization. This feature can be used across the Internet, for any L2 technology. It can be used in conjunction with L2 security that is used upon handover. - AVP-based extensible PANA message format allows standard and vendor-specific extensions which can be used to piggyback additional information exchange on top of the on-going PANA authentication. This can reduce the required round-trips between the PaC and the network elements. - Operators can allow additional limited protocol signaling to take place in parallel (out-of band) with PANA. E.g.: Mobile IPv6 binding update while executing PANA. - If multiple authentications need to be performed (e.g., one for the access device, another for the user), they can be carried out in parallel as two distinct PANA sessions. An appropriate implementation can bind the two PANA sessions under one network access session. - PANA can take advantage of IP-layer fragmentation, which becomes an important performance factor when using EAP methods with large payloads (e.g., certificated-based methods). In the absence of such a lower-layer fragmentation, one needs to rely on fragmentation at the EAP method layer. Due to lock-step nature of EAP, this increases the round-trips between the EAP peer and authentication server (cannot send the next fragment until the receipt of previous one is acknowledged). 20. What kind of authorization is possible with PANA? The base specification allows a simple binary authorization -- the PaC is either allowed unlimited IP access, or not. Fine granularity authorization request and result can be encoded on top of that by defining appropriate standard or vendor-specific authorization AVPs. 21. I heard about building service-specific local security associations using PANA. What is that? By default a successful PANA authentication yields a PANA SA between PaC and PAA, that is used for network access service. Additional SAs can be built by defining appropriate AVPs -- such as DHCP SA, Mobile IP SA, etc. For an example see http://www.watersprings.org/pub/id/draft-yegin-eap-boot-rfc3118-00.txt. 21.1. Couldn't I do the same with other EAP transports? In order to realize this, you need AVP-based extensibility to negotiate service specific parameters, especially the ones needed for building SAs. Check your favorite EAP lower-layer to see if it can do that. 22. What are the other PANA features worth noting? - Protected PANA signaling: PANA messages can be integrity protected using a MIC. This protection can be enabled along with the first EAP-Success message sent to the PaC. This security prevents exploitation of management signaling for DoS attacks (e.g., DoS based on unsecured EAP-Logoff messages in IEEE 802.1X). - Independence from L2 connection: When PANA is used, network access AAA can be completely undundled from L2 connection establishment. This allows asynchronous, on-demand AAA that can be dynamically enforced based on the network usage. Furthermore, multiple dynamic network access sessions can be created on top of single L2 connection. - Implementation: PANA can be implemented and deployed as a UDP-based application, which eliminates the impact on drivers/firmware. - Deployment flexibility: PAA and EP can be located anywhere on the access subnet. They are not limited to be on the L2 access device, or even be co-located. One PAA can manage multiple EPs. 23. Where can I find a PANA implementation? An open source PANA implementation on Linux, FreeBSD, Windows 2000/XP can be found at http://www.opendiameter.org. [Note: Don't be confused about the parent project name -- PANA implementation is not specific to Diameter protocol specification or implementation]. 24. If PANA is not bundled on the target client OS, what can I do? Until the PANA client becomes bundled in the target OS, it can be implemented by 3rd parties as a UDP-based application and installed on the target platforms. Alternatively, it can be implemented on the driver below IP. Both techniques are commonly used for rolling new technologies in the market (e.g., see various Mobile IP implementations for Windows). 25. Where can I find more information? Official IETF PANA WG web page: http://www.ietf.org/html.charters/pana-charter.html Additional PANA web page: http://panasec.org ------ For questions/comments: faq at panasec dot org ------------------------