Skip to content

Protocol for Carrying Authentication for Network Access (PANA)

Carry an Extensible Authentication Protocol exchange and its session state over UDP between an IP device and a network access authority without defining the authentication method or performing access enforcement itself.

Version
v2 · 2026-09-06 · History
Domain-specific #
2559
Origin domain
computer science
Subdomain
internet protocols
Aliases
PANA, Protocol for Carrying Authentication for Network Access

Core Idea

Protocol for Carrying Authentication for Network Access, abbreviated PANA, is an Internet protocol that transports an Extensible Authentication Protocol exchange between an IP device seeking access and a network-side authentication agent. RFC 5191 defines the PANA Client and PANA Authentication Agent, UDP carriage, messages, session state, sequencing, retransmission behavior, and protocol phases.[1] Its defining move is architectural separation. EAP methods establish the authentication evidence exchange; PANA carries that exchange across an IP network and maintains the surrounding access-authentication session; an enforcement point applies the authorization result. PANA does not invent a password, certificate, or cryptographic authentication method of its own.

A PANA session progresses through initial handshake and authentication, an access phase that can include liveness tests or reauthentication, and termination. PANA-Auth-Request and PANA-Auth-Answer messages carry EAP payloads. A session identifier and monotonically managed sequence numbers correlate state and reject inappropriate repeats; retransmission rules address unreliable UDP carriage. When the selected EAP method generates keying material, an AUTH attribute-value pair can protect later PANA messages. This protection authenticates the PANA session transcript after key establishment; it should not be misdescribed as replacing the EAP method or automatically encrypting all traffic.

The PANA framework separates the PaC, PAA, Authentication Server, and Enforcement Point roles, allowing some roles to be collocated while preserving their responsibilities.[2] The PAA acts as the EAP authenticator-facing carrier endpoint and can consult a separate backend authentication server. The enforcement point controls packet forwarding or access according to authorization state and may be configured through another mechanism. RFC 5191 also makes clear that PANA can be used over an IP link without assuming a particular link-layer access technology. This makes PANA a stable protocol abstraction rather than merely the name of a software package or product.

EAP itself is a framework for carrying authentication exchanges and negotiating an authentication method; RFC 3748 distinguishes the peer, authenticator, pass-through authenticator, and backend server roles.[3] PANA reuses that method-neutral exchange above IP/UDP. Its autonomous residual is IP-reachable access client + PANA agent + carried EAP payloads + reliable session state over UDP + lifecycle transitions + separation from enforcement. The strict parent is Authentication through composition/presupposition: PANA is a protocol scaffold that presupposes an authentication evidence method and transports it to a verdict-bearing access authority. It is not a strict subtype of every authentication mechanism, because it deliberately leaves the evidence method to EAP.

Structural Signature

  • A PANA Client. An IP device acts as the peer seeking authenticated network access.
  • A PANA Authentication Agent. A network-side endpoint terminates the PANA exchange and represents the access authority.
  • UDP transport. PANA messages travel over IP using the registered transport and protocol framing defined by the RFC.
  • Carried EAP payloads. Authentication method exchanges are encapsulated rather than redefined.
  • A session identifier. Messages are bound to the correct PANA session after establishment.
  • Sequencing. Request and answer messages use sequence state to correlate exchanges and control duplicates.
  • Retransmission behavior. The protocol compensates for loss without assuming reliable transport.
  • Lifecycle phases. Initiation, authentication, access, reauthentication or liveness, and termination are distinguished.
  • Optional keyed message authentication. Key-generating EAP methods can support an AUTH attribute for later PANA messages.
  • Authorization signaling. Success or failure informs an access-control decision without itself forwarding or blocking user traffic.
  • Role separation. Authentication server and enforcement point can be distinct from the PAA.
  • Method independence. The chosen EAP method supplies credentials, challenge semantics, and key properties.

What It Is Not

  • Not an authentication method. PANA carries EAP; it does not define passwords, certificates, biometrics, or a new EAP method.
  • Not EAP itself. EAP supplies the method negotiation and exchange framework; PANA supplies one IP-based lower-layer carrier and session protocol.
  • Not an enforcement point. The protocol communicates state but does not by itself filter data traffic.
  • Not a link-layer protocol. It operates over IP and UDP rather than being tied to one physical or data-link technology.
  • Not a general VPN. It does not create a user-data tunnel or promise confidentiality for application traffic.
  • Not IPsec. Keying and access authorization can support other protection arrangements, but PANA is not the IPsec security association protocol.
  • Not RADIUS or Diameter. Those are common backend AAA protocols; PANA is the access-device-to-PAA exchange.
  • Not merely UDP encapsulation. Session IDs, sequencing, retransmission, lifecycle, and role semantics are constitutive.

Scope of Application

PANA applies when an IP-capable access device must conduct method-neutral EAP authentication with a network access authority independently of the underlying link technology.

  • Heterogeneous access links. Reusing one access-authentication carrier across IP-bearing technologies.
  • Network admission. Establishing an authenticated session before or during authorization to use a network.
  • EAP method portability. Carrying existing and future EAP methods without redesigning the access protocol.
  • Separated enforcement. Coordinating a PAA with an enforcement point that applies access state elsewhere.
  • Backend AAA integration. Allowing the PAA to pass authentication work to an external server.
  • Session reauthentication. Repeating authentication within an established protocol lifecycle.
  • Liveness management. Detecting whether the peer relationship remains active under the RFC-defined exchange.
  • Standards analysis. Comparing IP-layer access authentication with link-layer EAP lower layers and tunneling systems.

Clarity

Name the PANA Client, PANA Authentication Agent, optional backend Authentication Server, and Enforcement Point, and say which are collocated. Identify PANA as the EAP carrier and name the selected EAP method separately. State that UDP delivery requires PANA sequencing and retransmission rules. Distinguish protocol authentication success from authorization policy and from actual packet enforcement. Do not claim confidentiality for PANA or user traffic unless another specified mechanism supplies it. If an EAP method generates keys, state which PANA messages receive AUTH protection and do not generalize beyond the RFC. Record the RFC version and updates because standards status and registries can change. Identify whether IP connectivity exists before PANA and what restricted access is permitted during authentication. Separate a failure to authenticate, an authorization denial, a transport timeout, and an enforcement failure. Avoid using ‘server’ loosely: the PAA is the PANA endpoint, whereas a backend Authentication Server may evaluate EAP through another protocol. State any deployment-specific discovery or configuration mechanism rather than attributing it to PANA core.

Manages Complexity

Network access authentication spans several layers and organizations. A device must reach an access authority, select and execute an authentication method, survive packet loss, associate responses with the right conversation, receive an authorization outcome, and have that outcome enforced on user traffic. PANA manages this complexity by defining a method-neutral IP carrier and state machine. EAP methods remain modular and can change without redesigning PANA framing. UDP remains lightweight while explicit sequencing and retransmission restore the reliability needed by the exchange. Named roles make trust and responsibility auditable: the PaC requests, the PAA terminates PANA, a backend server may evaluate evidence, and an enforcement point controls traffic. Lifecycle phases localize initialization, access, reauthentication, liveness, and termination behavior. The separation prevents protocol prose from pretending that carrying an authenticated result is the same as applying network policy. Its cost is deployment coordination: another mechanism must arrange enforcement, and the security of the whole system still depends on method selection, key handling, configuration, and the preauthentication network path.

Abstract Reasoning

  1. Identify the access device acting as PANA Client and the network authority acting as PANA Authentication Agent.
  2. Establish the limited IP and UDP reachability required to begin the exchange.
  3. Initialize protocol state, including message direction, session association, and sequence expectations.
  4. Select an EAP method according to the EAP and deployment policy rather than inventing one inside PANA.
  5. Carry EAP request and response payloads in the corresponding PANA authentication messages.
  6. Apply retransmission and duplicate-handling rules when UDP messages are lost or repeated.
  7. Keep backend Authentication Server processing distinct from the PANA transport endpoint.
  8. Derive and apply AUTH protection only when the EAP outcome provides the required keying material.
  9. Translate successful authentication into a separately governed authorization state.
  10. Communicate that state to the enforcement arrangement without claiming PANA performs packet filtering.
  11. Maintain liveness, reauthentication, and termination transitions for the established session.
  12. Audit failures by layer: carrier, session state, EAP method, authorization, or enforcement.

Knowledge Transfer

The strict parent is Authentication by composition and presupposition. PANA packages transport and lifecycle around the accepted prime's claimed-identity, evidence-exchange, verification, and verdict structure, while delegating the evidence method to EAP. The transferable lesson is to separate a method-neutral carrier, a verifier, a policy decision, and enforcement. The nontransferable accent is the RFC-defined PaC/PAA roles, UDP framing, EAP payload carriage, attributes, and PANA state machine.

Examples

Canonical

An IP device with limited preauthentication connectivity begins a PANA session with the network's PAA. The PAA sends an EAP request inside a PANA-Auth-Request, and the client returns the EAP response inside a PANA-Auth-Answer. Sequence state and retransmission rules preserve the exchange over UDP. When the EAP method succeeds, the PAA records the outcome and the deployment's enforcement point changes access according to policy. PANA carried and managed the exchange; the EAP method evaluated credentials, and the enforcement point controlled packets.[1]

Mapped back: PaC with limited IP reachability → PANA session and carried EAP exchange → authentication result → separate authorization and enforcement action.

Applied / In Practice

An architect compares PANA with a link-specific EAP lower layer. The PANA option preserves the organization's EAP methods while moving the carrier to IP/UDP and centralizing the PAA role. The design review separately documents bootstrap reachability, backend AAA, enforcement-point signaling, and user-data protection. This avoids the common error of listing PANA as though it supplied all four functions.

Mapped back: method-neutral access requirement → IP carrier selection → explicit role separation → independently reviewed enforcement and data protection.

Structural Tensions

  • Method neutrality vs. security outcome. PANA can carry strong or weak EAP methods. Diagnostic: Which component establishes evidence and key properties?
  • Unreliable transport vs. stateful exchange. UDP may lose or duplicate messages. Diagnostic: Are sequence and retransmission rules implemented as protocol state?
  • Authentication vs. authorization. A verified identity does not determine permitted access. Diagnostic: Where is policy evaluated after the EAP result?
  • Authorization vs. enforcement. A decision does not itself block packets. Diagnostic: Which enforcement point applies the state and by what separately specified relation?
  • Layer independence vs. bootstrap reachability. PANA requires IP before full admission. Diagnostic: What restricted path permits the initial PaC–PAA exchange?
  • Autonomous protocol vs. Authentication plus Interface. Many transports carry evidence. Diagnostic: Does the system implement the RFC-defined PaC/PAA state machine, lifecycle, sequencing, and EAP carriage?

Structural–Framed Character

PaC and PAA roles, UDP messages, EAP carriage, session IDs, sequencing, retransmission, lifecycle phases, and separation from enforcement are structural. EAP method, backend AAA protocol, access technology, enforcement implementation, credentials, and authorization policy are framed. The node is domain-specific because the structure is fixed by an Internet protocol standard.

Structural Core vs. Domain Accent

The portable core is method-neutral evidence carrier + session state + verdict handoff. The domain accent is EAP over UDP, PaC/PAA role names, PANA messages and attributes, retransmission rules, and network-admission lifecycle. Removing that accent leaves Authentication plus an Interface; retaining it yields PANA.

Authentication is the strict parent by composition and presupposition: PANA carries the identity-evidence exchange to the responsible verifier and maintains its session, but delegates method semantics to EAP and enforcement to another role.

The prospective workspace queue contains one strict upward edge to prime:authentication. No live DAG mutation is authorized.

Relationships to Other Abstractions

Local relationship map for Protocol for Carrying Authentication for Network Access (PANA)Parents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Protocol for Carryin…DOMAINPrime abstraction: Authentication — is a kind ofAuthenticationPRIME

Current abstraction Protocol for Carrying Authentication for Network Access (PANA) Domain-specific

Parents (1) — more general patterns this builds on

  • Protocol for Carrying Authentication for Network Access (PANA) is a kind of Authentication Prime

    Authentication is the strict parent by composition and presupposition: PANA carries the identity-evidence exchange to the responsible verifier and maintains its session, but delegates method semantics to EAP and enforcement to another.

Hierarchy path (1) — routes to 1 parentless root

  • Protocol for Carrying Authentication for Network Access (PANA) → Authentication

Neighborhood in Abstraction Space

Protocol for Carrying Authentication for Network Access (PANA) sits in a sparse region of the domain-specific corpus (100th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • Extensible Authentication Protocol. Defines the method-neutral exchange framework carried by PANA.
  • IEEE 802.1X. Provides port-based network access control and a link-layer EAP carriage architecture.
  • RADIUS. Commonly transports AAA information between a network access device and backend server.
  • Diameter. A broader AAA protocol family with different peers, applications, and transport assumptions.
  • Internet Key Exchange. Negotiates IPsec security associations rather than PANA access-authentication sessions.
  • Captive portal. Uses application-layer interaction and policy interception rather than the PANA state machine.

References

[1] Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, and Ashwin Yegin, ‘Protocol for Carrying Authentication for Network Access (PANA),’ RFC 5191, May 2008, https://doi.org/10.17487/RFC5191. registry ↩a ↩b

[2] Ashwin Yegin et al., ‘Protocol for Carrying Authentication for Network Access (PANA) Framework,’ RFC 5193, May 2008, https://doi.org/10.17487/RFC5193. registry ↩

[3] Bernard Aboba et al., ‘Extensible Authentication Protocol (EAP),’ RFC 3748, June 2004, https://doi.org/10.17487/RFC3748. registry ↩