idnits 2.17.1 draft-ietf-pcp-authentication-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2015) is 3221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5281 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft S. Hartman 4 Intended status: Standards Track Painless Security 5 Expires: December 31, 2015 D. Zhang 6 Huawei 7 T. Reddy 8 Cisco 9 June 29, 2015 11 Port Control Protocol (PCP) Authentication Mechanism 12 draft-ietf-pcp-authentication-12 14 Abstract 16 An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to 17 flexibly manage the IP address and port mapping information on 18 Network Address Translators (NATs) or firewalls, to facilitate 19 communication with remote hosts. However, the un-controlled 20 generation or deletion of IP address mappings on such network devices 21 may cause security risks and should be avoided. In some cases the 22 client may need to prove that it is authorized to modify, create or 23 delete PCP mappings. This document describes an in-band 24 authentication mechanism for PCP that can be used in those cases. 25 The Extensible Authentication Protocol (EAP) is used to perform 26 authentication between PCP devices. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 31, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 66 3.1.1. Authentication triggered by the client . . . . . . . 6 67 3.1.2. Authentication triggered by the server . . . . . . . 7 68 3.1.3. Authentication using EAP . . . . . . . . . . . . . . 8 69 3.2. Session Termination . . . . . . . . . . . . . . . . . . . 9 70 3.3. Session Re-Authentication . . . . . . . . . . . . . . . . 9 71 4. PA Security Association . . . . . . . . . . . . . . . . . . . 10 72 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 12 74 5.2. Opcode-specific information of AUTHENTICATION Opcode . . 13 75 5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 13 76 5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 14 77 5.5. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 15 78 5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 16 79 5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 16 80 5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 17 81 5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 17 82 5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 17 83 5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 18 84 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19 85 6.1. Authentication Data Generation . . . . . . . . . . . . . 19 86 6.2. Authentication Data Validation . . . . . . . . . . . . . 20 87 6.3. Retransmission Policies for PA Messages . . . . . . . . . 20 88 6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 21 89 6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 22 90 6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 23 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 24 94 7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 25 95 7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 25 96 7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 26 98 7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 26 99 7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 26 100 7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 27 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 103 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 10.1. Changes from wasserman-pcp-authentication-02 to ietf- 105 pcp-authentication-00 . . . . . . . . . . . . . . . . . 28 106 10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 28 107 10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 29 108 10.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 29 109 10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 29 110 10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 29 111 10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 30 112 10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 30 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 115 11.2. Informative References . . . . . . . . . . . . . . . . . 31 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 118 1. Introduction 120 Using the Port Control Protocol (PCP) [RFC6887], an application can 121 flexibly manage the IP address mapping information on its network 122 address translators (NATs) and firewalls, and control their policies 123 in processing incoming and outgoing IP packets. Because NATs and 124 firewalls both play important roles in network security 125 architectures, there are many situations in which authentication and 126 access control are required to prevent un-authorized users from 127 accessing such devices. This document defines a PCP security 128 extension that enables PCP servers to authenticate their clients with 129 Extensible Authentication Protocol (EAP). The EAP messages are 130 encapsulated within PCP messages during transportation. 132 The following issues are considered in the design of this extension: 134 o Loss of EAP messages during transportation 136 o Reordered delivery of EAP messages 138 o Generation of transport keys 139 o Integrity protection and data origin authentication for PCP 140 messages 142 o Algorithm agility 144 The mechanism described in this document meets the security 145 requirements to address the Advanced Threat Model described in the 146 base PCP specification [RFC6887]. This mechanism can be used to 147 secure PCP in the following situations: 149 o On security infrastructure equipment, such as corporate firewalls, 150 that do not create implicit mappings for specific traffic. 152 o On equipment (such as CGNs or service provider firewalls) that 153 serve multiple administrative domains and do not have a mechanism 154 to securely partition traffic from those domains. 156 o For any implementation that wants to be more permissive in 157 authorizing applications to create mappings for successful inbound 158 communications destined to machines located behind a NAT or a 159 firewall. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 Most of the terms used in this document are introduced in [RFC6887]. 169 PCP Client: A PCP software instance that is responsible for issuing 170 PCP requests to a PCP server. In this document, a PCP client is also 171 a EAP peer [RFC3748], and it is the responsibility of a PCP client to 172 provide the credentials when authentication is required. 174 PCP Server: A PCP software instance that resides on the PCP- 175 Controlled Device that receives PCP requests from the PCP client and 176 creates appropriate state in response to that request. In this 177 document, a PCP server is integrated with an EAP authenticator 178 [RFC3748]. Therefore, when necessary, a PCP server can verify the 179 credentials provided by a PCP client and make an access control 180 decision based on the authentication result. 182 PCP-Authentication (PA) Session: A series of PCP message exchanges 183 transferred between a PCP client and a PCP server. The PCP messages 184 involved within a session includes the PCP Authentication (PA) 185 messages used to perform EAP authentication, key distribution and 186 session management, and the common PCP messages secured with the keys 187 distributed during authentication. Each PA session is assigned a 188 distinctive Session ID. 190 Session Partner: A PCP implementation involved within a PA session. 191 Each PA session has two session partners (a PCP server and a PCP 192 client). 194 PCP device: A PCP client or a PCP server. 196 Session Lifetime: The lifetime associated with a PA session, which 197 decides the lifetime of the current authorization given to the PCP 198 client. 200 PCP Security Association (PCP SA): A PCP security association is 201 formed between a PCP client and a PCP server by sharing cryptographic 202 keying material and associated context. The formed duplex security 203 association is used to protect the bidirectional PCP signaling 204 traffic between the PCP client and PCP server. 206 Master Session Key (MSK): A key derived by the partners of a PA 207 session, using an EAP key generating method (e.g., the one defined in 208 [RFC5448]). 210 PCP-Authentication (PA) message: A PCP message containing an 211 AUTHENTICATION Opcode. Particularly, a PA message sent from a PCP 212 server to a PCP client is referred to as a PA-Server message, while a 213 PA message sent from a PCP client to a PCP server is referred to as a 214 PA-Client message. Therefore, a PA-Server message is actually a PCP 215 response message specified in [RFC6887], and a PA-Client message is a 216 PCP request message. This document specifies an option, the 217 PA_AUTHENTICATION_TAG Option defined in Section 5.5 for PCP 218 authentication, to provide integrity protection and message origin 219 authentication for PA messages. 221 Common PCP message: A PCP message which does not contain an 222 AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG 223 Option to provide integrity protection and message origin 224 authentication for the common PCP messages. 226 3. Protocol Details 228 3.1. Session Initiation 230 At the beginning of a PA session, a PCP client and a PCP server need 231 to exchange a series of PA messages in order to perform an EAP 232 authentication process. Each PA message MUST contain an 233 AUTHENTICATION Opcode and may optionally contain a set of Options for 234 various purposes (e.g., transporting authentication messages and 235 session management). The opcode-specific information in a 236 AUTHENTICATION Opcode consists of two fields : Session ID and 237 Sequence Number. The Session ID field is used to identify the PA 238 session to which the message belongs. The sequence number field is 239 used to detect whether reordering or duplication occurred during 240 message delivery. 242 3.1.1. Authentication triggered by the client 244 When a PCP client intends to proactively initiate a PA session with a 245 PCP server, it sends a PA-Initiation message (a PA-Client message 246 with the result code "INITIATION") to the PCP server. Section 5.1 247 updates the PCP request message format to have a result code. In the 248 message, the Session ID and Sequence Number fields of the 249 AUTHENTICATION Opcode are set as 0. The PA-Client message SHOULD 250 also contain a NONCE option defined in Section 5.3 which consists of 251 a random nonce. 253 After receiving the PA-Initiation, if the PCP server agrees to 254 initiate a PA session with the PCP client, it will reply with a PA- 255 Server message which contains an EAP Identity Request, and the result 256 code field of this PA-Server message is set to 257 AUTHENTICATION_REQUIRED. In addition, the server MUST assign a 258 random session identifier to distinctly identify this session, and 259 fill the identifier into the Session ID field of the AUTHENTICATION 260 Opcode in the PA-Server message. The Sequence Number field of the 261 AUTHENTICATION Opcode is set as 0. If there is a NONCE option in the 262 received PA-Initiation message, the PA-Server message MUST contain a 263 NONCE option so as to send the nonce value back. The nonce will then 264 be used by the PCP client to check the freshness of this message. 265 From now on, every PCP message within this PA session MUST contain 266 this session identifier. When receiving a PA message from an unknown 267 session, a PCP device MUST discard the message silently. If the PCP 268 client intends to simplify the authentication process, it MAY append 269 an EAP Identity Response message within the PA-Initiation message so 270 as to inform the PCP server that it would like to perform EAP 271 authentication and skip the step of waiting for the EAP Identity 272 Request. 274 PCP PCP 275 client server 276 |-- PA-Initiation-------------------------------->| 277 | (Seq=0, Session ID=0) | 278 | | 279 |<-- PA-Server -----------------------------------| 280 | (Seq=0, Session ID=X, EAP Identity request) | 281 | | 282 |-- PA-Client ----------------------------------->| 283 | (Seq=1, Session ID=X, EAP Identity response) | 284 | | 285 |<-- PA-Server -----------------------------------| 286 | (Seq=1, Session ID=X, EAP Identity request) | 288 3.1.2. Authentication triggered by the server 290 In the scenario where a PCP server receives a common PCP request 291 message from a PCP client which needs to be authenticated, the PCP 292 server can reply with a PA-Server message to initiate a PA session. 293 The result code field of this PA-Server message is set to 294 AUTHENTICATION_REQUIRED. In addition, the PCP server MUST assign a 295 Session ID for the session and transfer it within the PA-Server 296 message. The Sequence Number field in the PA-Server message is set 297 as 0. In the PA messages exchanged afterwards in this session, the 298 Session ID will be used in order to help session partners distinguish 299 the messages within this session from those not within. When the PCP 300 client receives this initial PA-Server message from the PCP server, 301 it can reply with a PA-Client message or silently discard the request 302 message according to its local policies. In the PA-Client message, a 303 NONCE option which consists of a random nonce MAY be appended. If 304 so, in the next PA-Server message, the PCP server MUST forward the 305 nonce back within a NONCE option. 307 PCP PCP 308 client server 309 |-- Common PCP request--------------------------->| 310 | | 311 |<-- PA-Server -----------------------------------| 312 | (Seq=0, Session ID=X, EAP Identity request) | 313 | | 314 |-- PA-Client ----------------------------------->| 315 | (Seq=0, Session ID=X, EAP Identity response) | 316 | | 317 |<-- PA-Server -----------------------------------| 318 | (Seq=1, Session ID=X, EAP Identity request) | 320 3.1.3. Authentication using EAP 322 In a PA session, an EAP Identity request message is transported 323 within a PA-Server message, and an EAP Identity response message is 324 transported within a PA-Client message. EAP relies on the underlying 325 protocol to provide reliable transmission; any reordered delivery or 326 loss of packets occurring during transportation must be detected and 327 addressed. Therefore, after sending out a PA-Server message, the PCP 328 server will not send a new PA-Server message until it receives a PA- 329 Client message with a proper sequence number from the PCP client, and 330 vice versa. If a PCP client receives a PA message containing an EAP 331 Identity request and cannot generate an EAP Identity response 332 immediately due to certain reasons (e.g., waiting for human input to 333 construct a EAP message or waiting for the additional PA messages in 334 order to construct a complete EAP message), the PCP device MUST reply 335 with a PA-Acknowledgement message (PA message with a RECEIVED_PAK 336 Option) to indicate that the message has been received. This 337 approach not only can avoid unnecessary retransmission of the PA 338 message but also can guarantee the reliable message delivery in the 339 conditions where a PCP device needs to receive multiple PA messages 340 before generating an EAP Identity response. 342 In this approach, PCP client and a PCP server MUST perform a key- 343 generating EAP method in authentication. Particularly, a PCP 344 authentication implementation MUST support EAP-TTLS [RFC5281] and 345 SHOULD support TEAP [RFC7170]. Therefore, after a successful 346 authentication procedure, a Master Session Key (MSK) will be 347 generated. If the PCP client and the PCP server want to generate a 348 transport key using the MSK, they need to agree upon a Pseudo-Random 349 Function (PRF) for the transport key derivation and a MAC algorithm 350 to provide data origin authentication for subsequent PCP messages. 351 In order to do this, the PCP server needs to append a set of PRF 352 Options and MAC_ALGORITHM Options to the initial PA-Server message. 353 Each PRF Option contains a PRF that the PCP server supports, and each 354 MAC_ALGORITHM Option contains a MAC (Message Authentication Code) 355 algorithm that the PCP server supports. Moreover, in the first PA- 356 Server message, the server MAY also attach an ID_INDICATOR Option 357 defined in Section 5.11 to direct the client to choose correct 358 credentials. After receiving the options, the PCP client MUST select 359 the PRF and the MAC algorithm which it would like to use, and then 360 adds the associated PRF and MAC Algorithm Options to the next PA- 361 Client message. 363 After the EAP authentication, the PCP server sends out a PA-Server 364 message to indicate the EAP authentication and PCP authorization 365 results. If the EAP authentication succeeds, the result code of the 366 PA-Server message is AUTHENTICATION_SUCCEEDED. In this case, before 367 sending out the PA-Server message, the PCP server MUST generate a PCP 368 SA and use the derived transport key to generate a digest for the 369 message. The digest is transported within an PA_AUTHENTICATION_TAG 370 Option for PCP Auth. A more detailed description of generating the 371 authentication data can be found in Section 6.1. In addition, the 372 PA-Server message MAY also contain a SESSION_LIFETIME Option defined 373 in Section 5.9 which indicates the lifetime of the PA session (i.e., 374 the lifetime of the MSK). After receiving the PA-Server message, the 375 PCP client then needs to generate a PA-Client message as response. 376 If the PCP client also authenticates the PCP server, the result code 377 of the PA-Client message is AUTHENTICATION_SUCCEEDED. In addition, 378 the PCP client needs to generate a PCP SA and uses the derived 379 transport key to secure the message. From then on, all the PCP 380 messages within the session are secured with the transport key and 381 the MAC algorithm specified in the PCP SA, unless a re-authentication 382 is performed. The first secure PA-client message from the client 383 MUST include the set of PRF and MAC_ALGORITHM options received from 384 the PCP server. The PCP server determines if the set of algorithms 385 conveyed by the client matches the set it had initially sent, to 386 detect an algorithm downgrade attack. If the server detects a 387 downgrade attack then it MUST send a PA-Server message with result 388 code DOWNGRADE_ATTACK_DETECTED and terminate the session. 390 If a PCP client/server cannot authenticate its session partner, the 391 device sends out a PA message with the result code, 392 AUTHENTICATION_FAILED. If the EAP authentication succeeds but 393 authorization fails, the device making the decision sends out a PA 394 message with the result code, AUTHORIZATION_FAILED. In these two 395 cases, after the PA message is sent out, the PA session MUST be 396 terminated immediately. 398 3.2. Session Termination 400 A PA session can be explicitly terminated by sending a termination- 401 indicating PA message (a PA message with a result code 402 "SESSION_TERMINATED" ) from either session partner. After receiving 403 a Termination-Indicating message from the session partner, a PCP 404 device MUST respond with a Termination-Indicating PA message and 405 remove the PA SA immediately. When the session partner initiating 406 the termination process receives the PA message, it will remove the 407 associated PA SA immediately. 409 3.3. Session Re-Authentication 411 A session partner may select to perform EAP re-authentication if it 412 would like to update the PCP SA without initiating a new PA session. 413 For example a re-authentication procedure could be triggered for the 414 following reasons: 416 o The session lifetime needs to be extended. 418 o The sequence number is going to reach the maximum value. 419 Specifically, when the sequence number reaches 2**32 - 2**16, the 420 session partner MUST trigger re-authentication. 422 When the PCP server would like to initiate a re-authentication, it 423 sends the PCP client a PA-Server message. The result code of the 424 message is set to "RE-AUTHENTICATION", which indicates the message is 425 for a re-authentication process. If the PCP client would like to 426 start the re-authentication, it will send a PA-Client message to the 427 PCP server, with the result code of the PA-Client message set to "RE- 428 AUTHENTICATION". Then, the session partners exchange PA messages to 429 transfer EAP messages for the re-authentication. During the re- 430 authentication procedure, the session partners protect the integrity 431 of PA messages with the key and MAC algorithm specified in the 432 current PCP SA; the sequence numbers associated with the message will 433 continue to keep increasing according to Section 6.3. 435 If the EAP re-authentication succeeds, the result code of the last 436 PA-Server message is "AUTHENTICATION_SUCCEEDED". In this case, 437 before sending out the PA-Server message, the PCP server MUST update 438 the SA and use the new key to generate a digest for the PA-Server 439 message and subsequent PCP messages. In addition, the PA-Server 440 message MAY be appended with a SESSION_LIFETIME Option which 441 indicates the new lifetime of the PA session. PA and PCP message 442 sequence numbers must also be reset to zero. 444 If the EAP authentication fails, the result code of the last PA- 445 Server message is "AUTHENTICATION_FAILED". If the EAP authentication 446 succeeds but authorization fails, the result code of the last PA- 447 Server message is "AUTHORIZATION_FAILED". In the latter two cases, 448 the PA session MUST be terminated immediately after the last PA 449 message exchange. 451 During re-authentication, the session partners can also exchange 452 common PCP messages in parallel. The common PCP messages MUST be 453 protected with the current SA until the new SA has been generated. 455 4. PA Security Association 457 At the beginning of a PA session, a session MUST generate a PA SA to 458 maintain its state information during the session. The parameters of 459 a PA SA are listed as follows: 461 o IP address and UDP port number of the PCP client 463 o IP address and UDP port number of the PCP server 464 o Session Identifier 466 o Sequence number for the next outgoing PA message 468 o Sequence number for the next incoming PA message 470 o Sequence number for the next outgoing common PCP message 472 o Sequence number for the next incoming common PCP message 474 o Last outgoing message payload 476 o Retransmission interval 478 o The master session key (MSK) generated by the EAP method. 480 o The MAC algorithm that the transport key should use to generate 481 digests for PCP messages. 483 o The pseudo random function negotiated in the initial PA-Server and 484 PA-Client message exchange for the transport key derivation 486 o The transport key derived from the MSK to provide integrity 487 protection and data origin authentication for the messages in the 488 PA session. The lifetime of the transport key SHOULD be identical 489 to the lifetime of the session. 491 o The nonce selected by the PCP client at the initiation of the 492 session. 494 o The Key ID associated with Transport key. 496 Particularly, the transport key is computed in the following way: 497 Transport key = prf(MSK, "IETF PCP" || Session ID || Nonce || key 498 ID), where: 500 o prf: The pseudo-random function assigned in the Pseudo-random 501 function parameter. 503 o MSK: The master session key generated by the EAP method. 505 o "IETF PCP": The ASCII code representation of the non-NULL 506 terminated string (excluding the double quotes around it). 508 o '||' : is the concatenation operator. 510 o Session ID: The ID of the session which the MSK is derived from. 512 o Nonce: The nonce selected by the client and transported in the 513 Initial PA-Client message. If the PCP client does not select one, 514 this value is set as 0. 516 o Key ID: The ID assigned for the transport key. 518 5. Packet Format 520 5.1. Packet Format of PCP Auth Messages 522 The format of the PA-Server message is identical to the response 523 message format specified in Section 7.2 of [RFC6887]. The result 524 code for PA-Sever message carrying EAP Identity request MUST be set 525 to AUTHENTICATION_REQUIRED. 527 As illustrated in Figure 1, the PA-Client messages use the request 528 header specified in Section 7.1 of[RFC6887]. The only difference is 529 that eight reserved bits are used to transfer the result codes (e.g., 530 "INITIATION", "AUTHENTICATION_FAILED"). Other fields in Figure 1 are 531 described in Section 7.1 of [RFC6887]. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Version = 2 |R| Opcode | Reserved | Result Code | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Requested Lifetime (32 bits) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 | PCP Client's IP Address (128 bits) | 542 | | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 : : 546 : Opcode-specific information : 547 : : 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 : : 550 : (optional) PCP Options : 551 : : 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 1. PA-Client message Format 556 The Requested Lifetime field of PA-Client message and Lifetime field 557 of PA-Server message are both set to 0 on transmission and ignored on 558 reception. 560 5.2. Opcode-specific information of AUTHENTICATION Opcode 562 The following diagram shows the format of the Opcode-specific 563 information for the AUTHENTICATION Opcode. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Session ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Sequence Number | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Session ID: This field contains a 32-bit PA session identifier. 575 Sequence Number: This field contains a 32-bit sequence number. A 576 sequence number needs to be incremented on every new (non- 577 retransmission) outgoing message in order to provide an ordering 578 guarantee for PCP messages. 580 5.3. NONCE Option 582 Because the session identifier of a PA session is determined by the 583 PCP server, a PCP client does not know the session identifier which 584 will be used when it sends out a PA-Initiation message. In order to 585 prevent an attacker from interrupting the authentication process by 586 sending off-line generated PA-Server messages, the PCP client needs 587 to generate a random number as a nonce in the PA-Initiation message. 588 The PCP server will append the nonce within the initial PA-Server 589 message. If the PA-Server message does not carry the correct nonce, 590 the message MUST be discarded silently. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Option Code | Reserved | Option-Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Nonce | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Option Code: TBA-130. 602 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 603 ignored on reception. 605 Option-Length: 4 octets. 607 Nonce: A random 32 bit number which is transported within a PA- 608 Initiation message and the corresponding reply message from the 609 PCP server. 611 5.4. AUTHENTICATION_TAG Option 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Option Code | Reserved | Option-Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Session ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Sequence Number | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Key ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | | 625 | Authentication Data (Variable) | 626 ~ ~ 627 | | 628 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Because there is no authentication Opcode in common PCP messages, the 632 authentication tag for common PCP messages needs to carry the Session 633 ID and Sequence Number. 635 Option Code: TBA-131. 637 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 638 ignored on reception. 640 Option-Length: The length of the AUTHENTICATION_TAG Option for 641 Common PCP message (in octets), including the 12 octet fixed 642 header and the variable length of the authentication data. 644 Session ID: A 32-bit field used to identify the session to which 645 the message belongs and identify the secret key used to create the 646 message digest appended to the PCP message. 648 Sequence Number: A 32-bit sequence number. In this solution, a 649 sequence number needs to be incremented on every new (non- 650 retransmission) outgoing message in order to provide ordering 651 guarantee for common PCP messages. 653 Key ID: The ID associated with the transport key used to generate 654 authentication data. This field is filled with zero if the MSK is 655 directly used to secure the message. 657 Authentication Data: A variable-length field that carries the 658 Message Authentication Code for the Common PCP message. The 659 generation of the digest varies according to the algorithms 660 specified in different PCP SAs. This field MUST end on a 32-bit 661 boundary, padded with 0's when necessary. 663 5.5. PA_AUTHENTICATION_TAG 665 This option is used to provide message authentication for PA 666 messages. Compared with the AUTHENTICATION_TAG Option for Common PCP 667 Messages, the Session ID field and the Sequence Number field are 668 removed because such information is provided in the AUTHENTICATION 669 Opcode. 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Option Code | Reserved | Option-Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Key ID | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | | 679 | Authentication Data (Variable) | 680 ~ ~ 681 | | 682 | | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Option Code: TBA-132. 687 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 688 ignored on reception. 690 Option-Length: The length of the PA_AUTHENTICATION Option for PCP 691 Auth message (in octet), including the 4 octet fixed header and 692 the variable length of the authentication data. 694 Key ID: The ID associated with the transport key used to generate 695 authentication data. This field is filled with zero if the MSK is 696 directly used to secure the message. 698 Authentication Data: A variable-length field that carries the 699 Message Authentication Code for the PCP Auth message. The 700 generation of the digest varies according to the algorithms 701 specified in different PCP SAs. This field MUST end on a 32-bit 702 boundary, padded with null characters when necessary. 704 5.6. EAP_PAYLOAD Option 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Option Code | Reserved | Option-Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 | EAP Message | 713 ~ ~ 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Option Code: TBA-133. 719 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 720 ignored on reception. 722 Option-Length: Variable 724 EAP Message: The EAP message transferred. Note this field MUST 725 end on a 32-bit boundary, padded with 0's when necessary. 727 5.7. PRF Option 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Option Code | Reserved | Option-Length | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | PRF | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Option Code: TBA-134. 739 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 740 ignored on reception. 742 Option-Length: 4 octets. 744 PRF: The Pseudo-Random Function which the sender supports to generate 745 an MSK. This field contains an IKEv2 Transform ID of Transform Type 746 2 [RFC7296][RFC4868]. A PCP implementation MUST support 747 PRF_HMAC_SHA2_256 (5). 749 5.8. MAC_ALGORITHM Option 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Option Code | Reserved | Option-Length | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | MAC Algorithm ID | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Option Code: TBA-135. 761 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 762 ignored on reception. 764 Option-Length: 4 octets. 766 MAC Algorithm ID: Indicate the MAC algorithm which the sender 767 supports to generate authentication data. The MAC Algorithm ID field 768 contains an IKEv2 Transform ID of Transform Type 3 769 [RFC7296][RFC4868]. A PCP implementation MUST support 770 AUTH_HMAC_SHA2_256_128 (12). 772 5.9. SESSION_LIFETIME Option 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Option Code | Reserved | Option-Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Session Lifetime | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Option Code: TBA-136. 784 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 785 ignored on reception. 787 Option-Length: 4 octets. 789 Session Lifetime: The lifetime of the PA Session, which is decided by 790 the authorization result. 792 5.10. RECEIVED_PAK Option 794 This option is used in a PA-Acknowledgement message to indicate that 795 a message with the contained sequence number has been received. 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Option Code | Reserved | Option-Length | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Received Sequence Number | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Option Code: TBA-137. 807 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 808 ignored on reception. 810 Option-Length: 4 octets. 812 Received Sequence Number: The sequence number of the last received 813 PCP message. 815 5.11. ID_INDICATOR Option 817 The ID_INDICATOR option is used by the PCP client to determine which 818 credentials to provide to the PCP server. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Option Code | Reserved | Option-Length | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | | 826 | ID Indicator | 827 ~ ~ 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Option Code: TBA-138. 833 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 834 ignored on reception. 836 Option-Length: Variable. 838 ID Indicator: The identity of the authority that issued the 839 credentials. The field MUST end on a 32-bit boundary, padded with 840 0's when necessary. The ID indicator field is UTF-8 encoded 841 [RFC3629] Unicode string conforming to the "UsernameCaseMapped" 842 profile of the PRECIS IdentifierClass 843 [I-D.ietf-precis-saslprepbis]. The PCP client validates that the 844 ID indicator field conforms to the "UsernameCaseMapped" profile of 845 the PRECIS IdentifierClass. The PCP client enforces the rules 846 specified in section 3.2.2 of [I-D.ietf-precis-saslprepbis] to map 847 the ID indicator field. The PCP client compares the resulting 848 string with the ID indicators stored locally on the PCP client to 849 pick the credentials for authentication. The two indicator 850 strings are to be considered equivalent by the client if and only 851 if they are an exact octet-for-octet match. 853 6. Processing Rules 855 6.1. Authentication Data Generation 857 If a PCP SA is generated as the result of a successful EAP 858 authentication process, every subsequent PCP message within the 859 session MUST carry an authentication tag which contains the digest of 860 the PCP message for data origin authentication and integrity 861 protection. 863 o Before generating a digest for a PA message, a device needs to 864 first locate the PCP SA according to the session identifier and 865 then get the transport key. Then the device appends an 866 PA_AUTHENTICATION_TAG Option for PCP Auth at the end of the PCP 867 Auth message. The length of the Authentication Data field is 868 decided by the MAC algorithm adopted in the session. The device 869 then fills the Key ID field with the key ID of the transport key, 870 and sets the Authentication Data field to 0. After this, the 871 device generates a digest for the entire PCP message (including 872 the PCP header and PA_AUTHENTICATION_TAG Option) using the 873 transport key and the associated MAC algorithm, and inserts the 874 generated digest into the Authentication Data field. 876 o Similar to generating a digest for a PA message, before generating 877 a digest for a common PCP message, a device needs to first locate 878 the PCP SA according to the session identifier and then get the 879 transport key. Then the device appends the AUTHENTICATION_TAG 880 Option at the end of common PCP message. The length of the 881 Authentication Data field is decided by the MAC algorithm adopted 882 in the session. The device then uses the corresponding values 883 derived from the SA to fill the Session ID field, the Sequence 884 Number field, and the Key ID field, and sets the Authentication 885 Data field to 0. After this, the device generates a digest for 886 the entire PCP message (including the PCP header and 887 AUTHENTICATION_TAG Option) using the transport key and the 888 associated MAC algorithm, and inputs the generated digest into the 889 Authentication Data field. 891 6.2. Authentication Data Validation 893 When a device receives a common PCP message with an 894 AUTHENTICATION_TAG Option for Common PCP Messages, the device needs 895 to use the Session ID transported in the option to locate the proper 896 SA, and then find the associated transport key (using the key ID in 897 the option) and the MAC algorithm. If no proper SA or transport key 898 is found or the sequence number is invalid (see Section 6.5), the PCP 899 message MUST be discarded silently. After storing the value of the 900 Authentication field of the AUTHENTICATION_TAG Option, the device 901 fills the Authentication field with zeros. Then, the device 902 generates a digest for the message (including the PCP header and 903 Authentication Tag Option) with the transport key and the MAC 904 algorithm. If the value of the newly generated digest is identical 905 to the stored one, the device can ensure that the message has not 906 been tampered with, and the validation succeeds. Otherwise, the 907 message MUST be discarded. 909 Similarly, when a device receives a PA message with an 910 PA_AUTHENTICATION_TAG Option for PCP Authentication, the device needs 911 to use the Session ID transported in the Opcode to locate the proper 912 SA, and then find the associated transport key (using the key ID in 913 the option) and the MAC algorithm. If no proper SA or transport key 914 is found or the sequence number is invalid (see Section 6.4), the PCP 915 message MUST be discarded silently. After storing the value of the 916 Authentication field of the PA_AUTHENTICATION_TAG Option, the device 917 fills the Authentication field with zeros. Then, the device 918 generates a digest for the message (including the PCP header and 919 PA_AUTHENTICATION_TAG Option) with the transport key and the MAC 920 algorithm. If the value of the newly generated digest is identical 921 to the stored one, the device can ensure that the message has not 922 been tampered with, and the validation succeeds. Otherwise, the 923 message MUST be discarded. 925 6.3. Retransmission Policies for PA Messages 927 Because EAP relies on the underlying protocols to provide reliable 928 transmission, after sending a PA message, a PCP client/server MUST 929 NOT send out any subsequent messages until receiving a PA message 930 with a proper sequence number from the peer. If no such a message is 931 received the PCP device will re-send the last message according to 932 retransmission policies. This work reuses the retransmission 933 policies specified in the base PCP protocol (Section 8.1.1 of 934 [RFC6887]). In the base PCP protocol, such retransmission policies 935 are only applied by PCP clients. However, in this work, such 936 retransmission policies are also applied by the PCP servers. If 937 Maximum retransmission duration seconds have elapsed and no expected 938 response is received, the device will terminate the session and 939 discard the current SA. 941 As illustrated in Section 3.1.3, in order to avoid unnecessary re- 942 transmission, the device receiving a PA message MUST send a PA- 943 Acknowledgement message to the sender of the PA message when it 944 cannot send a PA response immediately. The PA-Acknowledgement 945 message is used to indicate the receipt of the PA message. When the 946 sender receives the PA-Acknowledgement message, it will stop the 947 retransmission. 949 Note that the last PA messages transported within the phases of 950 session initiation, session re-authentication, and session 951 termination do not have to follow the above policies since the 952 devices sending out those messages do not expect any further PA 953 messages. 955 When a device receives a re-transmitted last incoming PA message from 956 its session partner, it MUST try to answer it by sending the last 957 outgoing PA message again. However, if the duplicate message has the 958 same sequence number but is not bit-wise identical to the original 959 message then the device MUST discard it. In order to achieve this 960 function, the device may need to maintain the last incoming and the 961 associated outgoing messages. In this case, if no outgoing PA 962 message has been generated for the received duplicate PA message yet, 963 the device needs to send a PA-Acknowledgement message. The rate of 964 replying to duplicate PA messages MUST be limited to provide 965 robustness against denial of service (DoS) attacks. The details of 966 rate limiting are outside the scope of this specification. 968 6.4. Sequence Numbers for PCP Auth Messages 970 PCP uses UDP to transport signaling messages. As an un-reliable 971 transport protocol, UDP does not guarantee ordered packet delivery 972 and does not provide any protection from packet loss. In order to 973 ensure the EAP messages are exchanged in a reliable way, every PCP 974 message exchanged during EAP authentication must carry a 975 monotonically increasing sequence number. During a PA session, a PCP 976 device needs to maintain two sequence numbers for PA messages, one 977 for incoming PA messages and one for outgoing PA messages. When 978 generating an outgoing PA message, the device adds the associated 979 outgoing sequence number to the message and increments the sequence 980 number maintained in the SA by 1. When receiving a PA message from 981 its session partner, the device will not accept it if the sequence 982 number carried in the message does not match the incoming sequence 983 number the device maintains. After confirming that the received 984 message is valid, the device increments the incoming sequence number 985 maintained in the SA by 1. 987 The above rules are not applicable to PA-Acknowledgement messages 988 (i.e., PA messages containing a RECEIVED_PAK Option). A PA- 989 Acknowledgement message does not transport any EAP message and only 990 indicates that a PA message is received. Therefore, reliable 991 transmission of PA-Acknowledgement messages is not required. For 992 instance, after sending out a PA-Acknowledgement message, a device 993 generates an EAP Identity response. In this case, the device need 994 not have to confirm whether the PA-Acknowledgement message has been 995 received by its session partner or not. Therefore, when receiving or 996 sending out a PA-Acknowledgement message, the device MUST NOT 997 increase the corresponding sequence number stored in the SA. 998 Otherwise, loss of a PA-Acknowledgement message will cause a mismatch 999 in sequence numbers. 1001 Another exception is the message retransmission scenario. As 1002 discussed in Section 6.3, when a PCP device does not receive any 1003 response from its session partner it needs to retransmit the last 1004 outgoing PA message following the retransmission procedure specified 1005 in section 8.1.1 of [RFC6887]. The original message and duplicate 1006 messages MUST be bit-wise identical. When the device receives such a 1007 duplicate PA message from its session partner, it MUST send the last 1008 outgoing PA message again. In such cases, the maintained incoming 1009 and outgoing sequence numbers will not be affected by the message 1010 retransmission. 1012 6.5. Sequence Numbers for Common PCP Messages 1014 When transporting common PCP messages within a PA session, a PCP 1015 device needs to maintain a sequence number for outgoing common PCP 1016 messages and a sequence number for incoming common PCP messages. 1017 When generating a new outgoing PCP message, the PCP device updates 1018 the Sequence Number field in the AUTHENTICATION_TAG option with the 1019 outgoing sequence number maintained in the SA and increments the 1020 outgoing sequence number by 1. 1022 When receiving a PCP message from its session partner, the PCP device 1023 will not accept it if the sequence number carried in the message is 1024 smaller than the incoming sequence number the device maintains. This 1025 approach can protect the PCP device from replay attacks. After 1026 confirming that the received message is valid, the PCP device will 1027 update the incoming sequence number maintained in the PCP SA with the 1028 sequence number of the incoming message. 1030 Note that the sequence number in the incoming message may not exactly 1031 match the incoming sequence number maintained locally. As discussed 1032 in the base PCP specification [RFC6887], if a PCP client is no longer 1033 interested in the PCP transaction and has not yet received a PCP 1034 response from the server then it will stop retransmitting the PCP 1035 request. After that, the PCP client might generate new PCP requests 1036 for other purposes using the current SA. In this case, the sequence 1037 number in the new request will be larger than the sequence number in 1038 the old request and so will be larger than the incoming sequence 1039 number maintained in the PCP server. 1041 Note that in the base PCP specification [RFC6887], a PCP client needs 1042 to select a nonce in each MAP or PEER request, and the nonce is sent 1043 back in the response. However, it is possible for a client to use 1044 the same nonce in multiple MAP or PEER requests, and this may cause a 1045 potential risk of replay attacks. This attack is addressed by using 1046 the sequence number in the PCP response. 1048 6.6. MTU Considerations 1050 EAP methods are responsible for MTU handling, so no special 1051 facilities are required in PCP to deal with MTU issues. 1052 Particularly, EAP lower layers indicate to EAP methods and AAA 1053 servers the MTU of the lower layer. EAP methods such as EAP-TLS 1054 [RFC5216], TEAP [RFC7170], and others that are likely to exceed 1055 reasonable MTUs provide support for fragmentation and reassembly. 1056 Others, such as EAP-GPSK [RFC5433] assume they will never send 1057 packets larger than the MTU and use small EAP packets. 1059 If an EAP message is too long to be transported within a single PA 1060 message, it will be divided into multiple sections and sent within 1061 different PA messages. Note that the receiver may not be able to 1062 know what to do in the next step until it has received all the 1063 sections and reconstructed the complete EAP message. In this case, 1064 in order to guarantee reliable message transmission, after receiving 1065 a PA message, the receiver replies with a PA-Acknowledgement message 1066 to notify the sender to send the next PA message. 1068 7. IANA Considerations 1070 The following PCP Opcode is to be allocated in the mandatory-to- 1071 process range from the standards action range (the registry for PCP 1072 Opcodes is maintained in http://www.iana.org/assignments/pcp- 1073 parameters): 1075 TBA AUTHENTICATION Opcode. 1077 The following PCP result codes are to be allocated in the mandatory- 1078 to-process range from the standards action range (the registry for 1079 PCP result codes is maintained in http://www.iana.org/assignments/ 1080 pcp-parameters): 1082 TBA INITIATION: The client indication to the server for 1083 authentication. 1085 TBA AUTHENTICATION_REQUIRED: The server indication to the client 1086 that authentication is required. 1088 TBA AUTHENTICATION_FAILED: This error response is signaled to the 1089 client if EAP authentication had failed. 1091 TBA AUTHENTICATION_SUCCEEDED:This success response is signaled to 1092 the client if EAP authentication had succeeded. 1094 TBA AUTHORIZATION_FAILED: This error response is signaled to the 1095 client if the EAP authentication had succeeded but authorization 1096 failed. 1098 TBA SESSION_TERMINATED: This PCP result code indicates to the 1099 partner that the PA session must be terminated. 1101 TBA DOWNGRADE_ATTACK_DETECTED: This error response is signaled to 1102 the client if the server detects downgrade attack. 1104 The following PCP Option Codes are to be allocated in the mandatory- 1105 to-process range from the standards action range (the registry for 1106 PCP Options is maintained in http://www.iana.org/assignments/pcp- 1107 parameters): 1109 7.1. NONCE 1111 Option Name: NONCE 1113 option-code: TBA-130 in the mandatory-to-process range (IANA). 1115 Purpose: See Section 5.3. 1117 Valid for Opcodes: Authentication Opcode. 1119 option-len: Option Length is 4 octets. 1121 May appear in: request and response. 1123 Maximum occurrences: 1. 1125 7.2. AUTHENTICATION_TAG 1127 Option Name: AUTHENTICATION_TAG 1129 option-code: TBA-131 in the mandatory-to-process range (IANA). 1131 Purpose: See Section 5.4. 1133 Valid for Opcodes: MAP, PEER and ANNOUNCE Opcodes. 1135 option-len: Variable length. 1137 May appear in: request and response. 1139 Maximum occurrences: 1. 1141 7.3. PA_AUTHENTICATION_TAG 1143 Option Name: PA_AUTHENTICATION_TAG 1145 option-code: TBA-132 in the mandatory-to-process range (IANA). 1147 Purpose: See Section 5.5. 1149 Valid for Opcodes: Authentication Opcode. 1151 option-len: Variable length. 1153 May appear in: request and response. 1155 Maximum occurrences: 1. 1157 7.4. EAP_PAYLOAD 1159 Option Name: EAP_PAYLOAD. 1161 option-code: TBA-133 in the mandatory-to-process range (IANA). 1163 Purpose: See Section 5.6. 1165 Valid for Opcodes: Authentication Opcode. 1167 option-len: Variable length. 1169 May appear in: request and response. 1171 Maximum occurrences: 1. 1173 7.5. PRF 1175 Option Name: PRF. 1177 option-code: TBA-134 in the mandatory-to-process range (IANA). 1179 Purpose: See Section 5.7. 1181 Valid for Opcodes: Authentication Opcode. 1183 option-len: Option Length is 4 octets. 1185 May appear in: request and response. 1187 Maximum occurrences: as many as fit within maximum PCP message size. 1189 7.6. MAC_ALGORITHM 1191 Option Name: MAC_ALGORITHM. 1193 option-code: TBA-135 in the mandatory-to-process range (IANA). 1195 Purpose: See Section 5.8. 1197 Valid for Opcodes: Authentication Opcode. 1199 option-len: Option Length is 4 octets. 1201 May appear in: request and response. 1203 Maximum occurrences: as many as fit within maximum PCP message size. 1205 7.7. SESSION_LIFETIME 1207 Option Name: SESSION_LIFETIME. 1209 option-code: TBA-136 in the mandatory-to-process range (IANA). 1211 Purpose: See Section 5.9. 1213 Valid for Opcodes: Authentication Opcode. 1215 option-len: Option Length is 4 octets. 1217 May appear in: response. 1219 Maximum occurrences: 1. 1221 7.8. RECEIVED_PAK 1223 Option Name: RECEIVED_PAK. 1225 option-code: TBA-137 in the mandatory-to-process range (IANA). 1227 Purpose: See Section 5.10. 1229 Valid for Opcodes: Authentication Opcode. 1231 option-len: Option Length is 4 octets. 1233 May appear in: request and response. 1235 Maximum occurrences: 1. 1237 7.9. ID_INDICATOR 1239 Option Name: ID_INDICATOR. 1241 option-code: TBA-138 in the mandatory-to-process range (IANA). 1243 Purpose: See Section 5.11. 1245 Valid for Opcodes: Authentication Opcode. 1247 option-len: Variable length. 1249 May appear in: response. 1251 Maximum occurrences: 1. 1253 8. Security Considerations 1255 In this work, after a successful EAP authentication process is 1256 performed between two PCP devices, an MSK will be exported. The MSK 1257 will be used to derive the transport keys to generate MAC digests for 1258 subsequent PCP message exchanges. However, before a transport key 1259 has been generated, the PA messages exchanged within a PA session 1260 have little cryptographic protection, and if there is no already 1261 established security channel between two session partners, these 1262 messages are subject to man-in-the-middle attacks and DOS attacks. 1263 For instance, the initial PA-Server and PA-Client message exchange is 1264 vulnerable to spoofing attacks as these messages are not 1265 authenticated and integrity protected. In addition, because the PRF 1266 and MAC algorithms are transported at this stage, an attacker may try 1267 to remove the PRF and MAC options containing strong algorithms from 1268 the initial PA-Server message and force the client choose the weakest 1269 algorithms. Therefore, the server needs to guarantee that all the 1270 PRF and MAC algorithms it provides support for are strong enough. 1272 In order to prevent very basic DOS attacks, a PCP device SHOULD 1273 generate state information as little as possible in the initial PA- 1274 Server and PA-Client message exchanges. The choice of EAP method is 1275 also very important. The selected EAP method must be resilient to 1276 the attacks possible in an insecure network environment, provide 1277 user-identity confidentiality, protection against dictionary attacks, 1278 and support session-key establishment. 1280 When a PCP proxy is located between a PCP server and PCP clients, the 1281 proxy may perform authentication with the PCP server before it 1282 processes requests from the clients. In addition, re-authentication 1283 between the PCP proxy and PCP server will not interrupt the service 1284 that the proxy provides to the clients since the proxy is still 1285 allowed to send common PCP messages to the PCP server during that 1286 period. 1288 9. Acknowledgements 1290 Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, 1291 Carlos Pignataro, Brian Haberman and Paul Kyzivat for the valuable 1292 comments. 1294 10. Change Log 1296 [Note: This section should be removed by the RFC Editor upon 1297 publication] 1299 10.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1300 authentication-00 1302 o Added discussion of in-band and out-of-band key management 1303 options, leaving choice open for later WG decision. 1305 o Removed support for fragmenting EAP messages, as that is handled 1306 by EAP methods. 1308 10.2. Changes from wasserman-pcp-authentication-01 to -02 1310 o Add a nonce into the first two exchanged PCP-Auth message between 1311 the PCP client and PCP server. When a PCP client initiate the 1312 session, it can use the nonce to detect offline attacks. 1314 o Add the key ID field into the authentication tag option so that a 1315 MSK can generate multiple transport keys. 1317 o Specify that when a PCP device receives a PCP-Auth-Server or a 1318 PCP-Auth-Client message from its partner the PCP device needs to 1319 reply with a PCP-Auth-Acknowledge message to indicate that the 1320 message has been received. 1322 o Add the support of fragmenting EAP messages. 1324 10.3. Changes from ietf-pcp-authentication-00 to -01 1326 o Editorial changes, added use cases to introduction. 1328 10.4. Changes from ietf-pcp-authentication-01 to -02 1330 o Add the support of re-authentication initiated by PCP server. 1332 o Specify that when a PCP device receives a PCP-Auth-Server or a 1333 PCP-Auth-Client message from its partner the PCP device MAY reply 1334 with a PCP-Auth-Acknowledge message to indicate that the message 1335 has been received. 1337 o Discuss the format of the PCP-Auth-Acknowledge message. 1339 o Remove the redundant information from the Auth Opcode, and specify 1340 new result codes transported in PCP packet headers 1342 o 1344 10.5. Changes from ietf-pcp-authentication-02 to -03 1346 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1348 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1350 o Specify two new sequence numbers for common PCP messages in the 1351 PCP SA, and describe how to use them 1353 o Specify a Authentication Tag Option for PCP Common Messages 1355 o Introduce the scenario where a EAP message has to be divided into 1356 multiple sections and transported in different PCP-Auth messages 1357 (for the reasons of MTU), and introduce how to use PCP-Auth- 1358 Acknowledge messages to ensure reliable packet delivery in this 1359 case. 1361 10.6. Changes from ietf-pcp-authentication-03 to -04 1363 o Change the name "PCP-Auth" to "PA". 1365 o Refine the retransmission policies. 1367 o Add more discussion about the sequence number management . 1369 o Provide the discussion about how to instruct a PCP client to 1370 choose proper credential during authentication, and an ID 1371 Indicator Option is defined for that purpose. 1373 10.7. Changes from ietf-pcp-authentication-04 to -05 1375 o Add contents in IANA considerations. 1377 o Add discussions in fragmentation. 1379 o Refine the PA messages retransmission policies. 1381 o Add IANA considerations. 1383 10.8. Changes from ietf-pcp-authentication-05 to -06 1385 o Added mechanism to handle algorithm downgrade attack. 1387 o Updated Security Considerations section. 1389 o Updated ID Indicator Option. 1391 11. References 1393 11.1. Normative References 1395 [I-D.ietf-precis-saslprepbis] 1396 Saint-Andre, P. and A. Melnikov, "Preparation, 1397 Enforcement, and Comparison of Internationalized Strings 1398 Representing Usernames and Passwords", draft-ietf-precis- 1399 saslprepbis-18 (work in progress), May 2015. 1401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1402 Requirement Levels", BCP 14, RFC 2119, March 1997. 1404 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1405 10646", STD 63, RFC 3629, November 2003. 1407 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1408 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1409 3748, June 2004. 1411 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1412 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1414 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1415 Protocol Tunneled Transport Layer Security Authenticated 1416 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 1418 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1419 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1420 2013. 1422 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1423 "Tunnel Extensible Authentication Protocol (TEAP) Version 1424 1", RFC 7170, May 2014. 1426 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1427 Kivinen, "Internet Key Exchange Protocol Version 2 1428 (IKEv2)", STD 79, RFC 7296, October 2014. 1430 11.2. Informative References 1432 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1433 Authentication Protocol", RFC 5216, March 2008. 1435 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1436 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1437 RFC 5433, February 2009. 1439 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1440 Extensible Authentication Protocol Method for 3rd 1441 Generation Authentication and Key Agreement (EAP-AKA')", 1442 RFC 5448, May 2009. 1444 Authors' Addresses 1446 Margaret Wasserman 1447 Painless Security 1448 356 Abbott Street 1449 North Andover, MA 01845 1450 USA 1452 Phone: +1 781 405 7464 1453 Email: mrw@painless-security.com 1454 URI: http://www.painless-security.com 1456 Sam Hartman 1457 Painless Security 1458 356 Abbott Street 1459 North Andover, MA 01845 1460 USA 1462 Email: hartmans@painless-security.com 1463 URI: http://www.painless-security.com 1464 Dacheng Zhang 1465 Huawei 1466 Beijing 1467 China 1469 Email: zhang_dacheng@hotmail.com 1471 Tirumaleswar Reddy 1472 Cisco Systems, Inc. 1473 Cessna Business Park, Varthur Hobli 1474 Sarjapur Marathalli Outer Ring Road 1475 Bangalore, Karnataka 560103 1476 India 1478 Email: tireddy@cisco.com