RFC 7652
Port Control Protocol (PCP) Authentication Mechanism
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. o 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_TAG option 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 and PA_AUTHENTICATION_TAG option) using the transport key and the associated MAC algorithm, and inserts the generated digest into the Authentication Data field. o 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_TAG option 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 and
AUTHENTICATION_TAG option) 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.
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.
6.3. Retransmission Policies for PA Messages
Because EAP relies on the underlying protocols to provide reliable transmission, after sending a PA message, a PCP client/server MUST NOT send out any subsequent messages until it has received a PA message with a proper sequence number from the peer. If no such message is received, the PCP device will resend the last message according to retransmission policies. This specification uses the retransmission policies specified in Section 8.1.1 of the base PCP specification [RFC6887]. In base PCP, such retransmission policies are only applied by PCP clients. However, in this specification, such retransmission policies are also applied by the PCP servers. If the "maximum retransmission" duration (in seconds) has elapsed and no expected response is received, the device will terminate the session and discard the current SA. As discussed in Section 3.1.3, in order to avoid unnecessary retransmission, the device receiving a PA message MUST send a PA-Acknowledgement message to the sender of the PA message when it cannot send a PA response immediately. The PA-Acknowledgement message is used to indicate the receipt of the PA message. When the sender receives the PA-Acknowledgement message, it will stop the retransmission. Note that the last PA messages transported within the phases of session initiation, session re-authentication, and session termination do not have to follow the above policies, since the devices sending out those messages do not expect any further PA messages. When a device receives a retransmitted last incoming PA message from its session partner, it MUST try to answer it by sending the last outgoing PA message again. However, if the duplicate message has the same sequence number but is not bitwise identical to the original message, then the device MUST discard it. In order to perform this function, the device may need to maintain the last incoming message and the associated outgoing messages. In this case, if no outgoing PA message has been generated for the received duplicate PA message yet, the device needs to send a PA-Acknowledgement message. The rate of replying to duplicate PA messages MUST be limited to provide robustness against denial-of-service (DoS) attacks. The details of rate limiting are outside the scope of this specification.
6.4. Sequence Numbers for PCP Auth Messages
PCP uses UDP to transport signaling messages. As an unreliable transport protocol, UDP does not guarantee ordered packet delivery and does not provide any protection from packet loss. In order to ensure that the EAP messages are exchanged in a reliable way, every PCP message exchanged during EAP authentication must carry a monotonically increasing sequence number. During a PA session, a PCP device needs to maintain two sequence numbers for PA messages: one for incoming PA messages and one for outgoing PA messages. When generating an outgoing PA message, the device adds the associated outgoing sequence number to the message and increments the sequence number maintained in the SA by 1. When receiving a PA message from its session partner, the device will not accept it if the sequence number carried in the message does not match the incoming sequence number maintained in the device. After confirming that the received message is valid, the device increments the incoming sequence number maintained in the SA by 1. The above rules are not applicable to PA-Acknowledgement messages (i.e., PA messages containing a RECEIVED_PAK option). A PA-Acknowledgement message does not transport any EAP message and only indicates that a PA message is received. Therefore, reliable transmission of PA-Acknowledgement messages is not required. For instance, after sending out a PA-Acknowledgement message, a device generates an EAP response. In this case, the device does not have to confirm whether the PA-Acknowledgement message has been received by its session partner or not. Therefore, when receiving or sending out a PA-Acknowledgement message, the device MUST NOT increase the corresponding sequence number stored in the SA. Otherwise, loss of a PA-Acknowledgement message will cause a mismatch in sequence numbers. Another exception is the message retransmission scenario. As discussed in Section 6.3, when a PCP device does not receive any response from its session partner, it needs to retransmit the last outgoing PA message, following the retransmission procedure specified in Section 8.1.1 of [RFC6887]. The original message and duplicate messages MUST be bitwise identical. When the device receives such a duplicate PA message from its session partner, it MUST send the last outgoing PA message again. In such cases, the maintained incoming and outgoing sequence numbers will not be affected by the message retransmission.
6.5. Sequence Numbers for Common PCP Messages
When transporting common PCP messages within a PA session, a PCP device needs to maintain a sequence number for outgoing common PCP messages and a sequence number for incoming common PCP messages. When generating a new outgoing PCP message, the PCP device updates the Sequence Number field in the AUTHENTICATION_TAG option with the outgoing sequence number maintained in the SA and increments the outgoing sequence number by 1. When receiving a PCP message from its session partner, the PCP device will not accept it if the sequence number carried in the message is smaller than the incoming sequence number maintained in the device. This approach can protect the PCP device from replay attacks. After confirming that the received message is valid, the PCP device will update the incoming sequence number maintained in the PCP SA with the sequence number of the incoming message. Note that the sequence number in the incoming message may not exactly match the incoming sequence number maintained locally. As discussed in the base PCP specification [RFC6887], if a PCP client is no longer interested in the PCP transaction and has not yet received a PCP response from the server, then it will stop retransmitting the PCP request. After that, the PCP client might generate new PCP requests for other purposes, using the current SA. In this case, the sequence number in the new request will be larger than the sequence number in the old request and so will be larger than the incoming sequence number maintained in the PCP server. Note that, as discussed in the base PCP specification [RFC6887], a PCP client needs to select a nonce in each MAP or PEER request, and the nonce is sent back in the response. However, it is possible for a client to use the same nonce in multiple MAP or PEER requests, and this may cause a potential risk of replay attacks. This attack is addressed by using the sequence number in the PCP response.6.6. MTU Considerations
EAP methods are responsible for MTU handling, so no special facilities are required in PCP to deal with MTU issues. Specifically, EAP lower layers indicate to EAP methods and Authentication, Authorization, and Accounting (AAA) servers the MTU of the lower layer. EAP methods such as EAP-TLS [RFC5216], TEAP [RFC7170], and others that are likely to exceed reasonable MTUs provide support for fragmentation and reassembly. Others, such as EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume that they will never send packets larger than the MTU and use small EAP packets.
If an EAP message is too long to be transported within a single PA message, it will be divided into multiple sections and sent within different PA messages. Note that the receiver may not be able to know what to do in the next step until it has received all the sections and reconstructed the complete EAP message. In this case, in order to guarantee reliable message transmission, after receiving a PA message, the receiver replies with a PA-Acknowledgement message to notify 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 (which is maintained in <http://www.iana.org/assignments/pcp-parameters>): 3 AUTHENTICATION. The following PCP result codes have been allocated from the Standards Action range of the "PCP Result Codes" registry (which is maintained in <http://www.iana.org/assignments/pcp-parameters>): 14 INITIATION: The client includes this PCP result code in its request to the server for authentication. 15 AUTHENTICATION_REQUIRED: This error response is sent to the client if EAP authentication is required. 16 AUTHENTICATION_FAILED: This error response is sent to the client if EAP authentication failed. 17 AUTHENTICATION_SUCCEEDED: This success response is sent to the client if EAP authentication succeeded. 18 AUTHORIZATION_FAILED: This error response is sent to the client if EAP authentication succeeded but authorization failed. 19 SESSION_TERMINATED: This PCP result code indicates to the partner that the PA session must be terminated. 20 UNKNOWN_SESSION_ID: This error response is sent from the PCP server if there is no known PA session associated with the Session ID sent in the PA request or common PCP request from the PCP client. 21 DOWNGRADE_ATTACK_DETECTED: This PCP result code indicates to the client that the server detected a downgrade attack.
22 AUTHENTICATION_REQUEST: The server indicates to the client that
the PA message contains an EAP request.
23 AUTHENTICATION_REPLY: The client indicates to 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 in
<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
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
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
As described in this specification, after a successful EAP authentication process is performed between two PCP devices, an MSK will be exported. The MSK will be used to derive the transport keys to generate MAC digests for subsequent PCP message exchanges. However, before a transport key has been generated, the PA messages exchanged within a PA session have little cryptographic protection, and if there is no already-established security channel between two session partners, these messages are subject to man-in-the-middle attacks and DoS attacks. For instance, the initial PA-Server and PA-Client message exchange is vulnerable to spoofing attacks, as these messages are not authenticated and integrity protected. In addition, because the PRF and MAC algorithms are transported at this stage, an attacker may try to remove the PRF and MAC options containing strong algorithms from the initial PA-Server message and force the client to choose the weakest algorithms. Therefore, the server needs to guarantee that all the PRF and MAC algorithms for which it provides support are strong enough. In order to prevent very basic DoS attacks, a PCP device SHOULD generate state information as little as possible in the initial PA-Server and PA-Client message exchanges. The choice of EAP method is also very 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. When a PCP proxy [RFC7648] is located between a PCP server and PCP clients, the proxy may perform authentication with the PCP server before it processes requests from the clients. In addition,
re-authentication between the PCP proxy and PCP server will not interrupt the service that the proxy provides to the clients, since the proxy is still allowed to send common PCP messages to the PCP server during that period.9. References
9.1. Normative References
[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
[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
Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen, Stephen Farrell, and Terry Manderson for their valuable comments.
Authors' Addresses
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