Summary

  • RFC 5191 makes an unusually useful distinction: an EAP method can succeed while the network-access authorization decision fails. Identity proof and permission are separate events with different authorities.
  • Even a successful PANA exchange is not the whole service receipt. A separate Enforcement Point applies packet filters, IP reconfiguration may still be required, and the PANA security association protects signaling rather than automatically protecting or delivering user traffic.

The easiest access-control mistake is to make the word “success” carry more authority than its issuer possesses. An EAP method answers a question about authentication. A PAA or its AAA path answers whether that authenticated client is authorized for network access. An Enforcement Point answers, through installed state, what packets will actually pass. The path and application answer whether those packets arrived and mattered.

RFC 5191 does not blur these layers. It describes the Protocol for Carrying Authentication for Network Access as a UDP-based lower layer for EAP. PANA moves EAP between a client, the PaC, and a PANA Authentication Agent, the PAA. It lets the PAA convey the outcome of authentication and authorization. It does not turn one method result into all of those outcomes at once.

That is why the specification explicitly handles the case in which EAP produces Success but network access is rejected by an AAA server or locally by the PAA. The final PANA-Auth-Request carries PANA_AUTHORIZATION_REJECTED; the final exchange may still be cryptographically protected if key material exists; the session then terminates. The authentication evidence remains real. So does the denial.

An operator who stores only “EAP Success” has not simplified the record. The operator has deleted the decision that controls access.

The method result and the access decision

PANA has a clear division of labour. EAP supplies the authentication framework and the selected EAP method performs its credential exchange. PANA carries that exchange over IP and maintains the session. The PAA, possibly using backend AAA infrastructure, makes or conveys the network-access authorization decision.

These components can agree, but their agreement is not structural identity. A valid credential may identify a subscriber whose account is suspended, a device whose posture is unacceptable, a tenant outside an allowed time window, or a principal whose requested service is not authorized. RFC 5191 does not enumerate a commercial policy. It preserves the technical fact that authentication success and authorization rejection can coexist.

The evidence object must therefore keep at least four fields apart: EAP outcome; method and peer identity; authorization result and decision source; and PANA session disposition. If a Master Session Key was produced, its existence belongs to the authentication record. It does not overwrite the authorization result.

This distinction also changes incident language. “The user failed authentication” is false when the credentials succeeded and policy denied access. “The network admitted the user” is false when only EAP Success was observed. Accurate language is not a cosmetic preference. It determines whether the next investigation goes to identity infrastructure, policy, accounting, PAA state or enforcement.

The Complete bit does not execute every control surface

At the end of the authentication-and-authorization phase, the final PANA-Auth request and answer use the Complete bit. When the result is PANA_SUCCESS, the request also carries the session lifetime. With a key-generating EAP method, the final exchange includes the Key-Id and AUTH material needed to protect later PANA signaling.

That completion has a precise scope. It completes the PANA authentication-and-authorization exchange between PaC and PAA. It is not a packet capture from every Enforcement Point. RFC 5191 allows the PAA and EP to be separate nodes and places the PAA-to-EP protocol and access-control filter creation outside the protocol specification.

This is the operational gap hidden by a single green state. A PAA can possess a successful authorization decision while an EP projection is pending, rejected, stale or installed on only part of the path. The standard requires PAA-to-EP provisioning to be protected for authentication, integrity and replay protection. That requirement shows the projection is a real control transaction. It is not proof that the transaction occurred in a particular deployment.

A defensible receipt identifies the target EP set, policy version, PaC and interface binding, transaction identifier, acknowledgement, installed filter fingerprint and observation time. If there are several EPs, success is a vector, not a Boolean. “Three of four policy targets acknowledged version 27” is useful. “PANA succeeded” is not a substitute.

An authenticated address may still be unusable

RFC 5191 also permits a successful authentication-and-authorization phase to end with the instruction that the PaC must reconfigure its IP address. The PAA sets the IP Reconfiguration bit because the address used for PANA may not be suitable for exchanging data through the EP.

The mechanism matters because many access dashboards make an address look like a stable subject identifier. Here the same device can authenticate over one address and then need another address for the access phase. How reconfiguration happens is outside RFC 5191.

The operation receipt therefore needs an address timeline: the pre-authentication source used by PANA, the reconfiguration instruction, the new address and lease provenance, interface binding, route and neighbour readiness, and the first observed permitted packet. Without that sequence, a support system may test the obsolete address, attach enforcement state to the wrong tuple, or call the access phase complete before the client has usable network configuration.

The right conclusion is not that the PANA result was wrong. It is that the result belonged to a control phase whose downstream projection had not yet been observed.

The PANA security association protects signaling

When the EAP method exports an MSK, PANA can create a PANA Security Association. The derived PANA_AUTH_KEY protects the PANA message header and payload, including carried EAP messages, through the AUTH AVP. This resists injection, modification and replay within the signaling exchange.

That is valuable evidence, but its boundary must remain visible. RFC 5191 defines the PANA SA as protection for bidirectional PANA signaling between PaC and PAA. It separately discusses per-packet data-traffic ciphering. Where the lower layer did not already secure traffic, keys may be derived and used with a secure-association protocol, such as link-layer protection or IPsec. How those keys are generated from the PANA SA and used is outside the document.

An authenticated final PANA exchange therefore does not prove that user packets were encrypted. It does not name the data-plane algorithm, show that a child security association was installed, attest the selectors, prove replay protection on data packets or establish remote receipt.

Operations should store the PANA SA and data-plane SA as different objects with a derivation edge between them. The first needs session ID, Key-Id, lifetime and protected-message verification. The second needs endpoints, selectors, algorithms, key identifiers, installation state, counters and expiry. If no data-plane ciphering is required, that too should be an explicit policy result rather than an inference from missing telemetry.

A live peer is not a working service

During the access phase, PANA notification request and answer messages can test peer liveness. A valid answer to a recent request indicates that the PANA peer is alive. RFC 5191 warns that periodic keepalive use needs care because congestion may create false alarms.

The liveness receipt belongs to the control peer. It does not show that the EP is forwarding the subscriber's traffic, that the current address is routed, that a remote endpoint replied or that an application transaction succeeded. A PAA process can answer while a separate EP has lost state. A control path can remain reachable while a data path is congested or filtered.

This is a recurring observability trap: the cheapest probe is promoted to a health verdict for the most expensive path. The correction is to name the probe target. “PAA replied to authenticated PANA ping at time T” is strong and narrow. “User service healthy” requires a different measurement.

Lifetime is permission duration, not availability

The PANA session lifetime is bounded by the current authorization lifetime. Re-authentication can extend it, and expiry can clean up a disconnected peer. This makes the lifetime a control boundary for state and permission.

It is not an uptime promise. A one-hour session lifetime does not prove sixty minutes of filter presence, address validity, packet passage or application availability. Lower-layer indications may help detect disconnection sooner, but RFC 5191 calls their availability and reliability topology-dependent and treats them as hints unless peer liveness is actually verified.

For each session, keep the granted authorization lifetime, PANA SA lifetime, re-authentication attempts, EP rule expiry and observed service interval separately. When the values diverge, the divergence is the incident. Collapsing them into one expiry timestamp makes it impossible to tell whether permission ended, signaling failed, enforcement aged out or service broke for another reason.

Termination must converge on enforcement

Either PaC or PAA can explicitly terminate the session. The framework expects termination to remove PANA state, stop accounting and remove installed per-PaC state from the EPs. Silent disconnection may instead be cleaned up by lifetime expiry or failed liveness tests.

Again, the command and its effect occupy different systems when PAA and EP are separate. A protected termination message is evidence that a control request was authentic. It is not a direct read of every EP table after deletion.

The audit record should retain the termination cause, protected exchange, accounting close, target EP list, delete acknowledgements and a post-delete rule query or equivalent dataplane test. A stale allow rule and a stale deny rule create different risks, but both are control-plane convergence failures. Neither can be diagnosed from the PANA session state alone.

Discovery names a destination; it does not establish trust

RFC 5191 leaves dynamic PAA discovery to other mechanisms. RFC 5192 defines DHCP options that can provide PAA addresses, and RFC 6345 later defines a relay element. These records solve reachability and placement questions. They do not grant a discovered address all the authority of a successfully authenticated PANA peer.

Discovery provenance belongs in the evidence chain: which DHCP server or configuration supplied the candidate, on what interface, with what lease or relay context, and which subsequent PANA and EAP evidence authenticated the session. Treating a discovered endpoint as trusted before the authentication exchange reverses the protocol's purpose.

It also obscures failure. A wrong address, unreachable relay, forged discovery response, authentication rejection and EP installation failure may all appear to a user as “no access”. They need different receipts and different owners.

The operational receipt PANA actually needs

A usable evidence object begins with the PaC, interface, discovery source and intended service. It records every PANA request and answer with session ID, sequence number, retransmission state and validation result. It links the EAP method result without replacing the authorization decision.

At completion, it stores the PANA result code, decision source, Complete bit, Key-Id, AUTH verification and granted lifetime. If IP reconfiguration is requested, it appends the address transition rather than mutating the earlier address out of history.

Then it crosses the architectural boundary: target EPs, protected provisioning transactions, policy version, installed filters, removal deadlines and reconciliation results. If per-packet protection is required, it links the separately installed security association. Finally it records packet observation, remote receipt and application outcome.

Each stage can be green while a later stage remains unknown or red. That is not complexity for its own sake. It is the minimum record needed to know which actor had authority over which fact.

Sources

  1. RFC 5191 HTML
  2. RFC 5191 text
  3. RFC 5191 record
  4. IETF Datatracker RFC 5191
  5. RFC 5191 history
  6. RFC 5191 references
  7. RFC 5191 errata
  8. RFC 5192
  9. RFC 5192 record
  10. RFC 5193
  11. RFC 5193 record
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy