Port Control Protocol (PCP) Authentication Mechanism
updates
- rfc-6887 — Port Control Protocol (PCP)
Extracted elements (30)
EAP was chosen as the authentication framework because it provides algorithm agility, handles credential exchange, and naturally produces keying material (MSK) for deriving transport keys. Encapsulating EAP inside PCP avoids out-of-band channels and allows the existing PCP UDP transport to carry authentication.
PA-Acknowledgement messages (RECEIVED_PAK) are excluded from sequence number incrementing because they carry no EAP payload and loss of an acknowledgement must not cause permanent sequence mismatch; this design also supports reassembly of fragmented EAP messages across multiple PA messages before a response is generated.
When a PCP proxy (RFC 7648) sits between PCP clients and a PCP server, the proxy authenticates independently with the server. Re-authentication between proxy and server does not interrupt service to clients because the proxy may continue sending common PCP messages during that period.
A PCP client and PCP server MUST perform a key-generating EAP method. Specifically, implementations MUST support EAP-TTLS (RFC 5281) and SHOULD support TEAP (RFC 7170).
A PCP implementation MUST support AUTH_HMAC_SHA2_256_128 (IKEv2 Transform Type 3, transform ID = 12) as the MAC algorithm for generating authentication data.
A PCP implementation MUST support PRF_HMAC_SHA2_256 (IKEv2 Transform Type 2, transform ID = 5) as the pseudorandom function for transport key derivation.
After receiving a PA-Initiation message, the PCP server MUST assign a unique Session ID and insert it into the PA-Server message. All subsequent PCP messages within the session MUST carry this Session ID.
After sending a PA message, a PCP device MUST NOT send any subsequent PA message until it receives a PA message with a proper sequence number from the peer; this ensures reliable delivery required by EAP.
After successful EAP authentication, every subsequent PCP message within the PA session MUST carry an authentication tag (AUTHENTICATION_TAG or PA_AUTHENTICATION_TAG) providing integrity protection and data origin authentication.
During re-authentication, common PCP messages MUST be protected with the current SA until the new SA has been generated; PA and common PCP sequence numbers are reset to zero after successful re-authentication.
Each PA message MUST contain an AUTHENTICATION Opcode. The PA-Initiation message MUST also contain a NONCE option carrying a client-generated random nonce to prevent spoofed PA-Server messages from interrupting the authentication process.
If a PCP client loses its PCP SA and sends a common PCP request, the server rejects it with AUTHENTICATION_REQUIRED. The client MUST authenticate with the server and, after successful EAP, retry the request with an AUTHENTICATION_TAG option.
If EAP authentication or authorization fails, the PA session MUST be terminated immediately after the failure result code PA message is sent. If session lifetime expires without re-authentication, the session MUST also be terminated immediately.
The first secure PA-Client message after successful authentication MUST include the full set of PRF and MAC_ALGORITHM options received from the server. If the server detects a downgrade attack (algorithm mismatch), it MUST send DOWNGRADE_ATTACK_DETECTED and terminate the session.
Upon receiving a SESSION_TERMINATED message, the recipient MUST respond with a termination-indicating PA message and MUST then remove the associated PCP SA immediately.
When a sequence number reaches 2^32 - 2^16, the session partner MUST trigger EAP re-authentication to prevent sequence number exhaustion.
When receiving or sending a PA-Acknowledgement message (a PA message containing a RECEIVED_PAK option), the device MUST NOT increment the corresponding sequence number stored in the SA, to prevent sequence number mismatch on acknowledgement loss.
The PA Security Association (PCP SA) contains: client and server IP/UDP addresses, Session ID, outgoing/incoming sequence numbers for both PA and common PCP messages, last outgoing payload, retransmission interval, MSK, MAC algorithm, PRF, transport key, client nonce, and key ID.
The transport key is derived as: transport_key = prf(MSK, "IETF PCP" || Session ID || Nonce || key ID), binding the key to the session identity and client nonce for freshness.
AUTHENTICATION opcode (value 3) allocated from the Standards Action range of the PCP Opcodes registry. Result codes 14–23 (INITIATION, AUTHENTICATION_REQUIRED, AUTHENTICATION_FAILED, AUTHENTICATION_SUCCEEDED, AUTHORIZATION_FAILED, SESSION_TERMINATED, UNKNOWN_SESSION_ID, DOWNGRADE_ATTACK_DETECTED, AUTHENTICATION_REQUEST, AUTHENTICATION_REPLY) allocated from the PCP Result Codes registry.
Nine PCP options allocated from the Standards Action range of the PCP Options registry: NONCE (4), AUTHENTICATION_TAG (5), PA_AUTHENTICATION_TAG (6), EAP_PAYLOAD (7), PRF (8), MAC_ALGORITHM (9), SESSION_LIFETIME (10), RECEIVED_PAK (11), ID_INDICATOR (12).
Before transport key establishment, PA messages have little cryptographic protection and are vulnerable to man-in-the-middle and DoS attacks. An attacker can strip PRF/MAC options from the initial exchange and force weaker algorithm selection; therefore all server-supported algorithms must individually be strong enough.
The chosen EAP method must (1) be resilient to attacks in an insecure network, (2) provide user-identity confidentiality and protection against dictionary attacks, and (3) support session-key establishment. To limit DoS exposure, PCP devices SHOULD generate as little state as possible during the initial PA message exchanges.
PA session states: (1) Initiation — client sends PA-Initiation or server sends AUTHENTICATION_REQUIRED; (2) EAP Exchange — PA-Server/PA-Client messages carry EAP request/response; (3) AUTHENTICATION_SUCCEEDED or AUTHENTICATION_FAILED/AUTHORIZATION_FAILED; (4) Active — common PCP messages protected by transport key; (5) Re-authentication — triggered by lifetime expiry or sequence number rollover; (6) Termination — SESSION_TERMINATED from either peer.
AUTHENTICATION_TAG option (Option Code 5): variable-length, fixed 12-octet header containing Session ID (32-bit), Sequence Number (32-bit), and Key ID (32-bit), followed by a variable-length Authentication Data (MAC); used to authenticate common PCP messages (MAP, PEER, ANNOUNCE).
EAP_PAYLOAD option (Option Code 7): variable-length, carries the EAP message verbatim; must end on a 32-bit boundary padded with zeros. Used within AUTHENTICATION Opcode messages to tunnel EAP over PCP.
NONCE option (Option Code 4): 4-octet fixed length carrying a random 32-bit nonce. Present in PA-Initiation and the corresponding PA-Server reply; used by the client to verify message freshness.
PA_AUTHENTICATION_TAG option (Option Code 6): variable-length, with a 4-octet fixed header (Key ID), followed by variable Authentication Data (MAC); used to authenticate PA messages; omits Session ID and Sequence Number because these appear in the AUTHENTICATION Opcode.
SESSION_LIFETIME option (Option Code 10): 4-octet fixed length, unsigned 32-bit integer in seconds (0 to 2^32-1). Sent in PA-Server messages to convey the authorization-derived lifetime of the PA session.
The AUTHENTICATION Opcode-specific information consists of two 32-bit fields: Session ID (identifies the PA session) and Sequence Number (monotonically increasing, detects reordering/duplication).