RFC 7652
Port Control Protocol (PCP) Authentication Mechanism
Port Control Protocol (PCP) Authentication Mechanism 🦋
Part 1 of 7, more coming bestie! 💖
okay so this is RFC 7652 🎀 It's a Standards Track document from the IETF, published in September 2015 (ISSN 2070-1721). The authors are M. Cullen and S. Hartman from Painless Security, plus D. Zhang and T. Reddy from Cisco. It updates RFC 6887, which is the base PCP spec. 👑
Internet Engineering Task Force (IETF) M. Cullen
Request for Comments: 7652 S. Hartman
Updates: 6887 Painless Security
Category: Standards Track D. Zhang
ISSN: 2070-1721
T. Reddy
Cisco
September 2015Abstract ✨
so an IPv4 or IPv6 host can use the Port Control Protocol (PCP) to manage the IP address-mapping and port-mapping info on NATs or firewalls, which helps it talk to remote hosts 🦋 But literally the uncontrolled making or deleting of IP address mappings on those devices can cause security risks, so it should be avoided 💀 Sometimes the client has to prove it's allowed to change, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that covers those cases 🔥 It uses the Extensible Authentication Protocol (EAP) to do the authentication between PCP devices.
This document updates RFC 6887.
Status of This Memo 🌸
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc7652 🧚
Copyright Notice 💜
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 6
3.1.1. Authentication Triggered by the Client . . . . . . . 6
3.1.2. Authentication Triggered by the Server . . . . . . . 7
3.1.3. Authentication Using EAP . . . . . . . . . . . . . . 8
3.2. Recovery from Lost PA Session . . . . . . . . . . . . . . 10
3.3. Session Termination . . . . . . . . . . . . . . . . . . . 11
3.4. Session Re-authentication . . . . . . . . . . . . . . . . 11
4. PA Security Association . . . . . . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 14
5.2. Opcode-Specific Information of AUTHENTICATION Opcode . . 16
5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 16
5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 17
5.5. PA_AUTHENTICATION_TAG Option . . . . . . . . . . . . . . 18
5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 19
5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 20
5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 20
5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 21
5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 21
6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Authentication Data Generation . . . . . . . . . . . . . 22
6.2. Authentication Data Validation . . . . . . . . . . . . . 23
6.3. Retransmission Policies for PA Messages . . . . . . . . . 24
6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 25
6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 26
6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 28
7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 29
7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 29
7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 30
7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 30
7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 30
7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 341. Introduction ✨
okay so with PCP [RFC6887], an application can flexibly manage the IP address-mapping info on its NATs and firewalls, and control their policies for processing incoming and outgoing IP packets 🌈 NATs and firewalls are both huge in network security, so there are tons of situations where authentication and access control are required to stop unauthorized users from getting at these devices 💅 This document defines a PCP security extension that lets PCP servers authenticate their clients with the Extensible Authentication Protocol (EAP). The EAP messages get encapsulated inside PCP messages during transmission. 🦋
The following issues are considered in the design of this extension:
- Loss of EAP messages during transmission.
- Reordered delivery of EAP messages.
- Generation of transport keys.
- Integrity protection and data origin authentication for PCP messages.
- Algorithm agility.
The mechanism in this document meets the security requirements to address the Advanced Threat Model described in the base PCP specification [RFC6887]. This mechanism can be used to secure PCP in the following situations:
- On security infrastructure equipment, such as corporate firewalls, that does not create implicit mappings for specific traffic.
- On equipment (such as Carrier-Grade NATs (CGNs) or service provider firewalls) that serves multiple administrative domains and does not have a mechanism to securely partition traffic from those domains.
- For any implementation that wants to be more permissive in authorizing applications to create mappings for successful inbound communications destined to machines located behind a NAT or a firewall.
2. Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 👑
Most of the terms used in this document are introduced in [RFC6887].
PCP client: a PCP software instance that is responsible for issuing PCP requests to a PCP server. In this document, a PCP client is also an EAP peer [RFC3748], and it is the responsibility of a PCP client to provide the credentials when authentication is required. 🎀
PCP server: a PCP software instance that lives on the PCP-controlled device, receives PCP requests from the PCP client, and creates appropriate state in response to that request. In this document, a PCP server is integrated with an EAP authenticator [RFC3748]. So when necessary, a PCP server can verify the credentials provided by a PCP client and make an access control decision based on the authentication result. 🧚
PCP-Authentication (PA) session: a series of PCP message exchanges transferred between a PCP client and a PCP server. The PCP messages that are part of a given session include the PA messages used to perform EAP authentication, key distribution, and session management, as well as the common PCP messages secured with the keys distributed during authentication. Each PA session is assigned a distinctive Session ID. 🦋
Session partner: a PCP implementation involved in a PA session. Each PA session has two session partners (a PCP server and a PCP client). 🌸
PCP device: a PCP client or a PCP server. 💜
Session lifetime: the lifetime associated with a PA session. The session lifetime of the PA session decides the lifetime of the current authorization given to the PCP client. ⏳
PA Security Association (PCP SA): an association formed between a PCP client and a PCP server by sharing cryptographic keying material and associated context. The formed duplex security association is used to protect the bidirectional PCP signaling traffic between the PCP client and PCP server. 🔐
Master Session Key (MSK): a key derived by the partners of a PA session, using an EAP key-generating method (e.g., the method defined in [RFC5448]). 🗝️
PCP-Authentication (PA) message: a PCP message containing an AUTHENTICATION Opcode. Specifically, a PA message sent from a PCP server to a PCP client is referred to as a PA-Server message, while a PA message sent from a PCP client to a PCP server is referred to as a PA-Client message. So a PA-Server message is actually a PCP response message as specified in [RFC6887], and a PA-Client message is a PCP request message. This document specifies an option (the PA_AUTHENTICATION_TAG option defined in Section 5.5) for PCP authentication to provide integrity protection and message origin authentication for PA messages. 🫶
Common PCP message: a PCP message that does not contain an AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG option to provide integrity protection and message origin authentication for the common PCP messages. 🍓
3. Protocol Details 🎀
3.1. Session Initiation 🦋
At the beginning of a PA session, a PCP client and a PCP server need to exchange a series of PA messages in order to perform an EAP authentication process. Each PA message MUST contain an AUTHENTICATION Opcode and may optionally contain a set of options for various purposes (e.g., transporting authentication messages and session management). The Opcode-specific information in an AUTHENTICATION Opcode consists of two fields: Session ID and Sequence Number. The Session ID field is used to identify the PA session to which the message belongs. The Sequence Number field is used to detect whether reordering or duplication occurred during message delivery. ✨
3.1.1. Authentication Triggered by the Client ✨
okay so bestie, say a PCP client wants to start a PA session on purpose 💅 it sends a PA-Initiation message (that's a PA-Client message with the result code INITIATION) to the PCP server. Section 5.1 updates the PCP request message format with result codes for the PCP authentication mechanism 🎀 In the Opcode-specific information, the Session ID and Sequence Number fields are both set to zero. The PA-Client message MUST also contain a NONCE option (defined in Section 5.3) holding a random nonce 🧚
Then the server decides whether it's down to start a PA session with that client 🦋 If it is, it replies with a PA-Server message carrying an EAP request, and its Result Code is set to AUTHENTICATION_REQUEST. The server MUST assign a unique session identifier so this session is distinctly its own, and it drops that identifier into the Session ID field in the Opcode-specific information 🔥 The Sequence Number is zero again. The PA-Server message MUST contain a NONCE option so the nonce gets sent right back 🫶 The client uses that nonce to check that the message is fresh, not stale or replayed 👀 And every later PCP message in this PA session MUST contain that same session identifier. no cap, it's the thread ID of the whole convo 💜
PCP PCP
client server
|-- PA-Initiation ------------------------------->|
| (Seq=0, rc=INITIATION, Session ID=0) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=1, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |3.1.2. Authentication Triggered by the Server 🌸
Now flip it 🙃 Say a PCP server gets a regular PCP request from a client that needs to be authenticated first. The server rejects that request with an AUTHENTICATION_REQUIRED error code, and it can also send an unsolicited PA-Server message to kick off a PA session 💖 That PA-Server message has its Result Code set to AUTHENTICATION_REQUEST. The PCP server MUST assign a Session ID for the session and send it along inside the PA-Server message. The Sequence Number is set to zero here too ✨
If the client retries the regular request before EAP authentication has succeeded, it just gets the AUTHENTICATION_REQUIRED error code again 😭 In the PA messages that come after this, the Session ID is what helps the session partners tell which messages belong to this session and which ones don't 🧩 When the PCP client gets that first PA-Server message, it can either reply with a PA-Client message or quietly ignore the request, depending on its local policies 🙈 The PA-Client message MAY have a NONCE option with a random nonce appended. If it does, the PCP server MUST forward that nonce back inside a NONCE option in the next PA-Server message 🍓
PCP PCP
client server
|-- Common PCP request -------------------------->|
| |
|<- Common PCP response --------------------------|
| (rc=AUTHENTICATION_REQUIRED) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=0, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |3.1.3. Authentication Using EAP 🦋
Okay, the EAP part is where it gets juicy 🔥 In a PA session, an EAP request rides inside a PA-Server message, and an EAP response rides inside a PA-Client message. EAP expects the layer underneath it to handle reliable delivery, so any reordering or loss of packets during transmission must be detected and addressed 👀 That's why, after the PCP server sends a PA-Server message, it won't send another one in the same PA session until it gets a PA-Client message with the right sequence number from the PCP client. It works the other way round too 💅
Sometimes a PCP client gets a PA message with an EAP request and just can't answer right away 😅 Maybe it's waiting on a human to type something in, or it's waiting for more PA messages so it can put together a full EAP message from fragments. In that case the PCP device MUST reply with a PA-Acknowledgement message (a PA message with a RECEIVED_PAK option) to say "got it, hold on" ✨ This is a big deal because it stops unnecessary retransmissions of the PA message, and it still guarantees reliable delivery when a device has to collect several fragmented PA messages before it can produce an EAP response 🫶 How many EAP messages get swapped between the PCP client and the PCP server depends on which EAP method is used for authentication 🌈
Here's the vibe: a PCP client and a PCP server MUST perform a key-generating EAP method for authentication 🔑 Specifically, a PCP authentication implementation MUST support Extensible Authentication Protocol Tunneled Transport Layer Security (EAP-TTLS) [RFC5281] and SHOULD support the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170] 💜 So once authentication goes through successfully, a Master Session Key (MSK) gets generated 🗝️ If the PCP client and the PCP server want to derive a transport key from that MSK, they have to agree on a Pseudorandom Function (PRF) for the transport key derivation, plus a Message Authentication Code (MAC) algorithm to provide data origin authentication for later PCP messages 🧚 To make that happen, the PCP server appends a set of PRF options and MAC_ALGORITHM options to the initial PA-Server message. Each PRF option carries a PRF the server supports, and each MAC_ALGORITHM option carries a MAC algorithm the server supports 🎀 The server MAY also attach an ID_INDICATOR option (defined in Section 5.11) in that first PA-Server message, to point the client toward the right credentials 🍓 After getting those options, the PCP client MUST pick the PRF and the MAC algorithm it wants to use, and then MUST add the matching PRF and MAC Algorithm options to its next PA-Client message 🙌
Once EAP authentication is done, the PCP server sends a PA-Server message that reports the EAP authentication result and the PCP authorization result 📣 If EAP succeeds, the result code of that PA-Server message is AUTHENTICATION_SUCCEEDED. In this case, before it sends that PA-Server message, the PCP server MUST update the PCP SA with the MSK and transport key, and MUST use the derived transport key to generate a digest for the message 🔐 The digest rides inside a PA_AUTHENTICATION_TAG option for PCP Auth. There's a more detailed explanation of how the authentication data gets generated in Section 6.1 🌸 The PA-Server message MUST also contain a SESSION_LIFETIME option (defined in Section 5.9), which says how long the PA session lasts (in other words, the lifetime of the MSK) ⏳ When the PCP client gets that PA-Server message, it has to generate a PA-Client message in response. If the PCP client also authenticates the PCP server, the result code of that PA-Client message is AUTHENTICATION_SUCCEEDED. The PCP client also updates the PCP SA with the MSK and transport key, and it uses the derived transport key to secure the message ✨ From that point on, every PCP message in the session is secured with the transport key and the MAC algorithm specified in the PCP SA, no exceptions 🔒
The first secure PA-Client message from the client MUST include the set of PRF and MAC_ALGORITHM options it got from the PCP server 💅 The PCP server then checks whether the set of algorithms the client sent matches the set it originally sent, which is how it catches an algorithm downgrade attack 🚨 If the server detects a downgrade attack, it MUST send a PA-Server message with the result code DOWNGRADE_ATTACK_DETECTED and terminate the session. And if a PCP client sends a regular PCP request inside the PA session without an AUTHENTICATION_TAG option, the PCP server rejects it with an AUTHENTICATION_REQUIRED error code 🙅♀️
Last bit, the sad path 😭 If a PCP client or server can't authenticate its session partner, that device sends a PA message with the result code AUTHENTICATION_FAILED. If EAP authentication succeeds but authorization fails, the device making that decision sends a PA message with the result code AUTHORIZATION_FAILED. In both of these cases, the PA session MUST be terminated immediately once that PA message goes out 💀 And it's totally possible for independent PCP clients on the same host to each create their own PA sessions with the PCP server. main character energy, one session per client 👑
3.2. Recovery from Lost PA Session 🌸
okay so picture this: a PCP server resets or loses its PCP SA because of a reboot, a power failure, or literally any other reason 😭. It then sends an unsolicited ANNOUNCE response, as explained in Section 14.1.3 of [RFC6887], to the PCP client. When the client gets an ANNOUNCE response with an anomalous Epoch Time, it figures the server might have lost state. ngl that's a lot of detective work 🕵️♀️. The ANNOUNCE is either bogus (an attack 👀), legit, or never seen by the client. Here are the three cases:
- The PCP client sends an integrity-protected unicast ANNOUNCE request to the PCP server to check whether the server has actually lost state or an attacker just sent that ANNOUNCE response.
- If an integrity-protected success response comes back from the PCP server, then the PCP client decides the PCP server has not lost the PA session, and the unsolicited ANNOUNCE response was sent by an attacker 🚨.
- If the PCP server answers the ANNOUNCE request with an
UNKNOWN_SESSION_IDerror code, then the PCP client MUST initiate full EAP authentication with the PCP server, as explained in Section 3.1.1. After EAP authentication succeeds, the PCP client updates the PCP SA and sends new common PCP requests to recreate any lost mapping state 🔁.
- In a scenario where the PCP server has lost the PCP SA but didn't tell the PCP client, if the PCP client sends an integrity-protected PCP request, then the PCP server rejects it with an
UNKNOWN_SESSION_IDerror code. The PCP client then starts full EAP authentication with the PCP server, as explained in Section 3.1.1, and updates the PCP SA once authentication succeeds ✨.
If the PCP client resets or loses the PCP SA because of a reboot, a power failure, or any other reason and then sends a common PCP request, the PCP server rejects it with an AUTHENTICATION_REQUIRED error code. The PCP client MUST authenticate with the PCP server and, after EAP authentication succeeds, retry the common PCP request with an AUTHENTICATION_TAG option. The PCP server MUST update the PCP SA after successful EAP authentication 💖.
3.3. Session Termination 🦋
A PA session can be explicitly terminated by either session partner, so either one can pull the plug 🔌. A PCP server may explicitly ask for termination by sending an unsolicited termination-indicating PA response (a PA response with a result code of SESSION_TERMINATED). When the PCP client receives a termination-indicating message, it MUST respond with a termination-indicating PA message and MUST then remove the associated PCP SA. To cover packet loss, the PCP server MAY transmit the termination-indicating PA response up to ten times (with an appropriate Epoch Time value in each one to reflect the time passing between transmissions), provided that (1) the interval between the first two notifications is at least 250 ms and (2) each interval between subsequent notifications at least doubles 🌈.
A PCP client may also explicitly request termination by sending a termination-indicating PA request (a PA request with a result code of SESSION_TERMINATED). After receiving a termination-indicating message from the PCP client, a PCP server MUST respond with a termination-indicating PA message and remove the PCP SA immediately 🏃♀️. When the PCP client receives that termination-indicating PA response, it MUST remove the associated PCP SA immediately too.
3.4. Session Re-authentication 💅
A session partner may choose to perform EAP re-authentication if it wants to update the PCP SA without starting a brand-new PA session. For example, a re-authentication could be triggered for these reasons:
- The session lifetime needs to be extended ⏳.
- The sequence number is about to hit its maximum value. Specifically, when the sequence number reaches
2**32 - 2**16, the session partner MUST trigger re-authentication.
When the PCP server wants to start a re-authentication, it sends the PCP client a PA-Server message. The result code of that message is set to RE-AUTHENTICATION, which tells everyone the message is for a re-authentication process. If the PCP client wants to start the re-authentication, it sends a PA-Client message to the PCP server with the result code of that PA-Client message set to RE-AUTHENTICATION. After that, the session partners swap PA messages to carry the EAP messages for the re-authentication. During re-authentication, the session partners protect the integrity of PA messages with the key and MAC algorithm specified in the current PCP SA, and the sequence numbers on those messages keep increasing as specified in Section 6.4 🔢. The result code for a PA-Server message carrying an EAP request is set to AUTHENTICATION_REQUIRED, and a PA-Client message carrying an EAP response is set to AUTHENTICATION_REPLY.
If EAP re-authentication succeeds, the result code of the last PA-Server message is AUTHENTICATION_SUCCEEDED 🎉. In this case, before sending out the PA-Server message, the PCP server MUST update the SA and use the new key to generate a digest for that PA-Server message and for subsequent PCP messages. On top of that, the PA-Server message MUST be appended with a SESSION_LIFETIME option that indicates the new lifetime of the PA session. PA and PCP message sequence numbers must also be reset to zero 🧸.
If EAP authentication fails, the result code of the last PA-Server message is AUTHENTICATION_FAILED. If EAP authentication succeeds but authorization fails, the result code of the last PA-Server message is AUTHORIZATION_FAILED. In those last two cases, the PA session MUST be terminated immediately after the last PA message exchange 💀. If, for some unknown reason, re-authentication isn't performed and the session lifetime has expired, then the PA session MUST be terminated immediately too.
During re-authentication, the session partners can also exchange common PCP messages in parallel 🧑🤝🧑. The common PCP messages MUST be protected with the current SA until the new SA has been generated. The sequence of EAP messages exchanged for re-authentication does not change, no matter which PCP device triggers the re-authentication. If the PCP server gets a re-authentication request from the PCP client after the PCP server itself has already sent a re-authentication request, then it should discard its own request and respond to the PCP client's re-authentication request 🙈.
4. PA Security Association 🔐
At the beginning of a new PA session, each PCP device must create and initialize state information for a new PA Security Association (PCP SA) to maintain its state information for the duration of the PA session. The parameters of a PCP SA are as follows:
- IP address and UDP port number of the PCP client.
- IP address and UDP port number of the PCP server.
- Session identifier.
- Sequence number for the next outgoing PA message.
- Sequence number for the next incoming PA message.
- Sequence number for the next outgoing common PCP message.
- Sequence number for the next incoming common PCP message.
- Last outgoing message payload.
- Retransmission interval.
- The Master Session Key (MSK) generated by the EAP method.
- The MAC algorithm that the transport key should use to generate digests for PCP messages.
- The pseudorandom function negotiated in the initial PA-Server and PA-Client message exchange for the transport key derivation.
- The transport key derived from the MSK to provide integrity protection and data origin authentication for the messages in the PA session. The lifetime of the transport key SHOULD be identical to the lifetime of the session 🗝️.
- The nonce selected by the PCP client at the initiation of the session.
- The key ID associated with the transport key.
Here's the specific way the transport key gets computed 🧮:
transport key = prf(MSK, "IETF PCP" || Session ID || Nonce ||
key ID), where:Here's what each piece means:
prfis the pseudorandom function assigned in the PRF option (Section 5.7).MSKis the master session key generated by the EAP method."IETF PCP"is the ASCII code representation of the non-null-terminated string (excluding the double quotes around it).'||'is the concatenation operator.- Session ID is the ID of the session from which the MSK is derived.
- Nonce is the nonce selected by the client and transported in the initial PA-Client message.
- Key ID is the ID assigned for the transport key.
5. Packet Format 📦
5.1. Packet Format of PCP Auth Messages 💖
okay so bestie, the PA-Server message is literally the same shape as the response message from Section 7.2 of [RFC6887] 🦋 no reinventing the wheel here. And if that PA-Server message is carrying an EAP request, its result code MUST be set to AUTHENTICATION_REQUEST ✨
This doc also updates the Reserved field in the Request header from Section 7.1 of [RFC6887] so it can carry Opcode-specific data 🎀 here's how that header looks now:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |Opcode-specific|
| | | | | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Request Packet Format
The PA-Client messages (see Figure 2 below) use that same Request header from Figure 1 🌸 the Opcode-specific data is how they carry result codes, like INITIATION or AUTHENTICATION_FAILED. Everything else in Figure 2 is explained in Section 7.1 of [RFC6887] 💅 and if a PA-Client message is carrying an EAP response, its result code MUST be set to AUTHENTICATION_REPLY 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: PA-Client Message Format
one more thing 👀 the Requested Lifetime field of a PA-Client message and the Lifetime field of a PA-Server message are BOTH set to zero when sent, and then ignored when received. 🙈
5.2. Opcode-Specific Information of AUTHENTICATION Opcode 🧚
here's the layout for the Opcode-specific information in the AUTHENTICATION Opcode 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Session ID: a 32-bit PA session identifier 🌈
- Sequence Number: a 32-bit sequence number. This one needs to go up by one on every new (non-retransmission) outgoing PA message so messages can be ordered ✨ that's the ordering guarantee, babe.
5.3. NONCE Option 🦋
okay this one is lowkey clever. The PCP server picks the session identifier of a PA session, which means the PCP client has no idea what ID is coming back when it sends a PA-Initiation message 🙈 so, to stop some attacker from butting in with spoofed PA-Server messages and wrecking the authentication, the client makes up a random number as a nonce and tucks it into the PA-Initiation message. The PCP server then attaches that same nonce to the first PA-Server message. 🔥
And if a PA-Server message doesn't have the correct nonce? It MUST be silently discarded. Gone. No drama. 💀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Option Code: 4.
- Reserved: 8 bits. It MUST be set to zero on transmission and MUST be ignored on reception.
- Option-Length: 4 octets.
- Nonce: a random 32-bit number carried in a PA-Initiation message and in the matching reply from the PCP server 🎀
5.4. AUTHENTICATION_TAG Option 🍓
this is the one for common PCP messages, and it's giving full security-guard energy 💅 here's the shape:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so common PCP messages don't have an authentication Opcode, which means this tag has to carry the Session ID and Sequence Number itself 🌸
- Option Code: 5.
- Reserved: 8 bits. It MUST be set to zero on transmission and MUST be ignored on reception.
- Option-Length: the length of the AUTHENTICATION_TAG option for the common PCP message, in octets. That includes the 12-octet fixed-length header plus the variable-length authentication data.
- Session ID: a 32-bit field that identifies the session the message belongs to, and also identifies the secret key used to make the message digest appended to the PCP message 🔑
- Sequence Number: a 32-bit sequence number. In this option, it needs to go up by one on every new (non-retransmission) outgoing common PCP message so those messages get an ordering guarantee ✨
- Key ID: the ID tied to the transport key used to generate the authentication data. If the MSK is used directly to secure the message, this field is filled with zeros 🧚
- Authentication Data: a variable-length field carrying the Message Authentication Code for the common PCP message. How the digest gets generated depends on the algorithms in each PCP SA 💖 this field MUST end on a 32-bit boundary, padded with zeros when needed.
5.5. PA_AUTHENTICATION_TAG Option 🌈
this option does message authentication for PA messages 🫶 compared to the common-message tag, the Session ID and Sequence Number fields are gone, since that info already lives in the Opcode-specific information of the AUTHENTICATION Opcode. Less repeating, more slay 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Option Code: 6.
- Reserved: 8 bits. It MUST be set to zero on transmission and MUST be ignored on reception.
- Option-Length: the length of the PA_AUTHENTICATION option for the PCP Auth message, in octets. That covers the 4-octet fixed-length header plus the variable-length authentication data.
- Key ID: the ID tied to the transport key used to generate the authentication data. If the MSK is used directly to secure the message, this field is filled with zeros 🎀
- Authentication Data: a variable-length field carrying the Message Authentication Code for the PCP Auth message. The digest generation depends on the algorithms in each PCP SA 🦋 this field MUST end on a 32-bit boundary, padded with null characters when needed.
5.6. EAP_PAYLOAD Option 🎀
Okay so this one is the courier 💌 It carries an actual EAP message inside the PCP packet, and the layout looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EAP Message |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 7. Iconic number, no notes 💅
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. These two are non-negotiable, bestie 🫶
Option-Length: Variable. The length depends on how big the message is 📏
EAP Message: This is the EAP message being transferred. Heads up: this field MUST end on a 32-bit boundary, padded with zeros when necessary 🧚
5.7. PRF Option 🌈
This is the PRF option, and it's basically how the sender says which pseudorandom function they can use to make an MSK. Here's the packet shape:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 8. 🔥
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. Same rule as always, periodt 💖
Option-Length: 4 octets.
PRF: The pseudorandom function that the sender supports to generate an MSK. This field holds a value that points to Internet Key Exchange Protocol version 2 (IKEv2) Transform Type 2 [RFC7296] [RFC4868]. Lowkey the key detail: a PCP implementation MUST support PRF_HMAC_SHA2_256 (transform ID = 5) ✨
5.8. MAC_ALGORITHM Option 🦋
This one tells everyone which MAC algorithm the sender can use to make authentication data. Shape first:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 9. 💅
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. 🫶
Option-Length: 4 octets.
MAC Algorithm ID: Indicates the MAC algorithm that the sender supports to generate authentication data. The MAC Algorithm ID field contains a value indicating IKEv2 Transform Type 3 [RFC7296] [RFC4868]. A PCP implementation MUST support AUTH_HMAC_SHA2_256_128 (transform ID = 12). That's the must-have one, no cap 🔥
5.9. SESSION_LIFETIME Option ⭐
This option is all about how long a PA session is allowed to live. Here's the shape:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 10. 🌸
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. 💜
Option-Length: 4 octets.
Session Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. This is the lifetime of the PA session, and the authorization result is what decides it 👑
5.10. RECEIVED_PAK Option 📬
This option is used in a PA-Acknowledgement message to say that a PA message with the included sequence number got received. It's the "got it!" reply 🥰
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 11. ✨
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. 🎀
Option-Length: 4 octets.
Received Sequence Number: The sequence number of the last received PA message. 🦋
5.11. ID_INDICATOR Option 🪪
The ID_INDICATOR option is how the PCP client figures out which credentials to hand over to the PCP server. Ngl, it's the "which ID card do I show" option 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ID Indicator |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Code: 12. 👑
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception. 💖
Option-Length: Variable. 📏
ID Indicator: The identity of the authority that issued the EAP credentials to be used to authenticate the client. The field MUST NOT be null terminated, and its length is indicated by the Option-Length field. In particular, when a client receives an ID_INDICATOR option, it MUST NOT rely on the presence of a null character in the wire format data to identify the end of the ID Indicator field. Basically: don't go hunting for a null byte to find the end, use the length 🙈
The field MUST end on a 32-bit boundary, padded with zeros when necessary. The ID Indicator field is a UTF-8 encoded [RFC3629] Unicode string conforming to the UsernameCaseMapped profile of the PRECIS IdentifierClass [RFC7613]. The PCP client validates that the ID Indicator field conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass. The PCP client enforces the rules specified in Section 3.2.2 of [RFC7613] to map the ID Indicator field. Then the PCP client compares the resulting string with the ID indicators stored locally on the PCP client to pick the credentials for authentication. The two indicator strings are to be considered equivalent by the client if and only if they are an exact octet-for-octet match. Exact match or nothing, bestie 🫶
6. Processing Rules 🔥
6.1. Authentication Data Generation 🔐
After a successful EAP authentication process, every subsequent PCP message within the PA session MUST carry an authentication tag that contains the digest of the PCP message for data origin authentication and integrity protection. Every. Single. One 💅
- Before generating a digest for a PA message, a device needs to first locate the PCP SA according to the session identifier and then get the transport key. Then, the device appends a
PA_AUTHENTICATION_TAGoption for PCP Auth at the end of the PCP Auth message. The length of the Authentication Data field is decided by the MAC algorithm adopted in the session. The device then fills the Key ID field with the key ID of the transport key and sets the Authentication Data field to zero. After this, the device generates a digest for the entire PCP message (including the PCP header andPA_AUTHENTICATION_TAGoption) using the transport key and the associated MAC algorithm, and inserts the generated digest into the Authentication Data field. 🧚 - Similar to generating a digest for a PA message, before generating a digest for a common PCP message, a device needs to first locate the PCP SA according to the session identifier and then get the transport key. Then, the device appends the
AUTHENTICATION_TAGoption at the end of the common PCP message. The length of the Authentication Data field is decided by the MAC algorithm adopted in the session. The device then uses the corresponding values derived from the SA to fill the Session ID field, the Sequence Number field, and the Key ID field, and sets the Authentication Data field to zero. After this, the device generates a digest for the entire PCP message (including the PCP header andAUTHENTICATION_TAGoption) using the transport key and the associated MAC algorithm, and inserts the generated digest into the Authentication Data field. 🦋
6.2. Authentication Data Validation 🕵️♀️
When a device receives a common PCP message with an AUTHENTICATION_TAG option for common PCP messages, the device needs to use the Session ID transported in the option to locate the proper SA and then find the associated transport key (using the key ID in the option) and the MAC algorithm. If no proper SA or transport key is found or the sequence number is invalid (see Section 6.5), the PCP device stops processing the PCP message and silently discards the message. After storing the value of the Authentication field of the AUTHENTICATION_TAG option, the device fills the Authentication field with zeros. Then, the device generates a digest for the message (including the PCP header and AUTHENTICATION_TAG option) with the transport key and the MAC algorithm. If the value of the newly generated digest is identical to the stored one, the device can ensure that the message has not been tampered with, and the validation succeeds. Otherwise, the PCP device stops processing the PCP message and silently discards the message. Tamper check, passed or dropped, no drama 💀
Similarly, when a device receives a PA message with a PA_AUTHENTICATION_TAG option for PCP authentication, the device needs to use the Session ID transported in the Opcode to locate the proper SA and then find the associated transport key (using the key ID in the option) and the MAC algorithm. If no proper SA or transport key is found or the sequence number is invalid (see Section 6.4), the PCP device stops processing the PCP message and silently discards the message. After storing the value of the Authentication field of the PA_AUTHENTICATION_TAG option, the device fills the Authentication field with zeros. Then, the device generates a digest for the message (including the PCP header and PA_AUTHENTICATION_TAG option) with the transport key and the MAC algorithm. If the value of the newly generated digest is identical to the stored one, the device can ensure that the message has not been tampered with, and the validation succeeds. Otherwise, the PCP device stops processing the PCP message and silently discards the message. Same energy for PA messages, iykyk 🌈
6.3. Retransmission Policies for PA Messages 🔁
okay so EAP leans on the underlying protocols to be reliable, which means after a PA message is sent, a PCP client/server MUST NOT send out any subsequent messages until it has received a PA message with a proper sequence number from its peer 🫶 if that message never shows up, the PCP device resends the last message following its retransmission policies. this spec uses the retransmission policies from Section 8.1.1 of the base PCP spec [RFC6887] 💅 in base PCP, only clients apply these policies, but here the PCP servers apply them too, so everyone's in on it ✨ if the "maximum retransmission" duration (in seconds) runs out and no expected response comes back, the device terminates the session and discards the current SA. 💀
as we talked about in Section 3.1.3, the device that receives a PA message MUST send a PA-Acknowledgement message back to the sender when it can't send a PA response right away 🦋 this avoids unnecessary retransmissions, because the PA-Acknowledgement just says "got it!" and once the sender gets that, it stops retransmitting 🌸
the last PA messages in session initiation, session re-authentication, and session termination don't have to follow these policies, since the devices sending them aren't expecting any more PA messages after that 🧚
when a device gets a retransmitted last incoming PA message from its session partner, it MUST try to answer by sending the last outgoing PA message again 🔥 but if the duplicate has the same sequence number and isn't bitwise identical to the original, the device MUST discard it 🙈 to pull this off, the device might need to keep track of the last incoming message and the outgoing messages tied to it 💜 and if no outgoing PA message has been made yet for that duplicate, the device needs to send a PA-Acknowledgement message ✨ replying to duplicate PA messages MUST be rate limited so it stays robust against denial-of-service (DoS) attacks 🛡️ the details of rate limiting are outside the scope of this spec, so that's a separate convo 🎀
6.4. Sequence Numbers for PCP Auth Messages 🔢
PCP uses UDP for its signaling messages, and UDP is unreliable: no ordered delivery, no protection from packet loss 😭 so to make sure EAP messages get exchanged reliably, every PCP message exchanged during EAP authentication must carry a monotonically increasing sequence number 💖 during a PA session, a PCP device keeps two sequence numbers for PA messages, one for incoming and one for outgoing 👑 when making an outgoing PA message, the device adds the matching outgoing sequence number and then bumps the sequence number stored in the SA by 1 ✨ when a PA message comes in from its session partner, the device won't accept it if the sequence number doesn't match the incoming sequence number it's tracking 🙅♀️ once the message checks out as valid, the device increments the incoming sequence number in the SA by 1 🌈
the above rules don't apply to PA-Acknowledgement messages (aka PA messages containing a RECEIVED_PAK option) 🦋 these don't carry any EAP message and only say that a PA message was received, so they don't need reliable transmission 🫠 for example, after sending a PA-Acknowledgement, a device generates an EAP response, and it doesn't have to check whether its partner got the PA-Acknowledgement 💅 so when receiving or sending a PA-Acknowledgement, the device MUST NOT increase the matching sequence number stored in the SA 🙈 otherwise, losing a PA-Acknowledgement would cause a sequence number mismatch, and nobody wants that drama 💀
there's one more exception, and it's the retransmission scenario 🔁 as covered in Section 6.3, when a PCP device doesn't get any response from its session partner, it has to retransmit the last outgoing PA message, following the retransmission procedure in Section 8.1.1 of [RFC6887] 🧚 the original message and the duplicate messages MUST be bitwise identical 🫶 and when the device gets a duplicate PA message like that from its session partner, it MUST send the last outgoing PA message again 🔥 in these cases, the sequence numbers the device is maintaining aren't affected by the retransmission, so the vibes stay stable ✨
6.5. Sequence Numbers for Common PCP Messages 💌
when common PCP messages are transported within a PA session, a PCP device needs one sequence number for outgoing common PCP messages and another for incoming ones 🍓 when making a new outgoing PCP message, the device updates the Sequence Number field in the AUTHENTICATION_TAG option with the outgoing sequence number kept in the SA, then bumps that outgoing number by 1 🎀
when a PCP message comes in from its session partner, the device won't accept it if its sequence number is smaller than the incoming sequence number the device is tracking 🛡️ this is how the PCP device protects itself from replay attacks 💜 once the message is confirmed valid, the device updates the incoming sequence number in the PCP SA to match the incoming message's sequence number 🌸
the sequence number in an incoming message might not exactly match the incoming sequence number tracked locally, and that's totally expected 🙈 as discussed in the base PCP spec [RFC6887], if a PCP client isn't interested in a PCP transaction anymore and hasn't yet gotten a PCP response from the server, it stops retransmitting the PCP request ✨ after that, the client might make new PCP requests for other purposes using the current SA 💅 in that case, the sequence number in the new request is larger than the one in the old request, and so it's also larger than the incoming sequence number maintained in the PCP server 👑
also, as covered in the base PCP spec [RFC6887], a PCP client needs to pick a nonce in each MAP or PEER request, and the server sends that nonce back in the response 🧚 a client could use the same nonce in multiple MAP or PEER requests, though, and that opens up a potential risk of replay attacks 😭 this attack gets addressed by using the sequence number in the PCP response 🫶
6.6. MTU Considerations 📏
EAP methods are responsible for MTU handling, so PCP doesn't need any special facilities to deal with MTU issues 💅 specifically, EAP lower layers tell EAP methods and Authentication, Authorization, and Accounting (AAA) servers what the MTU of the lower layer is ✨ EAP methods like EAP-TLS [RFC5216], TEAP [RFC7170], and others that are likely to go over reasonable MTUs support fragmentation and reassembly 🔥 others, like EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume they'll never send packets bigger than the MTU and use small EAP packets instead 🌈
if an EAP message is too long for a single PA message, it gets split into multiple sections and sent in different PA messages 🍓 the receiver might not know what to do next until it has all the sections and has rebuilt the full EAP message 🙈 so, to guarantee reliable message transmission, after receiving a PA message, the receiver replies with a PA-Acknowledgement message to tell the sender to send the next PA message 🦋
7. IANA Considerations 🧾
the following PCP Opcode has been allocated from the Standards Action range of the "PCP Opcodes" registry (maintained at <http://www.iana.org/assignments/pcp-parameters>):
3AUTHENTICATION
the following PCP result codes have been allocated from the Standards Action range of the "PCP Result Codes" registry (also maintained at <http://www.iana.org/assignments/pcp-parameters>) 🎀
14INITIATION: the client includes this PCP result code in its request to the server for authentication 🌸15AUTHENTICATION_REQUIRED: this error response goes to the client if EAP authentication is required 🔐16AUTHENTICATION_FAILED: this error response goes to the client if EAP authentication failed 💀17AUTHENTICATION_SUCCEEDED: this success response goes to the client if EAP authentication succeeded ✨18AUTHORIZATION_FAILED: this error response goes to the client if EAP authentication succeeded but authorization failed 😭19SESSION_TERMINATED: this PCP result code tells the partner that the PA session must be terminated 🥀20UNKNOWN_SESSION_ID: this error response comes from the PCP server if there's no known PA session tied to the Session ID sent in the PA request or common PCP request from the PCP client 🙈21DOWNGRADE_ATTACK_DETECTED: this PCP result code tells the client that the server detected a downgrade attack 🚨22AUTHENTICATION_REQUEST: the server tells the client that the PA message contains an EAP request 🧚23AUTHENTICATION_REPLY: the client tells the server that the PA message contains an EAP response 💌
the following PCP options have been allocated from the Standards Action range (the registry for PCP options is maintained at <http://www.iana.org/assignments/pcp-parameters>) 💅
7.1. NONCE 🎲
Name: NONCE.
Value: 4.
Purpose: See Section 5.3.
Valid for Opcodes: AUTHENTICATION.
Length: 4 octets.
May appear in: Request and response.
Maximum occurrences: 1.7.2. AUTHENTICATION_TAG 🏷️
Name: AUTHENTICATION_TAG.
Value: 5.
Purpose: See Section 5.4.
Valid for Opcodes: MAP, PEER, ANNOUNCE.
Length: variable.
May appear in: Request and response.
Maximum occurrences: 1.7.3. PA_AUTHENTICATION_TAG 🔖
Name: PA_AUTHENTICATION_TAG.
Value: 6.
Purpose: See Section 5.5.
Valid for Opcodes: AUTHENTICATION.
Length: variable.
May appear in: Request and response.
Maximum occurrences: 1.7.4. EAP_PAYLOAD 📦
Name: EAP_PAYLOAD.
Value: 7.
Purpose: See Section 5.6.
Valid for Opcodes: AUTHENTICATION.
Length: variable.
May appear in: Request and response.
Maximum occurrences: 1.7.5. PRF 🧪
Name: PRF.
Value: 8.
Purpose: See Section 5.7.
Valid for Opcodes: AUTHENTICATION.
Length: 4 octets.
May appear in: Request and response.
Maximum occurrences: as many as fit within maximum PCP message size.7.6. MAC_ALGORITHM 🔏
Name: MAC_ALGORITHM.
Value: 9.
Purpose: See Section 5.8.
Valid for Opcodes: AUTHENTICATION.
Length: 4 octets.
May appear in: Request and response.
Maximum occurrences: as many as fit within maximum PCP message size.7.7. SESSION_LIFETIME ⏳
Name: SESSION_LIFETIME.
Value: 10.
Purpose: See Section 5.9.
Valid for Opcodes: AUTHENTICATION
Length: 4 octets.
May appear in: Response.
Maximum occurrences: 1.7.8. RECEIVED_PAK 💖
okay so RECEIVED_PAK is the one with the little receipt energy 🧾 its whole job is explained in Section 5.10, but here's the entry itself 🎀
Name: RECEIVED_PAK.
Value: 11.
Purpose: See Section 5.10.
Valid for Opcodes: AUTHENTICATION.
Length: 4 octets.
May appear in: Request and response.
Maximum occurrences: 1.7.9. ID_INDICATOR 🦋
next up is ID_INDICATOR, which is giving very specific main character energy 👑 the details are below, and the purpose is in Section 5.11 💅
Name: ID_INDICATOR.
Value: 12.
Purpose: See Section 5.11.
Valid for Opcodes: AUTHENTICATION.
Length: variable.
May appear in: Response.
Maximum occurrences: 1.8. Security Considerations 🔥😭
bestie this part is SERIOUS, so read it slowly 🫶 once an EAP authentication process succeeds between two PCP devices, an MSK gets exported 🔑 that MSK is then used to derive the transport keys that generate the MAC digests for every later PCP message exchange 💜 BUT before a transport key exists, the PA messages inside a PA session have very little cryptographic protection 💀 so if the two session partners don't already have a secured channel between them, those messages are open to man-in-the-middle attacks and DoS attacks 🙈 for example, the very first PA-Server and PA-Client exchange is vulnerable to spoofing, because those messages aren't authenticated or integrity protected. it's giving "anyone can pretend to be you" 😬
it gets worse, ngl. because the PRF and MAC algorithms get transported at this stage, an attacker might try to strip out the PRF and MAC options that contain strong algorithms from the initial PA-Server message, and force the client to pick the weakest ones 💀 so the server needs to guarantee that every PRF and MAC algorithm it supports is strong enough 🛡️ no weak options allowed, periodt ✨
now for the defence side 🧚 to prevent the very basic DoS attacks, a PCP device SHOULD generate as little state information as possible during the initial PA-Server and PA-Client message exchanges 🌸 the choice of EAP method is ALSO super important. the selected EAP method must (1) be resilient to attacks that are possible in an insecure network environment, (2) provide user-identity confidentiality and protection against dictionary attacks, and (3) support session-key establishment 🎀 that's a lot of boxes to tick, but it's non-negotiable bestie 💅
last bit, and it's kind of iconic. when a PCP proxy [RFC7648] sits between a PCP server and PCP clients, the proxy may perform authentication with the PCP server before it processes requests from the clients 🦋 also, re-authentication between the PCP proxy and the PCP server will not interrupt the service the proxy gives the clients 🌈 why? because the proxy is still allowed to send common PCP messages to the PCP server during that period. the flow stays unbothered 💖
9. References 📚
9.1. Normative References
Here's the normative list, verbatim so nothing gets lost in translation 🎀
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<http://www.rfc-editor.org/info/rfc5281>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<http://www.rfc-editor.org/info/rfc7170>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.
[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
RFC 7648, DOI 10.17487/RFC7648, September 2015,
<http://www.rfc-editor.org/info/rfc7648>.9.2. Informative References
and here's the informative list, the "good to know" crew 🌸
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, DOI 10.17487/RFC5433, February 2009,
<http://www.rfc-editor.org/info/rfc5433>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<http://www.rfc-editor.org/info/rfc5448>.Acknowledgements 🫶💜
huge thank-yous to these legends for their valuable comments 🎀✨ Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen, Stephen Farrell, and Terry Manderson 👑 you all made this spec better 🌈
Authors' Addresses 💅
and finally, who wrote this thing 🧚 here are the contact details, exactly as published:
Margaret Cullen
Painless Security
356 Abbott Street
North Andover, MA 01845
United States
Phone: +1 781 405 7464
Email: margaret@painless-security.com
URI: http://www.painless-security.com
Sam Hartman
Painless Security
356 Abbott Street
North Andover, MA 01845
United States
Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang
Beijing, China
China
Email: zhang_dacheng@hotmail.com
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com📦 where this page comes from
- ietf: rfc7652 2015-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms