idnits 2.17.1 draft-ietf-pcp-authentication-13.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 (July 03, 2015) is 3191 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 Updates: 6887 (if approved) Painless Security 5 Intended status: Standards Track D. Zhang 6 Expires: January 4, 2016 Huawei 7 T. Reddy 8 Cisco 9 July 03, 2015 11 Port Control Protocol (PCP) Authentication Mechanism 12 draft-ietf-pcp-authentication-13 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 This document updates RFC6887. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Authentication triggered by the client . . . . . . . 6 69 3.1.2. Authentication triggered by the server . . . . . . . 7 70 3.1.3. Authentication using EAP . . . . . . . . . . . . . . 7 71 3.2. Session Termination . . . . . . . . . . . . . . . . . . . 9 72 3.3. Session Re-Authentication . . . . . . . . . . . . . . . . 10 73 4. PA Security Association . . . . . . . . . . . . . . . . . . . 11 74 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 12 76 5.2. Opcode-specific information of AUTHENTICATION Opcode . . 13 77 5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 14 78 5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 14 79 5.5. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 16 80 5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 17 81 5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 18 83 5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 18 84 5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 19 85 5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 19 86 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 20 87 6.1. Authentication Data Generation . . . . . . . . . . . . . 20 88 6.2. Authentication Data Validation . . . . . . . . . . . . . 21 89 6.3. Retransmission Policies for PA Messages . . . . . . . . . 21 90 6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 22 91 6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 23 92 6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 24 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 94 7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 26 96 7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 26 97 7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 26 98 7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 27 100 7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 27 101 7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 28 102 7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 28 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 105 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 10.1. Changes from wasserman-pcp-authentication-02 to ietf- 107 pcp-authentication-00 . . . . . . . . . . . . . . . . . 29 108 10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 29 109 10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 30 110 10.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 30 111 10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 30 112 10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 31 113 10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 31 114 10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 31 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 117 11.2. Informative References . . . . . . . . . . . . . . . . . 32 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Introduction 122 Using the Port Control Protocol (PCP) [RFC6887], an application can 123 flexibly manage the IP address mapping information on its network 124 address translators (NATs) and firewalls, and control their policies 125 in processing incoming and outgoing IP packets. Because NATs and 126 firewalls both play important roles in network security 127 architectures, there are many situations in which authentication and 128 access control are required to prevent un-authorized users from 129 accessing such devices. This document defines a PCP security 130 extension that enables PCP servers to authenticate their clients with 131 Extensible Authentication Protocol (EAP). The EAP messages are 132 encapsulated within PCP messages during transportation. 134 The following issues are considered in the design of this extension: 136 o Loss of EAP messages during transportation 138 o Reordered delivery of EAP messages 140 o Generation of transport keys 141 o Integrity protection and data origin authentication for PCP 142 messages 144 o Algorithm agility 146 The mechanism described in this document meets the security 147 requirements to address the Advanced Threat Model described in the 148 base PCP specification [RFC6887]. This mechanism can be used to 149 secure PCP in the following situations: 151 o On security infrastructure equipment, such as corporate firewalls, 152 that do not create implicit mappings for specific traffic. 154 o On equipment (such as CGNs or service provider firewalls) that 155 serve multiple administrative domains and do not have a mechanism 156 to securely partition traffic from those domains. 158 o For any implementation that wants to be more permissive in 159 authorizing applications to create mappings for successful inbound 160 communications destined to machines located behind a NAT or a 161 firewall. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 Most of the terms used in this document are introduced in [RFC6887]. 171 PCP Client: A PCP software instance that is responsible for issuing 172 PCP requests to a PCP server. In this document, a PCP client is also 173 a EAP peer [RFC3748], and it is the responsibility of a PCP client to 174 provide the credentials when authentication is required. 176 PCP Server: A PCP software instance that resides on the PCP- 177 Controlled Device that receives PCP requests from the PCP client and 178 creates appropriate state in response to that request. In this 179 document, a PCP server is integrated with an EAP authenticator 180 [RFC3748]. Therefore, when necessary, a PCP server can verify the 181 credentials provided by a PCP client and make an access control 182 decision based on the authentication result. 184 PCP-Authentication (PA) Session: A series of PCP message exchanges 185 transferred between a PCP client and a PCP server. The PCP messages 186 involved within a session includes the PA messages used to perform 187 EAP authentication, key distribution and session management, and the 188 common PCP messages secured with the keys distributed during 189 authentication. Each PA session is assigned a distinctive Session 190 ID. 192 Session Partner: A PCP implementation involved within a PA session. 193 Each PA session has two session partners (a PCP server and a PCP 194 client). 196 PCP device: A PCP client or a PCP server. 198 Session Lifetime: The lifetime associated with a PA session, which 199 decides the lifetime of the current authorization given to the PCP 200 client. 202 PCP Security Association (PCP SA): A PCP security association is 203 formed between a PCP client and a PCP server by sharing cryptographic 204 keying material and associated context. The formed duplex security 205 association is used to protect the bidirectional PCP signaling 206 traffic between the PCP client and PCP server. 208 Master Session Key (MSK): A key derived by the partners of a PA 209 session, using an EAP key generating method (e.g., the one defined in 210 [RFC5448]). 212 PCP-Authentication (PA) message: A PCP message containing an 213 AUTHENTICATION Opcode. Particularly, a PA message sent from a PCP 214 server to a PCP client is referred to as a PA-Server message, while a 215 PA message sent from a PCP client to a PCP server is referred to as a 216 PA-Client message. Therefore, a PA-Server message is actually a PCP 217 response message specified in [RFC6887], and a PA-Client message is a 218 PCP request message. This document specifies an option, the 219 PA_AUTHENTICATION_TAG Option defined in Section 5.5 for PCP 220 authentication, to provide integrity protection and message origin 221 authentication for PA messages. 223 Common PCP message: A PCP message which does not contain an 224 AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG 225 Option to provide integrity protection and message origin 226 authentication for the common PCP messages. 228 3. Protocol Details 230 3.1. Session Initiation 232 At the beginning of a PA session, a PCP client and a PCP server need 233 to exchange a series of PA messages in order to perform an EAP 234 authentication process. Each PA message MUST contain an 235 AUTHENTICATION Opcode and may optionally contain a set of Options for 236 various purposes (e.g., transporting authentication messages and 237 session management). The opcode-specific information in a 238 AUTHENTICATION Opcode consists of two fields : Session ID and 239 Sequence Number. The Session ID field is used to identify the PA 240 session to which the message belongs. The sequence number field is 241 used to detect whether reordering or duplication occurred during 242 message delivery. 244 3.1.1. Authentication triggered by the client 246 When a PCP client intends to proactively initiate a PA session with a 247 PCP server, it sends a PA-Initiation message (a PA-Client message 248 with the result code "INITIATION") to the PCP server. Section 5.1 249 updates the PCP request message format to have a result code. In the 250 message, the Session ID and Sequence Number fields of the 251 AUTHENTICATION Opcode are set as 0. The PA-Client message SHOULD 252 also contain a NONCE option defined in Section 5.3 which consists of 253 a random nonce. 255 After receiving the PA-Initiation, if the PCP server agrees to 256 initiate a PA session with the PCP client, it will reply with a PA- 257 Server message which contains an EAP Identity Request, and the result 258 code field of this PA-Server message is set to 259 AUTHENTICATION_REQUIRED. In addition, the server MUST assign a 260 random session identifier to distinctly identify this session, and 261 fill the identifier into the Session ID field of the AUTHENTICATION 262 Opcode in the PA-Server message. The Sequence Number field of the 263 AUTHENTICATION Opcode is set as 0. If there is a NONCE option in the 264 received PA-Initiation message, the PA-Server message MUST contain a 265 NONCE option so as to send the nonce value back. The nonce will then 266 be used by the PCP client to check the freshness of this message. 267 From now on, every PCP message within this PA session MUST contain 268 this session identifier. When receiving a PA message from an unknown 269 session, a PCP device MUST discard the message silently. 271 PCP PCP 272 client server 273 |-- PA-Initiation-------------------------------->| 274 | (Seq=0, Session ID=0) | 275 | | 276 |<-- PA-Server -----------------------------------| 277 | (Seq=0, Session ID=X, EAP Identity request) | 278 | | 279 |-- PA-Client ----------------------------------->| 280 | (Seq=1, Session ID=X, EAP Identity response) | 281 | | 282 |<-- PA-Server -----------------------------------| 283 | (Seq=1, Session ID=X, EAP Identity request) | 285 3.1.2. Authentication triggered by the server 287 In the scenario where a PCP server receives a common PCP request 288 message from a PCP client which needs to be authenticated, the PCP 289 server can reply with a PA-Server message to initiate a PA session. 290 The result code field of this PA-Server message is set to 291 AUTHENTICATION_REQUIRED. In addition, the PCP server MUST assign a 292 Session ID for the session and transfer it within the PA-Server 293 message. The Sequence Number field in the PA-Server message is set 294 as 0. The PCP client MUST NOT retry the common PCP request until it 295 receives AUTHENTICATION_SUCCEEDED result code from the PCP server. 296 In the PA messages exchanged afterwards in this session, the Session 297 ID will be used in order to help session partners distinguish the 298 messages within this session from those not within. When the PCP 299 client receives this initial PA-Server message from the PCP server, 300 it can reply with a PA-Client message or silently discard the request 301 message according to its local policies. In the PA-Client message, a 302 NONCE option which consists of a random nonce MAY be appended. If 303 so, in the next PA-Server message, the PCP server MUST forward the 304 nonce back within a NONCE option. 306 PCP PCP 307 client server 308 |-- Common PCP request--------------------------->| 309 | | 310 |<-- PA-Server -----------------------------------| 311 | (Seq=0, Session ID=X, EAP Identity request) | 312 | | 313 |-- PA-Client ----------------------------------->| 314 | (Seq=0, Session ID=X, EAP Identity response) | 315 | | 316 |<-- PA-Server -----------------------------------| 317 | (Seq=1, Session ID=X, EAP Identity request) | 319 3.1.3. Authentication using EAP 321 In a PA session, an EAP Identity request message is transported 322 within a PA-Server message, and an EAP Identity response message is 323 transported within a PA-Client message. EAP relies on the underlying 324 protocol to provide reliable transmission; any reordered delivery or 325 loss of packets occurring during transportation must be detected and 326 addressed. Therefore, after sending out a PA-Server message, the PCP 327 server will not send a new PA-Server message until it receives a PA- 328 Client message with a proper sequence number from the PCP client, and 329 vice versa. If a PCP client receives a PA message containing an EAP 330 Identity request and cannot generate an EAP Identity response 331 immediately due to certain reasons (e.g., waiting for human input to 332 construct a EAP message or due to EAP message fragmentation waiting 333 for the additional PA messages in order to construct a complete EAP 334 message), the PCP device MUST reply with a PA-Acknowledgement message 335 (PA message with a RECEIVED_PAK Option) to indicate that the message 336 has been received. This approach not only can avoid unnecessary 337 retransmission of the PA message but also can guarantee the reliable 338 message delivery in conditions where a PCP device needs to receive 339 multiple PA messages carrying the fragmented EAP request before 340 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. If PCP 389 client sends common PCP request without AUTHENTICATION_TAG option 390 then the PCP server rejects the request by returning 391 AUTHENTICATION_REQUIRED result code in the PA-server message. 393 If a PCP client/server cannot authenticate its session partner, the 394 device sends out a PA message with the result code, 395 AUTHENTICATION_FAILED. If the EAP authentication succeeds but 396 authorization fails, the device making the decision sends out a PA 397 message with the result code, AUTHORIZATION_FAILED. In these two 398 cases, after the PA message is sent out, the PA session MUST be 399 terminated immediately. 401 It is possible for independent PCP clients on the host to create 402 multiple PA sessions with the PCP server. It is RECOMMENDED that 403 once a PCP client on the host authenticates with the PCP server any 404 other PCP clients on the host SHOULD be able to reuse the previously 405 negotiated transport key for integrity protection. 407 3.2. Session Termination 409 A PA session can be explicitly terminated by either session partner. 410 A PCP Server may explicitly request termination of the session by 411 sending an unsolicited termination-indicating PA response (a PA 412 response with a result code "SESSION-TERMINATED"). Upon receiving a 413 termination-indicating message, the PCP client MUST respond with a 414 termination-indicating PA message, and SHOULD then remove the 415 associated PA SA. To accommodate packet loss, the PCP server MAY 416 transmit the termination-indicating PA response up to ten times (with 417 an appropriate Epoch Time value in each to reflect the passage of 418 time between transmissions) provided that the interval between the 419 first two notifications is at least 250 ms, and the interval between 420 subsequent notification at least doubles. 422 A PCP client may explicitly request termination of the session by 423 sending a termination-indicating PA request (a PA request with a 424 result code "SESSION-TERMINATED"). After receiving a termination- 425 indicating message from the PCP client, a PCP server MUST respond 426 with a termination-indicating PA response and remove the PA SA 427 immediately. When the PCP client receives the termination-indicating 428 PA response, it MUST remove the associated PA SA immediately. 430 3.3. Session Re-Authentication 432 A session partner may select to perform EAP re-authentication if it 433 would like to update the PCP SA without initiating a new PA session. 434 For example a re-authentication procedure could be triggered for the 435 following reasons: 437 o The session lifetime needs to be extended. 439 o The sequence number is going to reach the maximum value. 440 Specifically, when the sequence number reaches 2**32 - 2**16, the 441 session partner MUST trigger re-authentication. 443 When the PCP server would like to initiate a re-authentication, it 444 sends the PCP client a PA-Server message. The result code of the 445 message is set to "RE-AUTHENTICATION", which indicates the message is 446 for a re-authentication process. If the PCP client would like to 447 start the re-authentication, it will send a PA-Client message to the 448 PCP server, with the result code of the PA-Client message set to "RE- 449 AUTHENTICATION". Then, the session partners exchange PA messages to 450 transfer EAP messages for the re-authentication. During the re- 451 authentication procedure, the session partners protect the integrity 452 of PA messages with the key and MAC algorithm specified in the 453 current PCP SA; the sequence numbers associated with the message will 454 continue to keep increasing according to Section 6.3. The result 455 code for PA-Sever message carrying EAP Identity request will be set 456 to AUTHENTICATION_REQUIRED and PA-Client message carrying EAP 457 Identity response will be set to AUTHENTICATION_REPLY. 459 If the EAP re-authentication succeeds, the result code of the last 460 PA-Server message is "AUTHENTICATION_SUCCEEDED". In this case, 461 before sending out the PA-Server message, the PCP server MUST update 462 the SA and use the new key to generate a digest for the PA-Server 463 message and subsequent PCP messages. In addition, the PA-Server 464 message MAY be appended with a SESSION_LIFETIME Option which 465 indicates the new lifetime of the PA session. PA and PCP message 466 sequence numbers must also be reset to zero. 468 If the EAP authentication fails, the result code of the last PA- 469 Server message is "AUTHENTICATION_FAILED". If the EAP authentication 470 succeeds but authorization fails, the result code of the last PA- 471 Server message is "AUTHORIZATION_FAILED". In the latter two cases, 472 the PA session MUST be terminated immediately after the last PA 473 message exchange. If for some unknown reason re-authentication is 474 not performed and session lifetime has expired then PA session MUST 475 be terminated immediately. 477 During re-authentication, the session partners can also exchange 478 common PCP messages in parallel. The common PCP messages MUST be 479 protected with the current SA until the new SA has been generated. 480 The sequence of EAP messages exchanged for re-authentication will not 481 change, regardless of the PCP device triggering re-authentication. 483 4. PA Security Association 485 At the beginning of a PA session, a session MUST generate a PA SA to 486 maintain its state information during the session. The parameters of 487 a PA SA are listed as follows: 489 o IP address and UDP port number of the PCP client 491 o IP address and UDP port number of the PCP server 493 o Session Identifier 495 o Sequence number for the next outgoing PA message 497 o Sequence number for the next incoming PA message 499 o Sequence number for the next outgoing common PCP message 501 o Sequence number for the next incoming common PCP message 503 o Last outgoing message payload 505 o Retransmission interval 507 o The master session key (MSK) generated by the EAP method. 509 o The MAC algorithm that the transport key should use to generate 510 digests for PCP messages. 512 o The pseudo random function negotiated in the initial PA-Server and 513 PA-Client message exchange for the transport key derivation 515 o The transport key derived from the MSK to provide integrity 516 protection and data origin authentication for the messages in the 517 PA session. The lifetime of the transport key SHOULD be identical 518 to the lifetime of the session. 520 o The nonce selected by the PCP client at the initiation of the 521 session. 523 o The Key ID associated with Transport key. 525 Particularly, the transport key is computed in the following way: 526 Transport key = prf(MSK, "IETF PCP" || Session ID || Nonce || key 527 ID), where: 529 o prf: The pseudo-random function assigned in the Pseudo-random 530 function parameter. 532 o MSK: The master session key generated by the EAP method. 534 o "IETF PCP": The ASCII code representation of the non-NULL 535 terminated string (excluding the double quotes around it). 537 o '||' : is the concatenation operator. 539 o Session ID: The ID of the session which the MSK is derived from. 541 o Nonce: The nonce selected by the client and transported in the 542 Initial PA-Client message. If the PCP client does not select one, 543 this value is set as 0. 545 o Key ID: The ID assigned for the transport key. 547 5. Packet Format 549 5.1. Packet Format of PCP Auth Messages 551 The format of the PA-Server message is identical to the response 552 message format specified in Section 7.2 of [RFC6887]. The result 553 code for PA-Sever message carrying EAP Identity request MUST be set 554 to AUTHENTICATION_REQUIRED. 556 As illustrated in Figure 1, the PA-Client messages use the request 557 header specified in Section 7.1 of[RFC6887]. The only difference is 558 that eight reserved bits are used to transfer the result codes (e.g., 559 "INITIATION", "AUTHENTICATION_FAILED"). Other fields in Figure 1 are 560 described in Section 7.1 of [RFC6887]. The result code for PA-Client 561 message carrying EAP Identity response MUST be set to 562 AUTHENTICATION_REPLY. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Version = 2 |R| Opcode | Reserved | Result Code | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Requested Lifetime (32 bits) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 | PCP Client's IP Address (128 bits) | 573 | | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 : : 577 : Opcode-specific information : 578 : : 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 : : 581 : (optional) PCP Options : 582 : : 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Figure 1. PA-Client message Format 587 The Requested Lifetime field of PA-Client message and Lifetime field 588 of PA-Server message are both set to 0 on transmission and ignored on 589 reception. 591 5.2. Opcode-specific information of AUTHENTICATION Opcode 593 The following diagram shows the format of the Opcode-specific 594 information for the AUTHENTICATION Opcode. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Session ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Sequence Number | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Session ID: This field contains a 32-bit PA session identifier. 606 Sequence Number: This field contains a 32-bit sequence number. A 607 sequence number needs to be incremented on every new (non- 608 retransmission) outgoing PA message in order to provide an 609 ordering guarantee for PA messages. 611 5.3. NONCE Option 613 Because the session identifier of a PA session is determined by the 614 PCP server, a PCP client does not know the session identifier which 615 will be used when it sends out a PA-Initiation message. In order to 616 prevent an attacker from interrupting the authentication process by 617 sending off-line generated PA-Server messages, the PCP client needs 618 to generate a random number as a nonce in the PA-Initiation message. 619 The PCP server will append the nonce within the initial PA-Server 620 message. If the PA-Server message does not carry the correct nonce, 621 the message MUST be discarded silently. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Option Code | Reserved | Option-Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Nonce | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Option Code: TBA-130. 633 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 634 ignored on reception. 636 Option-Length: 4 octets. 638 Nonce: A random 32 bit number which is transported within a PA- 639 Initiation message and the corresponding reply message from the 640 PCP server. 642 5.4. AUTHENTICATION_TAG Option 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Option Code | Reserved | Option-Length | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Session ID | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Sequence Number | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Key ID | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 | Authentication Data (Variable) | 656 ~ ~ 657 | | 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Because there is no authentication Opcode in common PCP messages, the 662 authentication tag for common PCP messages needs to carry the Session 663 ID and Sequence Number. 665 Option Code: TBA-131. 667 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 668 ignored on reception. 670 Option-Length: The length of the AUTHENTICATION_TAG Option for 671 Common PCP message (in octets), including the 12 octet fixed 672 header and the variable length of the authentication data. 674 Session ID: A 32-bit field used to identify the session to which 675 the message belongs and identify the secret key used to create the 676 message digest appended to the PCP message. 678 Sequence Number: A 32-bit sequence number. In this solution, a 679 sequence number needs to be incremented on every new (non- 680 retransmission) outgoing common PCP message in order to provide 681 ordering guarantee for common PCP messages. 683 Key ID: The ID associated with the transport key used to generate 684 authentication data. This field is filled with zero if the MSK is 685 directly used to secure the message. 687 Authentication Data: A variable-length field that carries the 688 Message Authentication Code for the Common PCP message. The 689 generation of the digest varies according to the algorithms 690 specified in different PCP SAs. This field MUST end on a 32-bit 691 boundary, padded with 0's when necessary. 693 5.5. PA_AUTHENTICATION_TAG 695 This option is used to provide message authentication for PA 696 messages. Compared with the AUTHENTICATION_TAG Option for Common PCP 697 Messages, the Session ID field and the Sequence Number field are 698 removed because such information is provided in the AUTHENTICATION 699 Opcode. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Option Code | Reserved | Option-Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Key ID | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | | 709 | Authentication Data (Variable) | 710 ~ ~ 711 | | 712 | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Option Code: TBA-132. 717 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 718 ignored on reception. 720 Option-Length: The length of the PA_AUTHENTICATION Option for PCP 721 Auth message (in octet), including the 4 octet fixed header and 722 the variable length of the authentication data. 724 Key ID: The ID associated with the transport key used to generate 725 authentication data. This field is filled with zero if the MSK is 726 directly used to secure the message. 728 Authentication Data: A variable-length field that carries the 729 Message Authentication Code for the PCP Auth message. The 730 generation of the digest varies according to the algorithms 731 specified in different PCP SAs. This field MUST end on a 32-bit 732 boundary, padded with null characters when necessary. 734 5.6. EAP_PAYLOAD Option 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Option Code | Reserved | Option-Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | | 742 | EAP Message | 743 ~ ~ 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Option Code: TBA-133. 749 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 750 ignored on reception. 752 Option-Length: Variable 754 EAP Message: The EAP message transferred. Note this field MUST 755 end on a 32-bit boundary, padded with 0's when necessary. 757 5.7. PRF Option 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Option Code | Reserved | Option-Length | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | PRF | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Option Code: TBA-134. 769 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 770 ignored on reception. 772 Option-Length: 4 octets. 774 PRF: The Pseudo-Random Function which the sender supports to generate 775 an MSK. This field contains an IKEv2 Transform ID of Transform Type 776 2 [RFC7296][RFC4868]. A PCP implementation MUST support 777 PRF_HMAC_SHA2_256 (5). 779 5.8. MAC_ALGORITHM Option 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Option Code | Reserved | Option-Length | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | MAC Algorithm ID | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Option Code: TBA-135. 791 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 792 ignored on reception. 794 Option-Length: 4 octets. 796 MAC Algorithm ID: Indicate the MAC algorithm which the sender 797 supports to generate authentication data. The MAC Algorithm ID field 798 contains an IKEv2 Transform ID of Transform Type 3 799 [RFC7296][RFC4868]. A PCP implementation MUST support 800 AUTH_HMAC_SHA2_256_128 (12). 802 5.9. SESSION_LIFETIME Option 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Option Code | Reserved | Option-Length | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Session Lifetime | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Option Code: TBA-136. 814 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 815 ignored on reception. 817 Option-Length: 4 octets. 819 Session Lifetime: An unsigned 32-bit integer, in seconds, ranging 820 from 0 to 2^32-1 seconds. The lifetime of the PA Session, which is 821 decided by the authorization result. 823 5.10. RECEIVED_PAK Option 825 This option is used in a PA-Acknowledgement message to indicate that 826 a PA message with the contained sequence number has been received. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Option Code | Reserved | Option-Length | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Received Sequence Number | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Option Code: TBA-137. 838 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 839 ignored on reception. 841 Option-Length: 4 octets. 843 Received Sequence Number: The sequence number of the last received PA 844 message. 846 5.11. ID_INDICATOR Option 848 The ID_INDICATOR option is used by the PCP client to determine which 849 credentials to provide to the PCP server. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Option Code | Reserved | Option-Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 | ID Indicator | 858 ~ ~ 859 | | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Option Code: TBA-138. 864 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 865 ignored on reception. 867 Option-Length: Variable. 869 ID Indicator: The identity of the authority that issued the 870 credentials. The field MUST NOT be null terminated and its length 871 is indicated by the Option-Length field. In particular when a 872 client receives a ID_INDICATOR option, it MUST NOT rely on the 873 presence of a NUL character in the wire format data to identify 874 the end of the ID Indicator field. 876 The field MUST end on a 32-bit boundary, padded with 0's when 877 necessary. The ID indicator field is UTF-8 encoded [RFC3629] 878 Unicode string conforming to the "UsernameCaseMapped" profile of 879 the PRECIS IdentifierClass [I-D.ietf-precis-saslprepbis]. The PCP 880 client validates that the ID indicator field conforms to the 881 "UsernameCaseMapped" profile of the PRECIS IdentifierClass. The 882 PCP client enforces the rules specified in section 3.2.2 of 883 [I-D.ietf-precis-saslprepbis] to map the ID indicator field. The 884 PCP client compares the resulting string with the ID indicators 885 stored locally on the PCP client to pick the credentials for 886 authentication. The two indicator strings are to be considered 887 equivalent by the client if and only if they are an exact octet- 888 for-octet match. 890 6. Processing Rules 892 6.1. Authentication Data Generation 894 If a PCP SA is generated as the result of a successful EAP 895 authentication process, every subsequent PCP message within the 896 session MUST carry an authentication tag which contains the digest of 897 the PCP message for data origin authentication and integrity 898 protection. 900 o Before generating a digest for a PA message, a device needs to 901 first locate the PCP SA according to the session identifier and 902 then get the transport key. Then the device appends an 903 PA_AUTHENTICATION_TAG Option for PCP Auth at the end of the PCP 904 Auth message. The length of the Authentication Data field is 905 decided by the MAC algorithm adopted in the session. The device 906 then fills the Key ID field with the key ID of the transport key, 907 and sets the Authentication Data field to 0. After this, the 908 device generates a digest for the entire PCP message (including 909 the PCP header and PA_AUTHENTICATION_TAG Option) using the 910 transport key and the associated MAC algorithm, and inserts the 911 generated digest into the Authentication Data field. 913 o Similar to generating a digest for a PA message, before generating 914 a digest for a common PCP message, a device needs to first locate 915 the PCP SA according to the session identifier and then get the 916 transport key. Then the device appends the AUTHENTICATION_TAG 917 Option at the end of common PCP message. The length of the 918 Authentication Data field is decided by the MAC algorithm adopted 919 in the session. The device then uses the corresponding values 920 derived from the SA to fill the Session ID field, the Sequence 921 Number field, and the Key ID field, and sets the Authentication 922 Data field to 0. After this, the device generates a digest for 923 the entire PCP message (including the PCP header and 924 AUTHENTICATION_TAG Option) using the transport key and the 925 associated MAC algorithm, and inputs the generated digest into the 926 Authentication Data field. 928 6.2. Authentication Data Validation 930 When a device receives a common PCP message with an 931 AUTHENTICATION_TAG Option for Common PCP Messages, the device needs 932 to use the Session ID transported in the option to locate the proper 933 SA, and then find the associated transport key (using the key ID in 934 the option) and the MAC algorithm. If no proper SA or transport key 935 is found or the sequence number is invalid (see Section 6.5), the PCP 936 message MUST be discarded silently. After storing the value of the 937 Authentication field of the AUTHENTICATION_TAG Option, the device 938 fills the Authentication field with zeros. Then, the device 939 generates a digest for the message (including the PCP header and 940 Authentication Tag Option) with the transport key and the MAC 941 algorithm. If the value of the newly generated digest is identical 942 to the stored one, the device can ensure that the message has not 943 been tampered with, and the validation succeeds. Otherwise, the 944 message MUST be discarded. 946 Similarly, when a device receives a PA message with an 947 PA_AUTHENTICATION_TAG Option for PCP Authentication, the device needs 948 to use the Session ID transported in the Opcode to locate the proper 949 SA, and then find the associated transport key (using the key ID in 950 the option) and the MAC algorithm. If no proper SA or transport key 951 is found or the sequence number is invalid (see Section 6.4), the PCP 952 message MUST be discarded silently. After storing the value of the 953 Authentication field of the PA_AUTHENTICATION_TAG Option, the device 954 fills the Authentication field with zeros. Then, the device 955 generates a digest for the message (including the PCP header and 956 PA_AUTHENTICATION_TAG Option) with the transport key and the MAC 957 algorithm. If the value of the newly generated digest is identical 958 to the stored one, the device can ensure that the message has not 959 been tampered with, and the validation succeeds. Otherwise, the 960 message MUST be discarded. 962 6.3. Retransmission Policies for PA Messages 964 Because EAP relies on the underlying protocols to provide reliable 965 transmission, after sending a PA message, a PCP client/server MUST 966 NOT send out any subsequent messages until receiving a PA message 967 with a proper sequence number from the peer. If no such a message is 968 received the PCP device will re-send the last message according to 969 retransmission policies. This work reuses the retransmission 970 policies specified in the base PCP protocol (Section 8.1.1 of 971 [RFC6887]). In the base PCP protocol, such retransmission policies 972 are only applied by PCP clients. However, in this work, such 973 retransmission policies are also applied by the PCP servers. If 974 Maximum retransmission duration seconds have elapsed and no expected 975 response is received, the device will terminate the session and 976 discard the current SA. 978 As illustrated in Section 3.1.3, in order to avoid unnecessary re- 979 transmission, the device receiving a PA message MUST send a PA- 980 Acknowledgement message to the sender of the PA message when it 981 cannot send a PA response immediately. The PA-Acknowledgement 982 message is used to indicate the receipt of the PA message. When the 983 sender receives the PA-Acknowledgement message, it will stop the 984 retransmission. 986 Note that the last PA messages transported within the phases of 987 session initiation, session re-authentication, and session 988 termination do not have to follow the above policies since the 989 devices sending out those messages do not expect any further PA 990 messages. 992 When a device receives a re-transmitted last incoming PA message from 993 its session partner, it MUST try to answer it by sending the last 994 outgoing PA message again. However, if the duplicate message has the 995 same sequence number but is not bit-wise identical to the original 996 message then the device MUST discard it. In order to achieve this 997 function, the device may need to maintain the last incoming and the 998 associated outgoing messages. In this case, if no outgoing PA 999 message has been generated for the received duplicate PA message yet, 1000 the device needs to send a PA-Acknowledgement message. The rate of 1001 replying to duplicate PA messages MUST be limited to provide 1002 robustness against denial of service (DoS) attacks. The details of 1003 rate limiting are outside the scope of this specification. 1005 6.4. Sequence Numbers for PCP Auth Messages 1007 PCP uses UDP to transport signaling messages. As an un-reliable 1008 transport protocol, UDP does not guarantee ordered packet delivery 1009 and does not provide any protection from packet loss. In order to 1010 ensure the EAP messages are exchanged in a reliable way, every PCP 1011 message exchanged during EAP authentication must carry a 1012 monotonically increasing sequence number. During a PA session, a PCP 1013 device needs to maintain two sequence numbers for PA messages, one 1014 for incoming PA messages and one for outgoing PA messages. When 1015 generating an outgoing PA message, the device adds the associated 1016 outgoing sequence number to the message and increments the sequence 1017 number maintained in the SA by 1. When receiving a PA message from 1018 its session partner, the device will not accept it if the sequence 1019 number carried in the message does not match the incoming sequence 1020 number the device maintains. After confirming that the received 1021 message is valid, the device increments the incoming sequence number 1022 maintained in the SA by 1. 1024 The above rules are not applicable to PA-Acknowledgement messages 1025 (i.e., PA messages containing a RECEIVED_PAK Option). A PA- 1026 Acknowledgement message does not transport any EAP message and only 1027 indicates that a PA message is received. Therefore, reliable 1028 transmission of PA-Acknowledgement messages is not required. For 1029 instance, after sending out a PA-Acknowledgement message, a device 1030 generates an EAP Identity response. In this case, the device need 1031 not have to confirm whether the PA-Acknowledgement message has been 1032 received by its session partner or not. Therefore, when receiving or 1033 sending out a PA-Acknowledgement message, the device MUST NOT 1034 increase the corresponding sequence number stored in the SA. 1035 Otherwise, loss of a PA-Acknowledgement message will cause a mismatch 1036 in sequence numbers. 1038 Another exception is the message retransmission scenario. As 1039 discussed in Section 6.3, when a PCP device does not receive any 1040 response from its session partner it needs to retransmit the last 1041 outgoing PA message following the retransmission procedure specified 1042 in section 8.1.1 of [RFC6887]. The original message and duplicate 1043 messages MUST be bit-wise identical. When the device receives such a 1044 duplicate PA message from its session partner, it MUST send the last 1045 outgoing PA message again. In such cases, the maintained incoming 1046 and outgoing sequence numbers will not be affected by the message 1047 retransmission. 1049 6.5. Sequence Numbers for Common PCP Messages 1051 When transporting common PCP messages within a PA session, a PCP 1052 device needs to maintain a sequence number for outgoing common PCP 1053 messages and a sequence number for incoming common PCP messages. 1054 When generating a new outgoing PCP message, the PCP device updates 1055 the Sequence Number field in the AUTHENTICATION_TAG option with the 1056 outgoing sequence number maintained in the SA and increments the 1057 outgoing sequence number by 1. 1059 When receiving a PCP message from its session partner, the PCP device 1060 will not accept it if the sequence number carried in the message is 1061 smaller than the incoming sequence number the device maintains. This 1062 approach can protect the PCP device from replay attacks. After 1063 confirming that the received message is valid, the PCP device will 1064 update the incoming sequence number maintained in the PCP SA with the 1065 sequence number of the incoming message. 1067 Note that the sequence number in the incoming message may not exactly 1068 match the incoming sequence number maintained locally. As discussed 1069 in the base PCP specification [RFC6887], if a PCP client is no longer 1070 interested in the PCP transaction and has not yet received a PCP 1071 response from the server then it will stop retransmitting the PCP 1072 request. After that, the PCP client might generate new PCP requests 1073 for other purposes using the current SA. In this case, the sequence 1074 number in the new request will be larger than the sequence number in 1075 the old request and so will be larger than the incoming sequence 1076 number maintained in the PCP server. 1078 Note that in the base PCP specification [RFC6887], a PCP client needs 1079 to select a nonce in each MAP or PEER request, and the nonce is sent 1080 back in the response. However, it is possible for a client to use 1081 the same nonce in multiple MAP or PEER requests, and this may cause a 1082 potential risk of replay attacks. This attack is addressed by using 1083 the sequence number in the PCP response. 1085 6.6. MTU Considerations 1087 EAP methods are responsible for MTU handling, so no special 1088 facilities are required in PCP to deal with MTU issues. 1089 Particularly, EAP lower layers indicate to EAP methods and AAA 1090 servers the MTU of the lower layer. EAP methods such as EAP-TLS 1091 [RFC5216], TEAP [RFC7170], and others that are likely to exceed 1092 reasonable MTUs provide support for fragmentation and reassembly. 1093 Others, such as EAP-GPSK [RFC5433] assume they will never send 1094 packets larger than the MTU and use small EAP packets. 1096 If an EAP message is too long to be transported within a single PA 1097 message, it will be divided into multiple sections and sent within 1098 different PA messages. Note that the receiver may not be able to 1099 know what to do in the next step until it has received all the 1100 sections and reconstructed the complete EAP message. In this case, 1101 in order to guarantee reliable message transmission, after receiving 1102 a PA message, the receiver replies with a PA-Acknowledgement message 1103 to notify the sender to send the next PA message. 1105 7. IANA Considerations 1107 The following PCP Opcode is to be allocated in the mandatory-to- 1108 process range from the standards action range (the registry for PCP 1109 Opcodes is maintained in http://www.iana.org/assignments/pcp- 1110 parameters): 1112 TBA AUTHENTICATION Opcode. 1114 The following PCP result codes are to be allocated in the mandatory- 1115 to-process range from the standards action range (the registry for 1116 PCP result codes is maintained in http://www.iana.org/assignments/ 1117 pcp-parameters): 1119 TBA INITIATION: The client indication to the server for 1120 authentication. 1122 TBA AUTHENTICATION_REQUIRED: The server indication to the client 1123 that authentication is required. 1125 TBA AUTHENTICATION_FAILED: This error response is signaled to the 1126 client if EAP authentication had failed. 1128 TBA AUTHENTICATION_SUCCEEDED:This success response is signaled to 1129 the client if EAP authentication had succeeded. 1131 TBA AUTHORIZATION_FAILED: This error response is signaled to the 1132 client if the EAP authentication had succeeded but authorization 1133 failed. 1135 TBA SESSION_TERMINATED: This PCP result code indicates to the 1136 partner that the PA session must be terminated. 1138 TBA DOWNGRADE_ATTACK_DETECTED: This error response is signaled to 1139 the client if the server detects downgrade attack. 1141 TBA AUTHENTICATION_REPLY: The client indication to the server that 1142 EAP response is signaled in the PA message. 1144 The following PCP Option Codes are to be allocated in the mandatory- 1145 to-process range from the standards action range (the registry for 1146 PCP Options is maintained in http://www.iana.org/assignments/pcp- 1147 parameters): 1149 7.1. NONCE 1151 Option Name: NONCE 1153 option-code: TBA-130 in the mandatory-to-process range (IANA). 1155 Purpose: See Section 5.3. 1157 Valid for Opcodes: Authentication Opcode. 1159 option-len: Option Length is 4 octets. 1161 May appear in: request and response. 1163 Maximum occurrences: 1. 1165 7.2. AUTHENTICATION_TAG 1167 Option Name: AUTHENTICATION_TAG 1169 option-code: TBA-131 in the mandatory-to-process range (IANA). 1171 Purpose: See Section 5.4. 1173 Valid for Opcodes: MAP, PEER and ANNOUNCE Opcodes. 1175 option-len: Variable length. 1177 May appear in: request and response. 1179 Maximum occurrences: 1. 1181 7.3. PA_AUTHENTICATION_TAG 1183 Option Name: PA_AUTHENTICATION_TAG 1185 option-code: TBA-132 in the mandatory-to-process range (IANA). 1187 Purpose: See Section 5.5. 1189 Valid for Opcodes: Authentication Opcode. 1191 option-len: Variable length. 1193 May appear in: request and response. 1195 Maximum occurrences: 1. 1197 7.4. EAP_PAYLOAD 1199 Option Name: EAP_PAYLOAD. 1201 option-code: TBA-133 in the mandatory-to-process range (IANA). 1203 Purpose: See Section 5.6. 1205 Valid for Opcodes: Authentication Opcode. 1207 option-len: Variable length. 1209 May appear in: request and response. 1211 Maximum occurrences: 1. 1213 7.5. PRF 1215 Option Name: PRF. 1217 option-code: TBA-134 in the mandatory-to-process range (IANA). 1219 Purpose: See Section 5.7. 1221 Valid for Opcodes: Authentication Opcode. 1223 option-len: Option Length is 4 octets. 1225 May appear in: request and response. 1227 Maximum occurrences: as many as fit within maximum PCP message size. 1229 7.6. MAC_ALGORITHM 1231 Option Name: MAC_ALGORITHM. 1233 option-code: TBA-135 in the mandatory-to-process range (IANA). 1235 Purpose: See Section 5.8. 1237 Valid for Opcodes: Authentication Opcode. 1239 option-len: Option Length is 4 octets. 1241 May appear in: request and response. 1243 Maximum occurrences: as many as fit within maximum PCP message size. 1245 7.7. SESSION_LIFETIME 1247 Option Name: SESSION_LIFETIME. 1249 option-code: TBA-136 in the mandatory-to-process range (IANA). 1251 Purpose: See Section 5.9. 1253 Valid for Opcodes: Authentication Opcode. 1255 option-len: Option Length is 4 octets. 1257 May appear in: response. 1259 Maximum occurrences: 1. 1261 7.8. RECEIVED_PAK 1263 Option Name: RECEIVED_PAK. 1265 option-code: TBA-137 in the mandatory-to-process range (IANA). 1267 Purpose: See Section 5.10. 1269 Valid for Opcodes: Authentication Opcode. 1271 option-len: Option Length is 4 octets. 1273 May appear in: request and response. 1275 Maximum occurrences: 1. 1277 7.9. ID_INDICATOR 1279 Option Name: ID_INDICATOR. 1281 option-code: TBA-138 in the mandatory-to-process range (IANA). 1283 Purpose: See Section 5.11. 1285 Valid for Opcodes: Authentication Opcode. 1287 option-len: Variable length. 1289 May appear in: response. 1291 Maximum occurrences: 1. 1293 8. Security Considerations 1295 In this work, after a successful EAP authentication process is 1296 performed between two PCP devices, an MSK will be exported. The MSK 1297 will be used to derive the transport keys to generate MAC digests for 1298 subsequent PCP message exchanges. However, before a transport key 1299 has been generated, the PA messages exchanged within a PA session 1300 have little cryptographic protection, and if there is no already 1301 established security channel between two session partners, these 1302 messages are subject to man-in-the-middle attacks and DOS attacks. 1303 For instance, the initial PA-Server and PA-Client message exchange is 1304 vulnerable to spoofing attacks as these messages are not 1305 authenticated and integrity protected. In addition, because the PRF 1306 and MAC algorithms are transported at this stage, an attacker may try 1307 to remove the PRF and MAC options containing strong algorithms from 1308 the initial PA-Server message and force the client choose the weakest 1309 algorithms. Therefore, the server needs to guarantee that all the 1310 PRF and MAC algorithms it provides support for are strong enough. 1312 In order to prevent very basic DOS attacks, a PCP device SHOULD 1313 generate state information as little as possible in the initial PA- 1314 Server and PA-Client message exchanges. The choice of EAP method is 1315 also very important. The selected EAP method must be resilient to 1316 the attacks possible in an insecure network environment, provide 1317 user-identity confidentiality, protection against dictionary attacks, 1318 and support session-key establishment. 1320 When a PCP proxy is located between a PCP server and PCP clients, the 1321 proxy may perform authentication with the PCP server before it 1322 processes requests from the clients. In addition, re-authentication 1323 between the PCP proxy and PCP server will not interrupt the service 1324 that the proxy provides to the clients since the proxy is still 1325 allowed to send common PCP messages to the PCP server during that 1326 period. 1328 9. Acknowledgements 1330 Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, 1331 Carlos Pignataro, Brian Haberman, Paul Kyzivat and Jouni Korhonen for 1332 the valuable comments. 1334 10. Change Log 1336 [Note: This section should be removed by the RFC Editor upon 1337 publication] 1339 10.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1340 authentication-00 1342 o Added discussion of in-band and out-of-band key management 1343 options, leaving choice open for later WG decision. 1345 o Removed support for fragmenting EAP messages, as that is handled 1346 by EAP methods. 1348 10.2. Changes from wasserman-pcp-authentication-01 to -02 1350 o Add a nonce into the first two exchanged PCP-Auth message between 1351 the PCP client and PCP server. When a PCP client initiate the 1352 session, it can use the nonce to detect offline attacks. 1354 o Add the key ID field into the authentication tag option so that a 1355 MSK can generate multiple transport keys. 1357 o Specify that when a PCP device receives a PCP-Auth-Server or a 1358 PCP-Auth-Client message from its partner the PCP device needs to 1359 reply with a PCP-Auth-Acknowledge message to indicate that the 1360 message has been received. 1362 o Add the support of fragmenting EAP messages. 1364 10.3. Changes from ietf-pcp-authentication-00 to -01 1366 o Editorial changes, added use cases to introduction. 1368 10.4. Changes from ietf-pcp-authentication-01 to -02 1370 o Add the support of re-authentication initiated by PCP server. 1372 o Specify that when a PCP device receives a PCP-Auth-Server or a 1373 PCP-Auth-Client message from its partner the PCP device MAY reply 1374 with a PCP-Auth-Acknowledge message to indicate that the message 1375 has been received. 1377 o Discuss the format of the PCP-Auth-Acknowledge message. 1379 o Remove the redundant information from the Auth Opcode, and specify 1380 new result codes transported in PCP packet headers 1382 o 1384 10.5. Changes from ietf-pcp-authentication-02 to -03 1386 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1388 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1390 o Specify two new sequence numbers for common PCP messages in the 1391 PCP SA, and describe how to use them 1393 o Specify a Authentication Tag Option for PCP Common Messages 1395 o Introduce the scenario where a EAP message has to be divided into 1396 multiple sections and transported in different PCP-Auth messages 1397 (for the reasons of MTU), and introduce how to use PCP-Auth- 1398 Acknowledge messages to ensure reliable packet delivery in this 1399 case. 1401 10.6. Changes from ietf-pcp-authentication-03 to -04 1403 o Change the name "PCP-Auth" to "PA". 1405 o Refine the retransmission policies. 1407 o Add more discussion about the sequence number management . 1409 o Provide the discussion about how to instruct a PCP client to 1410 choose proper credential during authentication, and an ID 1411 Indicator Option is defined for that purpose. 1413 10.7. Changes from ietf-pcp-authentication-04 to -05 1415 o Add contents in IANA considerations. 1417 o Add discussions in fragmentation. 1419 o Refine the PA messages retransmission policies. 1421 o Add IANA considerations. 1423 10.8. Changes from ietf-pcp-authentication-05 to -06 1425 o Added mechanism to handle algorithm downgrade attack. 1427 o Updated Security Considerations section. 1429 o Updated ID Indicator Option. 1431 11. References 1433 11.1. Normative References 1435 [I-D.ietf-precis-saslprepbis] 1436 Saint-Andre, P. and A. Melnikov, "Preparation, 1437 Enforcement, and Comparison of Internationalized Strings 1438 Representing Usernames and Passwords", draft-ietf-precis- 1439 saslprepbis-18 (work in progress), May 2015. 1441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", BCP 14, RFC 2119, March 1997. 1444 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1445 10646", STD 63, RFC 3629, November 2003. 1447 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1448 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1449 3748, June 2004. 1451 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1452 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1454 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1455 Protocol Tunneled Transport Layer Security Authenticated 1456 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 1458 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1459 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1460 2013. 1462 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1463 "Tunnel Extensible Authentication Protocol (TEAP) Version 1464 1", RFC 7170, May 2014. 1466 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1467 Kivinen, "Internet Key Exchange Protocol Version 2 1468 (IKEv2)", STD 79, RFC 7296, October 2014. 1470 11.2. Informative References 1472 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1473 Authentication Protocol", RFC 5216, March 2008. 1475 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1476 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1477 RFC 5433, February 2009. 1479 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1480 Extensible Authentication Protocol Method for 3rd 1481 Generation Authentication and Key Agreement (EAP-AKA')", 1482 RFC 5448, May 2009. 1484 Authors' Addresses 1486 Margaret Wasserman 1487 Painless Security 1488 356 Abbott Street 1489 North Andover, MA 01845 1490 USA 1492 Phone: +1 781 405 7464 1493 Email: mrw@painless-security.com 1494 URI: http://www.painless-security.com 1495 Sam Hartman 1496 Painless Security 1497 356 Abbott Street 1498 North Andover, MA 01845 1499 USA 1501 Email: hartmans@painless-security.com 1502 URI: http://www.painless-security.com 1504 Dacheng Zhang 1505 Huawei 1506 Beijing 1507 China 1509 Email: zhang_dacheng@hotmail.com 1511 Tirumaleswar Reddy 1512 Cisco Systems, Inc. 1513 Cessna Business Park, Varthur Hobli 1514 Sarjapur Marathalli Outer Ring Road 1515 Bangalore, Karnataka 560103 1516 India 1518 Email: tireddy@cisco.com