idnits 2.17.1 draft-ietf-pcp-authentication-09.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 (May 28, 2015) is 3257 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) == Outdated reference: A later version (-18) exists of draft-ietf-precis-saslprepbis-17 ** Downref: Normative reference to an Informational RFC: RFC 5281 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: November 29, 2015 D. Zhang 6 Huawei 7 T. Reddy 8 Cisco 9 May 28, 2015 11 Port Control Protocol (PCP) Authentication Mechanism 12 draft-ietf-pcp-authentication-09 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 November 29, 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 . . . . . . . 5 67 3.1.2. Authentication triggered by the server . . . . . . . 6 68 3.1.3. Authentication using EAP . . . . . . . . . . . . . . 7 69 3.2. Session Termination . . . . . . . . . . . . . . . . . . . 9 70 3.3. Session Re-Authentication . . . . . . . . . . . . . . . . 9 71 4. PA Security Association . . . . . . . . . . . . . . . . . . . 10 72 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 11 74 5.2. Authentication Opcode . . . . . . . . . . . . . . . . . . 12 75 5.3. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 13 76 5.4. Authentication Tag Option for Common PCP Messages . . . . 13 77 5.5. Authentication Tag Option for PA Messages . . . . . . . . 14 78 5.6. EAP Payload Option . . . . . . . . . . . . . . . . . . . 15 79 5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 15 80 5.8. MAC Algorithm Option . . . . . . . . . . . . . . . . . . 16 81 5.9. Session Lifetime Option . . . . . . . . . . . . . . . . . 16 82 5.10. Received Packet Option . . . . . . . . . . . . . . . . . 16 83 5.11. ID Indicator Option . . . . . . . . . . . . . . . . . . . 17 84 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 18 85 6.1. Authentication Data Generation . . . . . . . . . . . . . 18 86 6.2. Authentication Data Validation . . . . . . . . . . . . . 18 87 6.3. Retransmission Policies for PA Messages . . . . . . . . . 19 88 6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 20 89 6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 21 90 6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 22 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 94 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 10.1. Changes from wasserman-pcp-authentication-02 to ietf- 96 pcp-authentication-00 . . . . . . . . . . . . . . . . . 27 97 10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 27 98 10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 27 99 10.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 27 100 10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 28 101 10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 28 102 10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 28 103 10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 28 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 106 11.2. Informative References . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 109 1. Introduction 111 Using the Port Control Protocol (PCP) [RFC6887], an application can 112 flexibly manage the IP address mapping information on its network 113 address translators (NATs) and firewalls, and control their policies 114 in processing incoming and outgoing IP packets. Because NATs and 115 firewalls both play important roles in network security 116 architectures, there are many situations in which authentication and 117 access control are required to prevent un-authorized users from 118 accessing such devices. This document proposes a PCP security 119 extension which enables PCP servers to authenticate their clients 120 with Extensible Authentication Protocol (EAP). The EAP messages are 121 encapsulated within PCP messages during transportation. 123 The following issues are considered in the design of this extension: 125 o Loss of EAP messages during transportation 127 o Reordered delivery of EAP messages 129 o Generation of transport keys 131 o Integrity protection and data origin authentication for PCP 132 messages 134 o Algorithm agility 136 The mechanism described in this document meets the security 137 requirements to address the Advanced Threat Model described in the 138 base PCP specification [RFC6887]. This mechanism can be used to 139 secure PCP in the following situations: 141 o On security infrastructure equipment, such as corporate firewalls, 142 that do not create implicit mappings for specific traffic. 144 o On equipment (such as CGNs or service provider firewalls) that 145 serve multiple administrative domains and do not have a mechanism 146 to securely partition traffic from those domains. 148 o For any implementation that wants to be more permissive in 149 authorizing applications to create mappings for successful inbound 150 communications destined to machines located behind a NAT or a 151 firewall. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 Most of the terms used in this document are introduced in [RFC6887]. 161 PCP Client: A PCP software instance which is responsible for issuing 162 PCP requests to a PCP server. In this document, a PCP client is also 163 a EAP peer [RFC3748], and it is the responsibility of a PCP client to 164 provide the credentials when authentication is required. 166 PCP Server: A PCP software instance that resides on the PCP- 167 Controlled Device that receives PCP requests from the PCP client and 168 creates appropriate state in response to that request. In this 169 document, a PCP server is integrated with an EAP authenticator 170 [RFC3748]. Therefore, when necessary, a PCP server can verify the 171 credentials provided by a PCP client and make an access control 172 decision based on the authentication result. 174 PCP-Authentication (PA) Session: A series of PCP message exchanges 175 transferred between a PCP client and a PCP server. The PCP messages 176 involved within a session includes the PCP Authentication (PA) 177 messages used to perform EAP authentication, key distribution and 178 session management, and the common PCP messages secured with the keys 179 distributed during authentication. Each PA session is assigned a 180 distinctive Session ID. 182 Session Partner: A PCP implementation involved within a PA session. 183 Each PA session has two session partners (a PCP server and a PCP 184 client). 186 Session Lifetime: The lifetime associated with a PA session, which 187 decides the lifetime of the current authorization given to the PCP 188 client. 190 PCP Security Association (PCP SA): A PCP security association is 191 formed between a PCP client and a PCP server by sharing cryptographic 192 keying material and associated context. The formed duplex security 193 association is used to protect the bidirectional PCP signaling 194 traffic between the PCP client and PCP server. 196 Master Session Key (MSK): A key derived by the partners of a PA 197 session, using an EAP key generating method (e.g., the one defined in 198 [RFC5448]). 200 PCP-Authentication (PA) message: A PCP message containing an 201 Authentication Opcode. Particularly, a PA message sent from a PCP 202 server to a PCP client is referred to as a PA-Server, while a PA 203 message sent from a PCP client to a PCP server is referred to as a 204 PA-Client. Therefore, a PA-Server is actually a PCP response message 205 specified in [RFC6887], and a PA-Client is a PCP request message. 206 This document specifies an option, the Authentication Tag Option 207 defined in Section 5.4 for PCP authentication, to provide integrity 208 protection and message origin authentication for PA messages. 210 Common PCP message: A PCP message which does not contain an 211 Authentication Opcode. This document specifies an Authentication Tag 212 Option to provide integrity protection and message origin 213 authentication for the common PCP messages. 215 3. Protocol Details 217 3.1. Session Initiation 219 At the beginning of a PA session, a PCP client and a PCP server need 220 to exchange a series of PA messages in order to perform an EAP 221 authentication process. Each PA message is attached with an 222 Authentication Opcode and may optionally contain a set of Options for 223 various purposes (e.g., transporting authentication messages and 224 session management). The Authentication Opcode consists of two 225 fields: Session ID and Sequence Number. The Session ID field is used 226 to identify the PA session to which the message belongs. The 227 sequence number field is used to detect whether reordering or 228 duplication occurred during message delivery. 230 3.1.1. Authentication triggered by the client 232 When a PCP client intends to proactively initiate a PA session with a 233 PCP server, it sends a PA-Initiation message (a PA-Client message 234 with the result code "INITIATION") to the PCP server. Section 5.1 235 updates the PCP request message format to have a result code. In the 236 message, the Session ID and Sequence Number fields of the 237 Authentication Opcode are set as 0. The PCP client SHOULD also 238 append a nonce option defined in Section 5.3 which consists of a 239 random nonce with the message. 241 After receiving the PA-Initiation, if the PCP server agrees to 242 initiate a PA session with the PCP client, it will reply with a PA- 243 Server message which contains an EAP Identity Request, and the result 244 code field of this PA-Server message is set to AUTHENTICATION- 245 REQUIRED. In addition, the server MUST assign a random session 246 identifier to distinctly identify this session, and fill the 247 identifier into the Session ID field of the Authentication Opcode in 248 the PA-Server message. The Sequence Number field of the 249 Authentication Opcode is set as 0. If there is a nonce option in the 250 received PA-Initiation message, the PA-Server message MUST be 251 attached with a nonce option so as to send the nonce value back. The 252 nonce will then be used by the PCP client to check the freshness of 253 this message. From now on, every PCP message within this session 254 will be attached with this session identifier. When receiving a PA 255 message from an unknown session, a PCP device MUST discard the 256 message silently. If the PCP client intends to simplify the 257 authentication process, it MAY append an EAP Identity Response 258 message within the PA-Initiation message so as to inform the PCP 259 server that it would like to perform EAP authentication and skip the 260 step of waiting for the EAP Identity Request. 262 PCP PCP 263 client server 264 |-- PA-Initiation-------------------------------->| 265 | (Seq=0, Session-ID=0) | 266 | | 267 |<-- PA-Server -----------------------------------| 268 | (Seq=0, Session-ID=X, EAP request) | 269 | | 270 |-- PA-Client ----------------------------------->| 271 | (Seq=1, Session-ID=X, EAP response) | 272 | | 273 |<-- PA-Server -----------------------------------| 274 | (Seq=1, Session-ID=X, EAP request) | 276 3.1.2. Authentication triggered by the server 278 In the scenario where a PCP server receives a common PCP request 279 message from a PCP client which needs to be authenticated, the PCP 280 server can reply with a PA-Server message to initiate a PA session. 281 The result code field of this PA-Server message is set to 282 AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a 283 session ID for the session and transfer it within the PA-Server 284 message. The Sequence Number field in the PA-Server is set as 0. In 285 the PA messages exchanged afterwards in this session, the session ID 286 will be used in order to help session partners distinguish the 287 messages within this session from those not within. When the PCP 288 client receives this initial PA-Server message from the PCP server, 289 it can reply with a PA-Client message or silently discard the request 290 message according to its local policies. In the PA-Client message, a 291 nonce option which consists of a random nonce MAY be appended. If 292 so, in the next PA-Server message, the PCP server MUST forward the 293 nonce back within a nonce option. 295 PCP PCP 296 client server 297 |-- Common PCP request--------------------------->| 298 | | 299 |<-- PA-Server -----------------------------------| 300 | (Seq=0, Session-ID=X, EAP request) | 301 | | 302 |-- PA-Client ----------------------------------->| 303 | (Seq=0, Session-ID=X, EAP response) | 304 | | 305 |<-- PA-Server -----------------------------------| 306 | (Seq=1, Session-ID=X, EAP request) | 308 3.1.3. Authentication using EAP 310 In a PA session, an EAP request message is transported within a PA- 311 Server message, and an EAP response message is transported within a 312 PA-Client message. EAP relies on the underlying protocol to provide 313 reliable transmission; any reordered delivery or loss of packets 314 occurring during transportation must be detected and addressed. 315 Therefore, after sending out a PA-Server message, the PCP server will 316 not send a new PA-Server message until it receives a PA-Client 317 message with a proper sequence number from the PCP client, and vice 318 versa. If a PCP device receives a PA message from its partner and 319 cannot generate an EAP response immediately due to certain reasons 320 (e.g., waiting for human input to construct a EAP message or waiting 321 for the additional PA messages in order to construct a complete EAP 322 message), the PCP device MUST reply with a PA-Acknowledgement message 323 (PA message with a Received Packet Option) to indicate that the 324 message has been received. This approach not only can avoid 325 unnecessary retransmission of the PA message but also can guarantee 326 the reliable message delivery in the conditions where a PCP device 327 needs to receive multiple PA messages before generating an EAP 328 response. 330 In this approach, it is mandated for a PCP client and a PCP server to 331 perform a key-generating EAP method in authentication. Particularly, 332 a PCP authentication implementation MUST support EAP-TTLS [RFC5281] 333 and SHOULD support TEAP [RFC7170]. Therefore, after a successful 334 authentication procedure, a Master Session Key (MSK) will be 335 generated. If the PCP client and the PCP server want to generate a 336 transport key using the MSK, they need to agree upon a Pseudo-Random 337 Function (PRF) for the transport key derivation and a MAC algorithm 338 to provide data origin authentication for subsequent PCP messages. 339 In order to do this, the PCP server needs to append a set of PRF 340 Options and MAC Algorithm Options to the initial PA-Server message. 341 Each PRF Option contains a PRF that the PCP server supports, and each 342 MAC Algorithm Option contains a MAC (Message Authentication Code) 343 algorithm that the PCP server supports. Moreover, in the first PA- 344 Server message, the server MAY also attach an ID Indicator Option 345 defined in Section 5.11 to direct the client to choose correct 346 credentials. After receiving the options, the PCP client selects the 347 PRF and the MAC algorithm which it would like to use, and then adds 348 the associated PRF and MAC Algorithm Options to the next PA-Client 349 message. 351 After the EAP authentication, the PCP server sends out a PA-Server 352 message to indicate the EAP authentication and PCP authorization 353 results. If the EAP authentication succeeds, the result code of the 354 PA-Server message is AUTHENTICATION-SUCCEEDED. In this case, before 355 sending out the PA-Server message, the PCP server MUST generate a PCP 356 SA and use the derived transport key to generate a digest for the 357 message. The digest is transported within an Authentication Tag 358 Option for PCP Auth. A more detailed description of generating the 359 authentication data can be found in Section 6.1. In addition, the 360 PA-Server MAY also contain a Session Lifetime Option defined in 361 Section 5.9 which indicates the lifetime of the PA session (i.e., the 362 lifetime of the MSK). After receiving the PA-Server message, the PCP 363 client then needs to generate a PA-Client message as response. If 364 the PCP client also authenticates the PCP server, the result code of 365 the PA-Client is AUTHENTICATION-SUCCEEDED. In addition, the PCP 366 client needs to generate a PCP SA and uses the derived transport key 367 to secure the message. From then on, all the PCP messages within the 368 session are secured with the transport key and the MAC algorithm 369 specified in the PCP SA, unless a re-authentication is performed. 370 The first secure PA-client response from the client MUST include the 371 set of PRF and MAC Algorithm options received from the PCP server. 372 The PCP server determines if the set of algorithms conveyed by the 373 client matches the set it had initially sent, to detect an algorithm 374 downgrade attack. If the server detects a downgrade attack then it 375 MUST send a PA-Server message with result code DOWNGRADE-ATTACK- 376 DETECTED and terminate the session. 378 If a PCP client/server cannot authenticate its session partner, the 379 device sends out a PA message with the result code, AUTHENTICATION- 380 FAILED. If the EAP authentication succeeds but authorization fails, 381 the device making the decision sends out a PA message with the result 382 code, AUTHORIZATION-FAILED. In these two cases, after the PA message 383 is sent out, the PA session MUST be terminated immediately. 385 3.2. Session Termination 387 A PA session can be explicitly terminated by sending a termination- 388 indicating PA message (a PA message with a result code "SESSION- 389 TERMINATED" ) from either session partner. After receiving a 390 Termination-Indicating message from the session partner, a PCP device 391 MUST respond with a Termination-Indicating PA message and remove the 392 PA SA immediately. When the session partner initiating the 393 termination process receives the PA message, it will remove the 394 associated PA SA immediately. 396 3.3. Session Re-Authentication 398 A session partner may select to perform EAP re-authentication if it 399 would like to update the PCP SA without initiating a new PA session. 400 A re-authentication procedure could be triggered for the following 401 reasons: 403 o The session lifetime needs to be extended. 405 o The sequence number is going to reach the maximum value. 406 Specifically, when the sequence number reaches 2**32 - 2**16, the 407 session partner MUST trigger re-authentication. 409 When the PCP server would like to initiate a re-authentication, it 410 sends the PCP client a PA-Server message. The result code of the 411 message is set to "RE-AUTHENTICATION", which indicates the message is 412 for a re-authentication process. If the PCP client would like to 413 start the re-authentication, it will send a PA-Client message to the 414 PCP server, with the result code of the PA-Client message set to "RE- 415 AUTHENTICATION". Then, the session partners exchange PA messages to 416 transfer EAP messages for the re-authentication. During the re- 417 authentication procedure, the session partners protect the integrity 418 of PA messages with the key and MAC algorithm specified in the 419 current PCP SA; the sequence numbers associated with the message will 420 continue to keep increasing according to Section 6.3. 422 If the EAP re-authentication succeeds, the result code of the last 423 PA-Server is "AUTHENTICATION-SUCCEEDED". In this case, before 424 sending out the PA-Server message, the PCP server MUST update the SA 425 and use the new key to generate a digest for the PA-Server and 426 subsequent PCP messages. In addition, the PA-Server message MAY be 427 appended with a Session Lifetime Option which indicates the new 428 lifetime of the PA session. PA and PCP message sequence numbers must 429 also be reset to zero. 431 If the EAP authentication fails, the result code of the last PA- 432 Server is "AUTHENTICATION-FAILED". If the EAP authentication 433 succeeds but authorization fails, the result code of the last PA- 434 Server is "AUTHORIZATION-FAILED". In the latter two cases, the PA 435 session MUST be terminated immediately after the last PA message 436 exchange. 438 During re-authentication, the session partners can also exchange 439 common PCP messages in parallel. The common PCP messages MUST be 440 protected with the current SA until the new SA has been generated. 442 4. PA Security Association 444 At the beginning of a PA session, a session SHOULD generate a PA SA 445 to maintain its state information during the session. The parameters 446 of a PA SA are listed as follows: 448 o IP address and UDP port number of the PCP client 450 o IP address and UDP port number of the PCP server 452 o Session Identifier 454 o Sequence number for the next outgoing PA message 456 o Sequence number for the next incoming PA message 458 o Sequence number for the next outgoing common PCP message 460 o Sequence number for the next incoming common PCP message 462 o Last outgoing message payload 464 o Retransmission interval 466 o The master session key (MSK) generated by the EAP method. 468 o The MAC algorithm that the transport key should use to generate 469 digests for PCP messages. 471 o The pseudo random function negotiated in the initial PA-Server and 472 PA-Client exchange for the transport key derivation 474 o The transport key derived from the MSK to provide integrity 475 protection and data origin authentication for the messages in the 476 PA session. The lifetime of the transport key SHOULD be identical 477 to the lifetime of the session. 479 o The nonce selected by the PCP client at the initiation of the 480 session. 482 o The Key ID associated with Transport key. 484 Particularly, the transport key is computed in the following way: 485 Transport key = prf(MSK, "IETF PCP" || Session_ID || Nonce || key 486 ID), where: 488 o prf: The pseudo-random function assigned in the Pseudo-random 489 function parameter. 491 o MSK: The master session key generated by the EAP method. 493 o "IETF PCP": The ASCII code representation of the non-NULL 494 terminated string (excluding the double quotes around it). 496 o '||' : is the concatenation operator. 498 o Session_ID: The ID of the session which the MSK is derived from. 500 o Nonce: The nonce selected by the client and transported in the 501 Initial PA-Client message. If the PCP client does not select one, 502 this value is set as 0. 504 o Key ID: The ID assigned for the transport key. 506 5. Packet Format 508 5.1. Packet Format of PCP Auth Messages 510 The format of the PA-Server message is identical to the response 511 message format specified in Section 7.2 of [RFC6887]. 513 As illustrated in Figure 1, the PA-Client messages use the request 514 header specified in Section 7.1 of[RFC6887]. The only difference is 515 that eight reserved bits are used to transfer the result codes (e.g., 516 "INITIATION", "AUTHENTICATION-FAILED"). Other fields in Figure 1 are 517 described in Section 7.1 of [RFC6887]. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Version = 2 |R| Opcode | Reserved | Result Code | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Requested Lifetime (32 bits) | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 | PCP Client's IP Address (128 bits) | 528 | | 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 : : 532 : Opcode-specific information : 533 : : 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 : : 536 : (optional) PCP Options : 537 : : 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 1. PA-Client message Format 542 5.2. Authentication Opcode 544 The following figure illustrates the format of an authentication 545 Opcode: 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Session ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Sequence Number | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Session ID: This field contains a 32-bit PA session identifier. 557 Sequence Number: This field contains a 32-bit sequence number. A 558 sequence number needs to be incremented on every new (non- 559 retransmission) outgoing message in order to provide an ordering 560 guarantee for PCP messages. 562 5.3. Nonce Option 564 Because the session identifier of a PA session is determined by the 565 PCP server, a PCP client does not know the session identifier which 566 will be used when it sends out a PA-Initiation message. In order to 567 prevent an attacker from interrupting the authentication process by 568 sending off-line generated PA-Server messages, the PCP client needs 569 to generate a random number as a nonce in the PA-Initiation message. 570 The PCP server will append the nonce within the initial PA-Server 571 message. If the PA-Server message does not carry the correct nonce, 572 the message will be discarded silently. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Option Code | Reserved | Option-Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Nonce | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Option-Length: The length of the Nonce Option (in octets), 583 including the 4 octet fixed header and the variable length of the 584 authentication data. 586 Nonce: A random 32 bit number which is transported within a PA- 587 Initiation message and the corresponding reply message from the 588 PCP server. 590 5.4. Authentication Tag Option for Common PCP Messages 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 | Session ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Sequence Number | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Key ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 | Authentication Data (Variable) | 605 ~ ~ 606 | | 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Because there is no authentication Opcode in common PCP messages, the 611 authentication tag for common PCP messages needs to carry the session 612 ID and sequence number. 614 Option-Length: The length of the Authentication Tag Option for 615 Common PCP (in octets), including the 12 octet fixed header and 616 the variable length of the authentication data. 618 Session ID: A 32-bit field used to identify the session to which 619 the message belongs and identify the secret key used to create the 620 message digest appended to the PCP message. 622 Sequence Number: A 32-bit sequence number. In this solution, a 623 sequence number needs to be incremented on every new (non- 624 retransmission) outgoing message in order to provide ordering 625 guarantee for common PCP messages. 627 Key ID: The ID associated with the transport key used to generate 628 authentication data. This field is filled with zero if the MSK is 629 directly used to secure the message. 631 Authentication Data: A variable-length field that carries the 632 Message Authentication Code for the PCP message. The generation 633 of the digest varies according to the algorithms specified in 634 different PCP SAs. This field MUST end on a 32-bit boundary, 635 padded with 0's when necessary. 637 5.5. Authentication Tag Option for PA Messages 639 This option is used to provide message authentication for PA 640 messages. Compared with the Authentication Tag Option for Common PCP 641 Messages, the session ID field and the sequence number field are 642 removed because such information is provided in the Authentication 643 Opcode. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Option Code | Reserved | Option-Length | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Key ID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | | 653 | Authentication Data (Variable) | 654 ~ ~ 655 | | 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Option-Length: The length of the Authentication Tag Option for PCP 660 Auth (in octet), including the 12 octet fixed header and the 661 variable length of the authentication data. 663 Key ID: The ID associated with the transport key used to generate 664 authentication data. This field is filled with zero if the MSK is 665 directly used to secure the message. 667 Authentication Data: A variable-length field that carries the 668 Message Authentication Code for the PCP message. The generation 669 of the digest varies according to the algorithms specified in 670 different PCP SAs. This field MUST end on a 32-bit boundary, 671 padded with null characters when necessary. 673 5.6. EAP Payload Option 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Option Code | Reserved | Option-Length | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | | 681 | EAP Message | 682 ~ ~ 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Option-Length: The length of the EAP Payload Option (in octets), 687 including the 4 octet fixed header and the variable length of the 688 EAP message. 690 EAP Message: The EAP message transferred. Note this field MUST 691 end on a 32-bit boundary, padded with 0's when necessary. 693 5.7. PRF Option 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Option Code | Reserved | Option-Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | PRF | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Option-Length: The length of the PRF Option (in octets), including 704 the 4 octet fixed header and the variable length of the EAP message. 706 PRF: The Pseudo-Random Function which the sender supports to generate 707 an MSK. This field contains an IKEv2 Transform ID of Transform Type 708 2 [RFC5996][RFC4868]. A PCP implementation MUST support 709 PRF_HMAC_SHA2_256 (5). 711 5.8. MAC Algorithm Option 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Option Code | Reserved | Option-Length | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | MAC Algorithm ID | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Option-Length: The length of the MAC Algorithm Option (in octets), 722 including the 4 octet fixed header and the variable length of the EAP 723 message. 725 MAC Algorithm ID: Indicate the MAC algorithm which the sender 726 supports to generate authentication data. The MAC Algorithm ID field 727 contains an IKEv2 Transform ID of Transform Type 3 728 [RFC5996][RFC4868]. A PCP implementation MUST support 729 AUTH_HMAC_SHA2_256_128 (12). 731 5.9. Session Lifetime Option 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Option Code | Reserved | Option-Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Session Lifetime | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Option-Length: The length of the Session Lifetime Option (in octets), 742 including the 4 octet fixed header and the variable length of the EAP 743 message. 745 Session Lifetime: The lifetime of the PA Session, which is decided by 746 the authorization result. 748 5.10. Received Packet Option 750 This option is used in a PA-Acknowledgement message to indicate that 751 a message with the contained sequence number has been received. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Option Code | Reserved | Option-Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Received Sequence Number | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Option-Length: The length of the Received Packet Option (in octets), 762 including the 4 octet fixed header and the variable length of the EAP 763 message. 765 Received Sequence Number: The sequence number of the last received 766 PCP message. 768 5.11. ID Indicator Option 770 The ID Indicator option is used by the PCP client to determine which 771 credentials to provide to the PCP server. 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Option Code | Reserved | Option-Length | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | 779 | ID Indicator | 780 ~ ~ 781 | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Option-Length: The length of the ID Indicator Option (in octets), 785 including the 4 octet fixed header and the variable length of the 786 EAP message. 788 ID Indicator: The identity of the authority that issued the 789 credentials. The field MUST end on a 32-bit boundary, padded with 790 0's when necessary. The ID indicator field is UTF-8 encoded 791 [RFC3629] Unicode string conforming to the "UsernameCaseMapped" 792 profile of the PRECIS IdentifierClass 793 [I-D.ietf-precis-saslprepbis]. The PCP client validates that the 794 ID indicator field conforms to the "UsernameCaseMapped" profile of 795 the PRECIS IdentifierClass. The PCP client enforces the rules 796 specified in section 3.2.2 of [I-D.ietf-precis-saslprepbis] to map 797 the ID indicator field. The PCP client compares the resulting 798 string with the ID indicators stored locally on the PCP client to 799 pick the credentials for authentication. The two indicator 800 strings are to be considered equivalent by the client if they are 801 an exact octet-for-octet match. 803 6. Processing Rules 805 6.1. Authentication Data Generation 807 If a PCP SA is generated as the result of a successful EAP 808 authentication process, every subsequent PCP message within the 809 session MUST carry an Authentication Tag Option which contains the 810 digest of the PCP message for data origin authentication and 811 integrity protection. 813 o Before generating a digest for a PA message, a device needs to 814 first locate the PCP SA according to the session identifier and 815 then get the transport key. Then the device appends an 816 Authentication Tag Option for PCP Auth at the end of the PCP Auth 817 message. The length of the Authentication Data field is decided 818 by the MAC algorithm adopted in the session. The device then 819 fills the Key ID field with the key ID of the transport key, and 820 sets the Authentication Data field to 0. After this, the device 821 generates a digest for the entire PCP message (including the PCP 822 header and Authentication Tag Option) using the transport key and 823 the associated MAC algorithm, and inserts the generated digest 824 into the Authentication Data field. 826 o Similar to generating a digest for a PA message, before generating 827 a digest for a common PCP message, a device needs to first locate 828 the PCP SA according to the session identifier and then get the 829 transport key. Then the device appends the Authentication Tag 830 Option at the end of common PCP message. The length of the 831 Authentication Data field is decided by the MAC algorithm adopted 832 in the session. The device then uses the corresponding values 833 derived from the SA to fill the Session ID field, the Sequence 834 Number field, and the Key ID field, and sets the Authentication 835 Data field to 0. After this, the device generates a digest for 836 the entire PCP message (including the PCP header and 837 Authentication Tag Option) using the transport key and the 838 associated MAC algorithm, and inputs the generated digest into the 839 Authentication Data field. 841 6.2. Authentication Data Validation 843 When a device receives a common PCP message with an Authentication 844 Tag Option for Common PCP Messages, the device needs to use the 845 session ID transported in the option to locate the proper SA, and 846 then find the associated transport key (using the key ID in the 847 option) and the MAC algorithm. If no proper SA or transport key is 848 found or the sequence number is invalid (see Section 6.5), the PCP 849 message MUST be discarded silently. After storing the value of the 850 Authentication field of the Authentication Tag Option, the device 851 fills the Authentication field with zeros. Then, the device 852 generates a digest for the message (including the PCP header and 853 Authentication Tag Option) with the transport key and the MAC 854 algorithm. If the value of the newly generated digest is identical 855 to the stored one, the device can ensure that the message has not 856 been tampered with, and the validation succeeds. Otherwise, the 857 message MUST be discarded. 859 Similarly, when a device receives a PA message with an Authentication 860 Tag Option for PCP Authentication, the device needs to use the 861 session ID transported in the opcode to locate the proper SA, and 862 then find the associated transport key (using the key ID in the 863 option) and the MAC algorithm. If no proper SA or transport key is 864 found or the sequence number is invalid (see Section 6.4), the PCP 865 message MUST be discarded silently. After storing the value of the 866 Authentication field of the Authentication Tag Option, the device 867 fills the Authentication field with zeros. Then, the device 868 generates a digest for the message (including the PCP header and 869 Authentication Tag Option) with the transport key and the MAC 870 algorithm. If the value of the newly generated digest is identical 871 to the stored one, the device can ensure that the message has not 872 been tampered with, and the validation succeeds. Otherwise, the 873 message MUST be discarded. 875 6.3. Retransmission Policies for PA Messages 877 Because EAP relies on the underlying protocols to provide reliable 878 transmission, after sending a PA message, a PCP client/server MUST 879 NOT send out any subsequent messages until receiving a PA message 880 with a proper sequence number from the peer. If no such a message is 881 received the PCP device will re-send the last message according to 882 retransmission policies. This work reuses the retransmission 883 policies specified in the base PCP protocol (Section 8.1.1 of 884 [RFC6887]). In the base PCP protocol, such retransmission policies 885 are only applied by PCP clients. However, in this work, such 886 retransmission policies are also applied by the PCP servers. If 887 Maximum retransmission duration seconds have elapsed and no expected 888 response is received, the device will terminate the session and 889 discard the current SA. 891 As illustrated in Section 3.1.3, in order to avoid unnecessary re- 892 transmission, the device receiving a PA message MUST send a PA- 893 Acknowledgement message to the sender of the PA message when it 894 cannot send a PA response immediately. The PA-Acknowledgement 895 message is used to indicate the receipt of the PA message. When the 896 sender receives the PA-Acknowledgement message, it will stop the 897 retransmission. 899 Note that the last PA messages transported within the phases of 900 session initiation, session re-authentication, and session 901 termination do not have to follow the above policies since the 902 devices sending out those messages do not expect any further PA 903 messages. 905 When a device receives a re-transmitted last incoming PA message from 906 its session partner, it MUST try to answer it by sending the last 907 outgoing PA message again. However, if the duplicate message has the 908 same sequence number but is not bit-wise identical to the original 909 message then the device MUST discard it. In order to achieve this 910 function, the device may need to maintain the last incoming and the 911 associated outgoing messages. In this case, if no outgoing PA 912 message has been generated for the received duplicate PA message yet, 913 the device needs to send a PA-Acknowledgement message. The rate of 914 replying to duplicate PA messages MUST be limited to provide 915 robustness against denial of service (DoS) attacks. The details of 916 rate limiting are outside the scope of this specification. 918 6.4. Sequence Numbers for PCP Auth Messages 920 PCP uses UDP to transport signaling messages. As an un-reliable 921 transport protocol, UDP does not guarantee ordered packet delivery 922 and does not provide any protection from packet loss. In order to 923 ensure the EAP messages are exchanged in a reliable way, every PCP 924 message exchanged during EAP authentication must carry a 925 monotonically increasing sequence number. During a PA session, a PCP 926 device needs to maintain two sequence numbers for PA messages, one 927 for incoming PA messages and one for outgoing PA messages. When 928 generating an outgoing PA message, the device adds the associated 929 outgoing sequence number to the message and increments the sequence 930 number maintained in the SA by 1. When receiving a PA message from 931 its session partner, the device will not accept it if the sequence 932 number carried in the message does not match the incoming sequence 933 number the device maintains. After confirming that the received 934 message is valid, the device increments the incoming sequence number 935 maintained in the SA by 1. 937 The above rules are not applicable to PA-Acknowledgement messages 938 (i.e., PA messages containing a Received Packet Option). A PA- 939 Acknowledgement message does not transport any EAP message and only 940 indicates that a PA message is received. Therefore, reliable 941 transmission of PA-Acknowledgement messages is not required. For 942 instance, after sending out a PA-Acknowledgement message, a device 943 generates an EAP response. In this case, the device need not have to 944 confirm whether the PA-Acknowledgement message has been received by 945 its session partner or not. Therefore, when receiving or sending out 946 a PA-Acknowledgement message, the device MUST NOT increase the 947 corresponding sequence number stored in the SA. Otherwise, loss of a 948 PA-Acknowledgement message will cause a mismatch in sequence numbers. 950 Another exception is the message retransmission scenario. As 951 discussed in Section 6.3, when a PCP device does not receive any 952 response from its session partner it needs to retransmit the last 953 outgoing PA message following the retransmission procedure specified 954 in section 8.1.1 of [RFC6887]. The original message and duplicate 955 messages MUST be bit-wise identical. When the device receives such a 956 duplicate PA message from its session partner, it MUST send the last 957 outgoing PA message again. In such cases, the maintained incoming 958 and outgoing sequence numbers will not be affected by the message 959 retransmission. 961 6.5. Sequence Numbers for Common PCP Messages 963 When transporting common PCP messages within a PA session, a PCP 964 device needs to maintain a sequence number for outgoing common PCP 965 messages and a sequence number for incoming common PCP messages. 966 When generating a new outgoing PCP message, the PCP device updates 967 the Sequence Number field in the Authentication tag option with the 968 outgoing sequence number maintained in the SA and increments the 969 outgoing sequence number by 1. 971 When receiving a PCP message from its session partner, the PCP device 972 will not accept it if the sequence number carried in the message is 973 smaller than the incoming sequence number the device maintains. This 974 approach can protect the PCP device from replay attacks. After 975 confirming that the received message is valid, the PCP device will 976 update the incoming sequence number maintained in the PCP SA with the 977 sequence number of the incoming message. 979 Note that the sequence number in the incoming message may not exactly 980 match the incoming sequence number maintained locally. As discussed 981 in the base PCP specification [RFC6887], if a PCP client is no longer 982 interested in the PCP transaction and has not yet received a PCP 983 response from the server then it will stop retransmitting the PCP 984 request. After that, the PCP client might generate new PCP requests 985 for other purposes using the current SA. In this case, the sequence 986 number in the new request will be larger than the sequence number in 987 the old request and so will be larger than the incoming sequence 988 number maintained in the PCP server. 990 Note that in the base PCP specification [RFC6887], a PCP client needs 991 to select a nonce in each MAP or PEER request, and the nonce is sent 992 back in the response. However, it is possible for a client to use 993 the same nonce in multiple MAP or PEER requests, and this may cause a 994 potential risk of replay attacks. This attack is addressed by using 995 the sequence number in the PCP response. 997 6.6. MTU Considerations 999 EAP methods are responsible for MTU handling, so no special 1000 facilities are required in PCP to deal with MTU issues. 1001 Particularly, EAP lower layers indicate to EAP methods and AAA 1002 servers the MTU of the lower layer. EAP methods such as EAP-TLS 1003 [RFC5216], TEAP [RFC7170], and others that are likely to exceed 1004 reasonable MTUs provide support for fragmentation and reassembly. 1005 Others, such as EAP-GPSK [RFC5433] assume they will never send 1006 packets larger than the MTU and use small EAP packets. 1008 If an EAP message is too long to be transported within a single PA 1009 message, it will be divided into multiple sections and sent within 1010 different PA messages. Note that the receiver may not be able to 1011 know what to do in the next step until it has received all the 1012 sections and reconstructed the complete EAP message. In this case, 1013 in order to guarantee reliable message transmission, after receiving 1014 a PA message, the receiver replies with a PA-Acknowledgement message 1015 to notify the sender to send the next PA message. 1017 7. IANA Considerations 1019 The following PCP Opcode is to be allocated in the mandatory-to- 1020 process range from the standards action range (the registry for PCP 1021 Opcodes is maintained in http://www.iana.org/ assignments/pcp- 1022 parameters): 1024 TBA Authentication Opcode. 1026 The following PCP Option Codes are to be allocated in the mandatory- 1027 to-process range from the standards action range (the registry for 1028 PCP Options is maintained in http://www.iana.org/ assignments/pcp- 1029 parameters): 1031 Option Name: Nonce. 1033 option-code: TBA in the mandatory-to-process range (IANA). 1035 Purpose: See Section 5.3. 1037 Valid for Opcodes: Authentication Opcode. 1039 option-len: Option Length is 4 octets. 1041 May appear in: request and response. 1043 Maximum occurences: 1. 1045 Option Name: Authentication Tag for Common PCP Messages. 1047 option-code: TBA in the mandatory-to-process range (IANA). 1049 Purpose: See Section 5.4. 1051 Valid for Opcodes: MAP, PEER and ANNOUNCE Opcodes. 1053 option-len: Variable length. 1055 May appear in: request and response. 1057 Maximum occurences: 1. 1059 Option Name: Authentication Tag for PCP Auth Messages. 1061 option-code: TBA in the mandatory-to-process range (IANA). 1063 Purpose: See Section 5.5. 1065 Valid for Opcodes: Authentication Opcode. 1067 option-len: Variable length. 1069 May appear in: request and response. 1071 Maximum occurences: 1. 1073 Option Name: EAP Payload. 1075 option-code: TBA in the mandatory-to-process range (IANA). 1077 Purpose: See Section 5.6. 1079 Valid for Opcodes: Authentication Opcode. 1081 option-len: Variable length. 1083 May appear in: request and response. 1085 Maximum occurences: 1. 1087 Option Name: PRF. 1089 option-code: TBA in the mandatory-to-process range (IANA). 1091 Purpose: See Section 5.7. 1093 Valid for Opcodes: Authentication Opcode. 1095 option-len: Variable length. 1097 May appear in: request and response. 1099 Maximum occurences: 1. 1101 Option Name: MAC Algorithm. 1103 option-code: TBA in the mandatory-to-process range (IANA). 1105 Purpose: See Section 5.8. 1107 Valid for Opcodes: Authentication Opcode. 1109 option-len: Variable length. 1111 May appear in: request and response. 1113 Maximum occurences: 1. 1115 Option Name: Session Lifetime. 1117 option-code: TBA in the mandatory-to-process range (IANA). 1119 Purpose: See Section 5.9. 1121 Valid for Opcodes: Authentication Opcode. 1123 option-len: Option Length is 4 octets. 1125 May appear in: response. 1127 Maximum occurences: 1. 1129 Option Name: Received Packet. 1131 option-code: TBA in the mandatory-to-process range (IANA). 1133 Purpose: See Section 5.10. 1135 Valid for Opcodes: Authentication Opcode. 1137 option-len: Option Length is 4 octets. 1139 May appear in: request and response. 1141 Maximum occurences: 1. 1143 Option Name: ID Indicator. 1145 option-code: TBA in the mandatory-to-process range (IANA). 1147 Purpose: See Section 5.11. 1149 Valid for Opcodes: Authentication Opcode. 1151 option-len: Variable length. 1153 May appear in: response. 1155 Maximum occurences: 1. 1157 The following PCP result codes are to be allocated in the mandatory- 1158 to-process range from the standards action range (the registry for 1159 PCP result codes is maintained in http://www.iana.org/ assignments/ 1160 pcp-parameters): 1162 TBA INITIATION: The client indication to the server for 1163 authentication. 1165 TBA AUTHENTICATION-REQUIRED: The server indication to the client 1166 that authentication is required. 1168 TBA AUTHENTICATION-FAILED: This error response is signaled to the 1169 client if EAP authentication had failed. 1171 TBA AUTHENTICATION-SUCCEEDED:This success response is signaled to 1172 the client if EAP authentication had succeeded. 1174 TBA AUTHORIZATION-FAILED: This error response is signaled to the 1175 client if the EAP authentication had succeeded but authorization 1176 failed. 1178 TBA SESSION-TERMINATED: This PCP result code indicates to the 1179 partner that the PA session must be terminated. 1181 TBA DOWNGRADE-ATTACK-DETECTED: This error response is signaled to 1182 the client if the server detects downgrade attack. 1184 8. Security Considerations 1186 In this work, after a successful EAP authentication process is 1187 performed between two PCP devices, an MSK will be exported. The MSK 1188 will be used to derive the transport keys to generate MAC digests for 1189 subsequent PCP message exchanges. However, before a transport key 1190 has been generated, the PA messages exchanged within a PA session 1191 have little cryptographic protection, and if there is no already 1192 established security channel between two session partners, these 1193 messages are subject to man-in-the-middle attacks and DOS attacks. 1194 For instance, the initial PA-Server and PA-Client exchange is 1195 vulnerable to spoofing attacks as these messages are not 1196 authenticated and integrity protected. In addition, because the PRF 1197 and MAC algorithms are transported at this stage, an attacker may try 1198 to remove the PRF and MAC options containing strong algorithms from 1199 the initial PA-Server message and force the client choose the weakest 1200 algorithms. Therefore, the server needs to guarantee that all the 1201 PRF and MAC algorithms it provides support for are strong enough. 1203 In order to prevent very basic DOS attacks, a PCP device SHOULD 1204 generate state information as little as possible in the initial PA- 1205 Server and PA-Client exchanges. The choice of EAP method is also 1206 very important. The selected EAP method must be resilient to the 1207 attacks possible in an insecure network environment, provide user- 1208 identity confidentiality, protection against dictionary attacks, and 1209 support session-key establishment. 1211 When a PCP proxy is located between a PCP server and PCP clients, the 1212 proxy may perform authentication with the PCP server before it 1213 processes requests from the clients. In addition, re-authentication 1214 between the PCP proxy and PCP server will not interrupt the service 1215 that the proxy provides to the clients since the proxy is still 1216 allowed to send common PCP messages to the PCP server during that 1217 period. 1219 9. Acknowledgements 1221 Thanks to Dan Wing, Prashanth Patil, Dave Thaler and Peter Saint- 1222 Andre for the valuable comments. 1224 10. Change Log 1226 [Note: This section should be removed by the RFC Editor upon 1227 publication] 1229 10.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1230 authentication-00 1232 o Added discussion of in-band and out-of-band key management 1233 options, leaving choice open for later WG decision. 1235 o Removed support for fragmenting EAP messages, as that is handled 1236 by EAP methods. 1238 10.2. Changes from wasserman-pcp-authentication-01 to -02 1240 o Add a nonce into the first two exchanged PCP-Auth message between 1241 the PCP client and PCP server. When a PCP client initiate the 1242 session, it can use the nonce to detect offline attacks. 1244 o Add the key ID field into the authentication tag option so that a 1245 MSK can generate multiple transport keys. 1247 o Specify that when a PCP device receives a PCP-Auth-Server or a 1248 PCP-Auth-Client message from its partner the PCP device needs to 1249 reply with a PCP-Auth-Acknowledge message to indicate that the 1250 message has been received. 1252 o Add the support of fragmenting EAP messages. 1254 10.3. Changes from ietf-pcp-authentication-00 to -01 1256 o Editorial changes, added use cases to introduction. 1258 10.4. Changes from ietf-pcp-authentication-01 to -02 1260 o Add the support of re-authentication initiated by PCP server. 1262 o Specify that when a PCP device receives a PCP-Auth-Server or a 1263 PCP-Auth-Client message from its partner the PCP device MAY reply 1264 with a PCP-Auth-Acknowledge message to indicate that the message 1265 has been received. 1267 o Discuss the format of the PCP-Auth-Acknowledge message. 1269 o Remove the redundant information from the Auth Opcode, and specify 1270 new result codes transported in PCP packet headers 1272 o 1274 10.5. Changes from ietf-pcp-authentication-02 to -03 1276 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1278 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1280 o Specify two new sequence numbers for common PCP messages in the 1281 PCP SA, and describe how to use them 1283 o Specify a Authentication Tag Option for PCP Common Messages 1285 o Introduce the scenario where a EAP message has to be divided into 1286 multiple sections and transported in different PCP-Auth messages 1287 (for the reasons of MTU), and introduce how to use PCP-Auth- 1288 Acknowledge messages to ensure reliable packet delivery in this 1289 case. 1291 10.6. Changes from ietf-pcp-authentication-03 to -04 1293 o Change the name "PCP-Auth" to "PA". 1295 o Refine the retransmission policies. 1297 o Add more discussion about the sequence number management . 1299 o Provide the discussion about how to instruct a PCP client to 1300 choose proper credential during authentication, and an ID 1301 Indicator Option is defined for that purpose. 1303 10.7. Changes from ietf-pcp-authentication-04 to -05 1305 o Add contents in IANA considerations. 1307 o Add discussions in fragmentation. 1309 o Refine the PA messages retransmission policies. 1311 o Add IANA considerations. 1313 10.8. Changes from ietf-pcp-authentication-05 to -06 1315 o Added mechanism to handle algorithm downgrade attack. 1317 o Updated Security Considerations section. 1319 o Updated ID Indicator Option. 1321 11. References 1323 11.1. Normative References 1325 [I-D.ietf-precis-saslprepbis] 1326 Saint-Andre, P. and A. Melnikov, "Preparation, 1327 Enforcement, and Comparison of Internationalized Strings 1328 Representing Usernames and Passwords", draft-ietf-precis- 1329 saslprepbis-17 (work in progress), May 2015. 1331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1332 Requirement Levels", BCP 14, RFC 2119, March 1997. 1334 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1335 10646", STD 63, RFC 3629, November 2003. 1337 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1338 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1339 3748, June 2004. 1341 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1342 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1344 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1345 Protocol Tunneled Transport Layer Security Authenticated 1346 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 1348 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1349 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1350 5996, September 2010. 1352 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1353 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1354 2013. 1356 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1357 "Tunnel Extensible Authentication Protocol (TEAP) Version 1358 1", RFC 7170, May 2014. 1360 11.2. Informative References 1362 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1363 Authentication Protocol", RFC 5216, March 2008. 1365 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1366 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1367 RFC 5433, February 2009. 1369 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1370 Extensible Authentication Protocol Method for 3rd 1371 Generation Authentication and Key Agreement (EAP-AKA')", 1372 RFC 5448, May 2009. 1374 Authors' Addresses 1376 Margaret Wasserman 1377 Painless Security 1378 356 Abbott Street 1379 North Andover, MA 01845 1380 USA 1382 Phone: +1 781 405 7464 1383 Email: mrw@painless-security.com 1384 URI: http://www.painless-security.com 1386 Sam Hartman 1387 Painless Security 1388 356 Abbott Street 1389 North Andover, MA 01845 1390 USA 1392 Email: hartmans@painless-security.com 1393 URI: http://www.painless-security.com 1395 Dacheng Zhang 1396 Huawei 1397 Beijing 1398 China 1400 Email: zhang_dacheng@hotmail.com 1402 Tirumaleswar Reddy 1403 Cisco Systems, Inc. 1404 Cessna Business Park, Varthur Hobli 1405 Sarjapur Marathalli Outer Ring Road 1406 Bangalore, Karnataka 560103 1407 India 1409 Email: tireddy@cisco.com