Protocol for Carrying Authentication for Network Access (PANA)
updated by
- rfc-5872 — IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)
Extracted elements (32)
EAP messages are carried in PAR messages; PAN messages are primarily acknowledgments. As an optimization, the PaC MAY piggyback an EAP message in a PAN to reduce round trips. This optimization SHOULD NOT be used when generating the EAP response requires significant time (e.g., user input), to avoid triggering unnecessary PAR retransmissions.
PANA is UDP-based rather than TCP-based because it must run between the EAP peer and EAP authenticator at network-layer before link-layer or transport-layer security is established. A UDP transport avoids dependence on TCP state that may not be available during initial network access.
The PAA may optionally remain stateless in response to a PCI by sending an initial PAR without an EAP-Payload and without starting a retransmission timer. This shifts the retry burden to the PaC (which retransmits PCI until it receives a second PAR), preventing resource exhaustion at the PAA from spoofed PCI floods.
A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-Auth-Answer messages following the initial (S-bit) exchange, and MUST NOT appear in any other message except during re-authentication. This nonce feeds into PANA_AUTH_KEY derivation.
A received PANA message is invalid if: any header field is invalid; the message type is unexpected for the current phase; required AVPs are missing or misplaced; AVPs cannot be decoded; or a post-EAP-Success message lacks an AUTH AVP whose value matches the computed hash. Invalid messages MUST be discarded.
All PANA implementations MUST support the AUTH_HMAC_SHA1_160 (IKEv2 Transform ID 7) integrity algorithm as defined in RFC 4595, and MUST support the PRF_HMAC_SHA1 (IKEv2 Transform ID 2) pseudo-random function as defined in RFC 2104.
Implementations MUST limit the rate of performing liveness tests (ping). There is no protocol-level negotiation of ping timers; rate limiting is handled locally by each peer independently.
PANA request messages MUST be retransmitted until an answer is received or the maximum retransmission count is reached, at which point the PANA session MUST be terminated immediately. Invalid messages MUST be discarded to provide robustness against DoS attacks.
Ping request and answer messages (PNR/PNA with 'P' bit set) MUST be protected with an AUTH AVP when a PANA SA is available. A ping request MUST NOT be sent during the authentication, re-authentication, or termination phases.
Re-authentication of an ongoing PANA session MUST NOT reset the sequence numbers. The first PAR and PAN in the re-authentication phase MUST have the 'S' bit cleared and carry a Nonce AVP.
The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'S' (Start) bit set regardless of who initiated the session. All other messages MUST NOT have the 'S' bit set. Similarly, the final PAR and PAN in authentication/re-authentication MUST have the 'C' (Complete) bit set; all other messages MUST NOT.
When a key-generating EAP method is used and an MSK is successfully generated, the last PAR with the 'C' bit set MUST contain a Key-Id AVP and an AUTH AVP. Any subsequent PANA message in that session MUST also contain an AUTH AVP.
When a new MSK is derived during re-authentication, any key derived from the old MSK MUST be updated to one derived from the new MSK. One Key-Id AVP MUST be carried in the final C-bit PAR and PAN, containing a value that uniquely identifies the MSK within the PANA session.
When a PaC changes its IP address, it MUST send any valid PANA message. If that message is valid and carries the new source IP address, the PAA MUST update the session record with the new PaC address. If a PANA SA exists, the message MUST be AUTH-protected.
When the last PAR with the 'C' bit set carries Result-Code PANA_SUCCESS, a Session-Lifetime AVP MUST also be present. The PaC MUST initiate re-authentication before the current session lifetime expires if it wishes to maintain access.
A PANA Security Association (PANA SA) stores: PaC_nonce, PAA_nonce, MSK, MSK Identifier, PANA_AUTH_KEY, the negotiated PRF, and the negotiated integrity algorithm. The SA lifetime equals the PANA session lifetime and is deleted upon session termination.
Message authentication uses: AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU), where PANA_PDU is the full PANA message (header + payload) with the AUTH AVP Value field initialized to zero. The integrity algorithm is the one negotiated via Integrity-Algorithm AVP in the initial S-bit exchange.
PANA defines seven message types: PCI (type 1, PaC→PAA only), PAR/PAN (type 2, bidirectional), PTR/PTA (type 3, bidirectional), and PNR/PNA (type 4, bidirectional). The R-bit in the Flags field distinguishes requests from answers for the same message type number.
PANA maintains two 32-bit sequence numbers per peer: one for outgoing requests and one for expected incoming requests. Numbers are monotonically incremented by 1 per new request and wrap to zero after 2^32-1. Initial sequence numbers are randomly chosen; the PCI message always carries sequence number 0.
Retransmission uses DHCPv6-style exponential backoff: RT = IRT + RAND*IRT for the first retransmission; RT = 2*RTprev + RAND*RTprev subsequently, capped at MRT. RAND is uniformly distributed in [-0.1, +0.1]. PCI defaults: IRT=1s, MRT=120s, MRC=0, MRD=0. Request defaults: IRT=1s, MRT=30s, MRC=10, MRD=0.
The Nonce AVP (code 5) carries a randomly chosen OctetString of 8–256 octets. The recommended maximum length is 20 octets (full HMAC-SHA1 output length). If both peers are trusted to generate random values, 10 octets (half the PRF key length) suffices; otherwise the full PRF key length is required.
The PANA_AUTH_KEY is derived as: PANA_AUTH_KEY = prf+(MSK, "IETF PANA" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID), where prf+ is the IKEv2 function from RFC 4306, I_PAR and I_PAN are the initial (S-bit) message bodies, and Key_ID is the MSK identifier from the Key-Id AVP.
IANA assigns UDP port 716 to PANA. All PANA peers MUST listen on this port. The session initiator uses it as the destination port; the responder copies the initiator's source port as its destination port for replies.
IANA maintains the PANA AVP Code registry (16-bit; values 1–9 defined here; further assignments by Designated Expert with Specification Required or Standards Action). PANA also supports vendor-specific AVP namespaces keyed by the IANA Enterprise Number in the Vendor-Id field.
IANA maintains the PANA Message Type registry (values 1–65519 by IETF Consensus; 65520–65535 reserved for experiments). This document defines types 1–4. The same type number is shared by request and answer messages (except type 1); the R-bit distinguishes them.
Monotonically increasing, randomly initialized sequence numbers prevent replay attacks by causing stale or duplicate messages to be silently discarded. An adversary must eavesdrop to inject a valid sequence number, significantly raising the bar for spoofing attacks on ongoing PANA/EAP sessions.
Networks without lower-layer security prior to PANA MUST use key-generating EAP methods. The PANA_AUTH_KEY is derived to be session-unique by incorporating nonces and message bodies, cryptographically separating it from the MSK. Per-packet data-traffic ciphering can be enabled post-authentication using keys derived from the PANA SA.
The initial PANA-Auth-Request/Answer exchange is unauthenticated and vulnerable to spoofing. The PAA mitigates DoS by minimizing state creation in the initial exchange (optionally omitting EAP-Payload in the first PAR and not retransmitting it). Rate-limiting of incoming PCI messages is also recommended.
The PAA-to-EP communication channel must be protected for authentication, integrity, and replay prevention, because the PAA provisions per-PaC authorization filters on the EP. The protocol for this channel is outside PANA's scope but its security is a deployment requirement.
A PANA session transitions through four phases: Authentication and Authorization (initial EAP exchange), Access (data traffic allowed, liveness testing), Re-authentication (EAP re-run to extend session), and Termination (explicit disconnect or session expiry). Re-authentication is a sub-phase of Access; failure in re-authentication terminates the session.
Each AVP carries: a 16-bit AVP Code, a 16-bit AVP Flags field (V-bit for vendor-specific), a 16-bit AVP Length (value octets only, excluding header fields), a 16-bit Reserved field, an optional 32-bit Vendor-Id, and a variable-length Value field. OctetString AVPs MUST be padded to a 32-bit boundary; padding is not counted in AVP Length.
The PANA message header is 16 octets: a 16-bit Reserved field (must be zero), a 16-bit Message Length (total message including header), a 16-bit Flags field (R/S/C/A/P/I bits), a 16-bit Message Type, a 32-bit Session Identifier, and a 32-bit Sequence Number, followed by AVPs. All fields are in network byte order.