Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs
Extracted elements (25)
An encryption policy table format (Y/N/X columns) is introduced so that future AVP specifications can declaratively state their encryption requirements, enabling consistent validation behavior across implementations without per-AVP ad hoc rules.
Two directional keys (PANA_PAC_ENCR_KEY for PaC→PAA and PANA_PAA_ENCR_KEY for PAA→PaC) are defined separately rather than using a single shared key. This prevents replay across directions and follows standard bidirectional key separation practice.
After decryption and unencapsulation, the legitimate occurrence of AVPs recovered from an Encryption-Encap AVP is still subject to the AVP Occurrence Table (Figure 4 of RFC 5191), not just the encryption policy table.
The PRF used in the prf+ key derivation function SHALL be negotiated using the existing PRF-Algorithm AVP in the initial PANA-Auth-Request/Answer exchange with the 'S' bit set, as defined in RFC 5191 Section 4.1.
If Encryption-Encap AVPs are being sent from the PaC to the PAA and the sequence number is about to wrap, the PaC SHALL initiate PANA re-authentication. Similarly, if sending from PAA to PaC with a sequence number about to wrap, the PAA SHALL initiate re-authentication.
In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR as the encryption algorithm.
PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY SHALL NOT be used for purposes other than those specified in this document. Compromise of these keys would lead to compromise of the secret information protected by them.
The Encryption-Encap AVP SHALL only be used if the EAP method generates cryptographic keys (specifically the MSK). It may be used starting from the very first PANA message carrying a Result-Code AVP set to PANA_Success.
The PAA SHALL send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs it supports. The PaC SHALL select one algorithm and respond with the initial PANA-Auth-Answer carrying exactly one Encryption-Algorithm AVP for the selected algorithm.
The Session ID and Sequence Number values in the AES128_CTR nonce SHALL be the same as those in the PANA message carrying the Encryption-Encap AVP. The Key-Id value SHALL be the same as the one used for deriving the encryption keys.
The specification of any AVP SHOULD state whether the AVP shall or shall not be encrypted using the Encryption-Encap AVP. If the specification is silent, the AVP MAY be encrypted.
There SHALL be only one Encryption-Encap AVP in a PANA message. All AVPs that require encryption SHALL be encapsulated within that single Encryption-Encap AVP.
When an AVP has encryption policy 'Y' (required), if the AVP is encountered not encrypted it SHALL be considered invalid and the containing message SHALL be discarded. When policy is 'N' (forbidden), an encrypted occurrence SHALL also be discarded.
PANA_PAA_ENCR_KEY = prf+(MSK, "IETF PANA PAA Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID). This key encrypts AVPs sent from the PAA to the PaC. Both keys' lengths depend on the negotiated encryption algorithm.
PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID). This key encrypts AVPs sent from the PaC to the PAA. The prf+ function is defined in IKEv2 (RFC 5996).
The Encryption-Algorithm AVP (AVP code 13) conveys the negotiated encryption algorithm for use with the Encryption-Encap AVP. Its value data is of type Unsigned32; currently only AES128_CTR (code 1) is defined.
The Encryption-Encap AVP (AVP code 12) encapsulates one or more PANA AVPs in encrypted form. When AES128_CTR is negotiated, the AVP data payload is occupied by the ciphertext of the encapsulated AVPs.
A new "Encryption-Algorithm (AVP Code 13) AVP Values" sub-registry created under the PANA Parameters registry. Value 1 assigned to AES128_CTR; all other values (0, 2–4294967295) are unassigned. Registration requires IETF Review or IESG Approval.
An encryption policy column labeled "Enc" has been added to the existing "AVP Codes" sub-registry, applied to all existing AVP codes and those defined in this document, recording Y/N/X encryption requirements per AVP.
Two new AVP codes registered in the "AVP Codes" sub-registry under "Protocol for Carrying Authentication for Network Access (PANA) Parameters": code 12 for Encryption-Encap AVP and code 13 for Encryption-Algorithm AVP.
AES-CTR nonce uniqueness-per-key is guaranteed as long as the PANA sequence number does not wrap. When the sequence number approaches wraparound, re-authentication is mandated to generate a fresh MSK and new encryption keys.
PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY are secret keys shared between PaC and PAA. They must not be used for purposes other than AVP encryption; compromise leads to disclosure of all protected AVP payloads.
RFC 5191 guarantees that an AUTH AVP is always present in every PANA message after key generation. Therefore, an Encryption-Encap AVP is always accompanied by an AUTH AVP, satisfying AES-CTR's companion authentication requirement.
The AES128_CTR nonce is 12 octets composed of: a 4-octet Key-Id, a 4-octet Session ID, and a 4-octet Sequence Number, each encoded in network byte order. These are used as input to the formatting and counter generation functions from NIST SP800-38C with parameters n=12, q=3.
The first counter block for AES128_CTR encryption is Ctr_1: a 1-octet Flags field (0x02) followed by the 12-octet nonce (Key-Id | Session ID | Sequence Number) followed by a 3-octet counter initialized to 1, yielding a 16-octet block.