idnits 2.17.1 draft-ietf-pcp-authentication-06.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The above rules are not applicable to PA-Acknowledgement messages (i.e., PA messages containing a Received Packet Option). A PA-Acknowledgement message does not transport any EAP message and only indicates that a PA message is received. Therefore, reliable transmission of PA-Acknowledgement message is not required. For instance, after sending out a PA-Acknowledgement message, a device generates a EAP response. In this case, the device need not have to confirm whether the PA-Acknowledgement message has been received by its session partner or not. Therefore, when receiving or sending out a PA-Acknowledgement message, the device MUST not increase the corresponding sequence number stored in the SA. Otherwise, loss of PA-Acknowledgement message during transportation will cause mismatch in sequence numbers. -- The document date (October 13, 2014) is 3482 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5191' is defined on line 1142, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: Experimental Painless Security 5 Expires: April 16, 2015 D. Zhang 6 Huawei 7 T. Reddy 8 Cisco 9 October 13, 2014 11 Port Control Protocol (PCP) Authentication Mechanism 12 draft-ietf-pcp-authentication-06 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 proposes 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 April 16, 2015. 45 Copyright Notice 47 Copyright (c) 2014 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.2. Session Termination . . . . . . . . . . . . . . . . . . . 8 67 3.3. Session Re-Authentication . . . . . . . . . . . . . . . . 8 68 4. PA Security Association . . . . . . . . . . . . . . . . . . . 9 69 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 10 71 5.2. Authentication OpCode . . . . . . . . . . . . . . . . . . 11 72 5.3. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 12 73 5.4. Authentication Tag Option for Common PCP . . . . . . . . 12 74 5.5. Authentication Tag Option for PCP Auth Messages . . . . . 13 75 5.6. EAP Payload Option . . . . . . . . . . . . . . . . . . . 14 76 5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.8. MAC Algorithm Option . . . . . . . . . . . . . . . . . . 15 78 5.9. Session Lifetime Option . . . . . . . . . . . . . . . . . 15 79 5.10. Received Packet Option . . . . . . . . . . . . . . . . . 15 80 5.11. ID Indicator Option . . . . . . . . . . . . . . . . . . . 16 81 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. Authentication Data Generation . . . . . . . . . . . . . 17 83 6.2. Authentication Data Validation . . . . . . . . . . . . . 17 84 6.3. Retransmission Policies for PA Messages . . . . . . . . . 18 85 6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 19 86 6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 20 87 6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 20 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 91 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 10.1. Changes from wasserman-pcp-authentication-02 to ietf- 93 pcp-authentication-00 . . . . . . . . . . . . . . . . . 23 94 10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 23 95 10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 23 96 10.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 23 97 10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 24 98 10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 24 99 10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 24 100 10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 24 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 103 11.2. Informative References . . . . . . . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 Using the Port Control Protocol (PCP) [RFC6887], an IPv4 or IPv6 host 109 can flexibly manage the IP address mapping information on its network 110 address translators (NATs) and firewalls, and control their policies 111 in processing incoming and outgoing IP packets. Because NATs and 112 firewalls both play important roles in network security 113 architectures, there are many situations in which authentication and 114 access control are required to prevent un-authorized users from 115 accessing such devices. This document proposes a PCP security 116 extension which enables PCP servers to authenticate their clients 117 with Extensible Authentication Protocol (EAP). The EAP messages are 118 encapsulated within PCP packets during transportation. 120 The following issues are considered in the design of this extension: 122 o Loss of EAP messages during transportation 124 o Disordered delivery of EAP messages 126 o Generation of transport keys 128 o Integrity protection and data origin authentication for PCP 129 messages 131 o Algorithm agility 133 The mechanism described in this document meets the security 134 requirements to address the Advanced Threat Model described in the 135 base PCP specification [RFC6887]. This mechanism can be used to 136 secure PCP in the following situations: 138 o On security infrastructure equipment, such as corporate firewalls, 139 that do not create implicit mappings for specific traffic. 141 o On equipment (such as CGNs or service provider firewalls) that 142 serve multiple administrative domains and do not have a mechanism 143 to securely partition traffic from those domains. 145 o For any implementation that wants to be more permissive in 146 authorizing explicit mappings than it is in authorizing implicit 147 mappings. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 Most of the terms used in this document are introduced in [RFC6887]. 157 PCP Client: A PCP device (e.g., a host) which is responsible for 158 issuing PCP requests to a PCP server. In this document, a PCP client 159 is also a EAP peer [RFC3748], and it is the responsibility of a PCP 160 client to provide the credentials when authentication is required. 162 PCP Server: A PCP device (e.g., a NAT or a firewall) that implements 163 the server-side of the PCP protocol, via which PCP clients request 164 and manage explicit mappings. In this document, a PCP server is 165 integrated with an EAP authenticator [RFC3748]. Therefore, when 166 necessary, a PCP server can verify the credentials provided by a PCP 167 client and make an access control decision based on the 168 authentication result. 170 PCP-Authentication (PA) Session: A series of PCP message exchanges 171 transferred between a PCP client and a PCP server. The PCP message 172 involved within a session includes the PA messages used to perform 173 EAP authentication, key distribution and session management, and the 174 common PCP messages secured with the keys distributed during 175 authentication. Each PA session is assigned a distinctive Session 176 ID. 178 Session Partner: A PCP device involved within a PA session. Each PA 179 session has two session partners (a PCP server and a PCP client). 181 Session Lifetime: The life period associated with a PA session, which 182 decides the lifetime of the current authorization given to the PCP 183 client. 185 PCP Security Association (PCP SA): A PCP security association is 186 formed between a PCP client and a PCP server by sharing cryptographic 187 keying material and associated context. The formed duplex security 188 association is used to protect the bidirectional PCP signaling 189 traffic between the PCP client and PCP server. 191 Master Session Key (MSK): A key derived by the partners of a PA 192 session, using an EAP key generating method (e.g., the one defined in 193 [RFC5448]). 195 PCP-Authentication (PA) message: A PCP message containing an 196 Authentication Opcode. Particularly, a PA message sent from a PCP 197 server to a PCP client is referred to as a PA-Server, while PA 198 message sent from a PCP client to a PCP server is referred to as a 199 PA-Client. Therefore, a PA-Server is actually a PCP response message 200 specified in [RFC6887], and a PA-Client is a PCP request message. 201 This document specifies an option, the Authentication Tag Option for 202 PCP Auth, to provide integrity protection and message origin 203 authentication for PA messages. 205 Common PCP message: A PCP message which does not contain an 206 Authentication Opcode. This document specifies an option, the 207 Authentication Tag Option for Common PCP, to provide integrity 208 protection and message origin authentication for the common PCP 209 messages. 211 3. Protocol Details 213 3.1. Session Initiation 215 At the beginning of a PA session, a PCP client and a PCP server need 216 to exchange a series of PA messages in order to perform an EAP 217 authentication process. Each PA message is attached with an 218 Authentication Opcode and may optionally contain a set of Options for 219 various purposes (e.g., transporting authentication messages and 220 session management). The Authentication Opcode consists of two 221 fields: Session ID and Sequence Number. The Session ID field is used 222 to identify the PA session to which the message belongs. The 223 sequence number field is used to detect the disorder or the 224 duplication occurred during packet delivery. 226 When a PCP client intends to proactively initiate a PA session with a 227 PCP server, it sends a PA-Initiation message (a PA-Client message 228 with the result code "INITIATION") to the PCP server. In the 229 message, the Session ID and Sequence Number fields of the 230 Authentication Opcode are set as 0. The PCP client SHOULD also 231 append a nonce option which consists of a random nonce with the 232 message. 234 After receiving the PA-Initiation, if the PCP server agrees to 235 initiate a PA session with the PCP client, it will reply with a PA- 236 Server message which contains an EAP Identity Request, and the result 237 code field of this PA-Server message is set as AUTHENTICATION- 238 REQUIRED. In addition, the server MUST assign a random session 239 identifier to distinctly identify this session, and fill the 240 identifier into the Session ID field of the Authentication Opcode in 241 the PA-Server message. The Sequence Number field of the 242 Authentication Opcode is set as 0. If there is a nonce option in the 243 received PA-Initiation message, the PA-Server message MUST be 244 attached with a nonce option so as to send the nonce value back. The 245 nonce will then be used by the PCP client to check the freshness of 246 this message. From now on, every PCP message within this session 247 will be attached with this session identifier. When receiving a PA 248 message from an unknown session, a PCP device MUST discard the 249 message silently. If the PCP client intends to simplify the 250 authentication process, it MAY append an EAP Identity Response 251 message within the PA-Initiation message so as to inform the PCP 252 server that it would like to perform EAP authentication and skip the 253 step of waiting for the EAP Identity Request. 255 In the scenario where a PCP server receives a common PCP request 256 message from a PCP client which needs to be authenticated, the PCP 257 server can reply with a PA-Server message to initiate a PA session. 258 The result code field of this PA-Server message is set as 259 AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a 260 session ID for the session and transfer it within the PA-Server 261 message. The Sequence Number field in the PA-Server is set as 0. In 262 the PA messages exchanged afterwards in this session, the session ID 263 MUST be used in order to help session partners distinguish the 264 messages within this session from those not within. When the PCP 265 client receives this initial PA-Server message from the PCP server, 266 it can reply with a PA-Client message or silently discard the request 267 message according to its local policies. In the PA-Client message, a 268 nonce option which consists of a random nonce MAY be appended. If 269 so, in the next PA-Server message, the PCP sever MUST forward the 270 nonce back within a nonce option. 272 In a PA session, an EAP request message is transported within a PA- 273 Server message, and an EAP answer message is transported within a PA- 274 Client message. EAP relies on the underlying protocol to provide 275 reliable transmission; any disordered delivery or loss of packets 276 occurred during transportation must be detected and addressed. 277 Therefore, after sending out a PA-Server message, the PCP server will 278 not send a new PA-Server message until it receives a PA-Client 279 message with a proper sequence number from the PCP client, and vice 280 versa. If a PCP device receives a PA message from its partner and 281 cannot generate a EAP response within a pre-specified period due to 282 certain reasons (e.g., waiting for human input to construct a EAP 283 message or waiting for the additional PA messages in order to 284 construct a complete EAP message), the PCP device MUST reply with a 285 PA-Acknowledge message (PA message with a Received Packet Option) to 286 notify the packet has been received. This approach not only can 287 avoid unnecessary retransmission of the PA message but also can 288 guarantee the reliable packet delivery in the conditions where a PCP 289 device needs to receive multiple PA messages before generating an EAP 290 response. 292 In this approach, it is mandated for a PCP client and a PCP server to 293 perform a key-generating EAP method in authentication. Therefore, 294 after a successful authentication procedure, a Master Session Key 295 (MSK) will be generated. If the PCP client and the PCP server want 296 to generate a traffic key using the MSK, they need to agree upon a 297 Pseudo-Random Function (PRF) for the transport key derivation and a 298 MAC algorithm to provide data origin authentication for subsequent 299 PCP packets. In order to do this, the PCP server needs to append a 300 set of PRF Options and MAC Algorithm Options to the initial PA-Server 301 message. Each PRF Option contains a PRF that the PCP server 302 supports, and each MAC Algorithm Option contains a MAC (Message 303 Authentication Code) algorithm that the PCP server supports. 304 Moreover, in the first PA-Server message, the server MAY also attach 305 a ID Indication Option to direct the client to choose correct 306 credentials. After receiving the options, the PCP client selects the 307 PRF and the MAC algorithm which it would like to use, and then 308 attaches the associated PRF and MAC Algorithm Options to the next PA- 309 Client message. 311 After the EAP authentication, the PCP server sends out a PA-Server 312 message to indicate the EAP authentication and PCP authorization 313 results. If the EAP authentication succeeds, the result code of the 314 PA-Server message is AUTHENTICATION-SUCCEED. In this case, before 315 sending out the PA-Server message, the PCP server MUST generate a PCP 316 SA and use the derived transport key to generate a digest for the 317 message. The digest is transported within an Authentication Tag 318 Option for PCP Auth. A more detailed description of generating the 319 authentication data can be found in Section 7.1. In addition, the 320 PA-Server MAY also contain a Session Lifetime Option which indicates 321 the life-time of the PA session (i.e., the life-time of the MSK). 322 After receiving the PA-Server message, the PCP client then needs to 323 generate a PA-Client message as response. This response MUST also 324 include the set of PRF and MAC Algorithm options received from the 325 PCP server. The PCP server determines if the set of algorithms 326 conveyed by the client matches the set it had initially sent to 327 detect algorithm downgrade attack. If the PCP client also 328 authenticates the PCP server, the result code of the PA-Client is 329 AUTHENTICATION-SUCCEED. In addition, the PCP client needs to 330 generate a PCP SA and uses the derived traffic key to secure the 331 message. From then on, all the PCP messages within the session are 332 secured with the traffic key and the MAC algorithm specified in the 333 PCP SA, unless a re-authentication is performed. 335 If a PCP client/server cannot authenticate its session partner, the 336 device sends out a PA message with the result code, AUTHENTICATION- 337 FAILED. If the EAP authentication succeeds but Authorization fails, 338 the device making the decision sends out a PA message with the result 339 code, AUTHORIZATION-FAILED. In these two cases, after the PA message 340 is sent out, the PA session MUST be terminated immediately. 342 3.2. Session Termination 344 A PA session can be explicitly terminated by sending a termination- 345 indicating PA message (a PA message with a result code "SESSION- 346 TERMINATION" ) from either session partner. After receiving a 347 Termination-Indicating message from the session partner, a PCP device 348 MUST respond with a Termination-Indicating PA message and remove the 349 PA SA immediately. When the session partner initiating the 350 termination process receives the PA message, it will remove the 351 associated PA SA immediately. 353 3.3. Session Re-Authentication 355 A session partner may select to perform EAP re-authentication if it 356 would like to update the PCP SA without initiating a new PA session. 357 An re-authentication procedure could be triggered for the following 358 reasons: 360 o The session life period needs to be extended 362 o The sequence number is going to reach the maximum value 364 When the PCP server would like to initiate a re-authentication, it 365 sends the PCP client a PA-Server message. The result code of the 366 message is set to "RE-AUTHENTICATION", which indicates the message is 367 for an re-authentication process. If the PCP client would like to 368 start the re-authentication, it will send an PA-Client message to the 369 PCP server, the result code of the PA-Client message is set to "RE- 370 AUTHENTICATION". Then, the session partners exchange PA messages to 371 transfer EAP messages for the re-authentication. During the re- 372 authentication procedure, the session partners protect the integrity 373 of PA messages with the key and MAC algorithm specified in the 374 current PCP SA; the sequence numbers associated with the packet will 375 continue to keep increasing according to Section 7.3. 377 If the EAP re-authentication succeeds, the result code of the last 378 PA-Server is "AUTHENTICATION-SUCCEED". In this case, before sending 379 out the PA-Server message, the PCP server MUST update the SA and use 380 the new key to generate digest for the PA-Server and subsequent PCP 381 messages. In addition, the PA-Server message MAY be appended with a 382 Session Lifetime Option which indicates the new life-time of the PA 383 session. PA and PCP message sequence numbers must also be reset to 384 zero. 386 If the EAP authentication fails, the result code of the last PA- 387 Server is "AUTHENTICATION-FAILED". If the EAP authentication 388 succeeds but Authorization fails, the result code of the last PA- 389 Server is "AUTHORIZATION-FAILED". In the latter two cases, the PA 390 session MUST be terminated immediately after the last PA message 391 exchange. 393 During re-authentication, the session partners can also exchange 394 common PCP messages in parallel. The common PCP messages MUST be 395 protected with the current SA until the new SA has been generated. 397 4. PA Security Association 399 At the beginning of a PA session, a session SHOULD generate a PA SA 400 to maintain its state information during the session. The parameters 401 of a PA SA are listed as follows: 403 o IP address and UDP port number of the PCP client 405 o IP address and UDP port number of the PCP server 407 o Session Identifier 409 o Sequence number for the next outgoing PA message 411 o Sequence number for the next incoming PA message 413 o Sequence number for the next outgoing common PCP message 415 o Sequence number for the next incoming common PCP message 417 o Last outgoing message payload 419 o Retransmission interval 421 o MSK: The master session key generated by the EAP method. 423 o MAC algorithm: The algorithm that the transport key should use to 424 generate digests for PCP messages. 426 o Pseudo-random function: The pseudo random function negotiated in 427 the initial PA-Server and PA-Client exchange for the transport key 428 derivation 430 o Transport key: the key derived from the MSK to provide integrity 431 protection and data origin authentication for the messages in the 432 PA session. The life-time of the transport key SHOULD be 433 identical to the life-time of the session. 435 o The nonce selected by the PCP client at the initiation of the 436 session. 438 o Key ID: the ID associated with Transport key. 440 Particularly, the transport key is computed in the following way: 441 Transport key = prf(MSK, "IETF PCP"| Session_ID| Nonce| key ID), 442 where: 444 o The prf: The pseudo-random function assigned in the Pseudo-random 445 function parameter. 447 o MSK: The master session key generated by the EAP method. 449 o "IETF PCP": The ASCII code representation of the non-NULL 450 terminated string (excluding the double quotes around it). 452 o Session_ID: The ID of the session which the MSK is derived from. 454 o Nonce: The nonce selected by the client and transported in the 455 Initial PA-Client packet. If the PCP client does not select one, 456 this value is set as 0. 458 o Key ID: The ID assigned for the traffic key. 460 5. Packet Format 462 5.1. Packet Format of PCP Auth Messages 464 The format of PA-Server message is identical to the response packet 465 format specified in Section 7.2 of [RFC6887]. 467 As illustrated in Figure 1, the PA-Client messages use the request 468 header specified in Section 7.1 of[RFC6887]. The only difference is 469 that eight reserved bits are used to transfer the result codes (e.g., 470 "INITIATION", "AUTHENTICATION-FAILED"). Other fields in Figure 1 are 471 described in Section 7.1 of [RFC6887]. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Version = 2 |R| Opcode | Reserved | Result Code | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Requested Lifetime (32 bits) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 | PCP Client's IP Address (128 bits) | 482 | | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 : : 486 : Opcode-specific information : 487 : : 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 : : 490 : (optional) PCP Options : 491 : : 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 1. PA-Client message Format 496 5.2. Authentication OpCode 498 The following figure illustrates the format of an authentication 499 Opcode: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Session ID | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Sequence Number | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Session ID: This field contains a 32-bit PA session identifier. 511 Sequence Number: This field contains a 32-bit sequence number. In 512 this solution, a sequence number needs to be incremented on every 513 new (non-retransmission) outgoing packet in order to provide 514 ordering guarantee for PCP. 516 5.3. Nonce Option 518 Because the session identifier of PA session is determined by the PCP 519 server, a PCP client does not know the session identifier which will 520 be used when it sends out a PA-Initiation message. In order to 521 prevent an attacker from interrupting the authentication process by 522 sending off-line generated PA-Server messages, the PCP client needs 523 to generate a random number as nonce in the PA-Initiation message. 524 The PCP server will append the nonce within the initial PA-Server 525 message. If the PA-Server message does not carry the correct nonce, 526 the message will be discarded silently. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Option Code | Reserved | Option-Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Nonce | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Option-Length: The length of the Nonce Option (in octet), 537 including the 4 octet fixed header and the variable length of the 538 authentication data. 540 Nonce: A random 32 bits number which is transported within a PA- 541 Initiation message and the corresponding reply message from the 542 PCP server. 544 5.4. Authentication Tag Option for Common PCP 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Option Code | Reserved | Option-Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Session ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Sequence Number | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Key ID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 | Authentication Data (Variable) | 559 ~ ~ 560 | | 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Because there is no authentication Opcode in common PCP messages, the 565 authentication tag for common PCP messages needs to provide the 566 information of session ID and sequence numbers. 568 Option-Length: The length of the Authentication Tag Option for 569 Common PCP (in octet), including the 12 octet fixed header and the 570 variable length of the authentication data. 572 Session ID: A 32-bit field used to indicates the identifier of the 573 session that the message belongs to and identifies the secret key 574 used to create the message digest appended to the PCP message. 576 Sequence Number: This field contains a 32-bit sequence number. In 577 this solution, a sequence number needs to be incremented on every 578 new (non-retransmission) outgoing packet in order to provide 579 ordering guarantee for common PCP messages. 581 Key ID: The ID associated with the traffic key used to generate 582 authentication data. This field is filled with zero if MSK is 583 directly used to secure the message. 585 Authentication Data: A variable-length field that carries the 586 Message Authentication Code for the PCP packet. The generation of 587 the digest varies according to the algorithms specified in 588 different PCP SAs. This field MUST end on a 32-bit boundary, 589 padded with 0's when necessary. 591 5.5. Authentication Tag Option for PCP Auth Messages 593 This option is used to provide message authentication for PA 594 messages. Compared with the Authentication Tag Option for Common 595 PCP, the session ID field and the sequence number field are removed 596 because such information is provided in the Authentication Opcode. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Option Code | Reserved | Option-Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Key ID | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 | Authentication Data (Variable) | 607 ~ ~ 608 | | 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Option-Length: The length of the Authentication Tag Option for PCP 613 Auth (in octet), including the 12 octet fixed header and the 614 variable length of the authentication data. 616 Key ID: The ID associated with the traffic key used to generate 617 authentication data. This field is filled with zero if MSK is 618 directly used to secure the message. 620 Authentication Data: A variable-length field that carries the 621 Message Authentication Code for the PCP packet. The generation of 622 the digest varies according to the algorithms specified in 623 different PCP SAs. This field MUST end on a 32-bit boundary, 624 padded with 0's when necessary. 626 5.6. EAP Payload Option 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Option Code | Reserved | Option-Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 | EAP Message | 635 ~ ~ 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Option-Length: The length of the EAP Payload Option (in octet), 640 including the 4 octet fixed header and the variable length of the 641 EAP message. 643 EAP Message: The EAP message transferred. Note this field MUST 644 end on a 32-bit boundary, padded with 0's when necessary. 646 5.7. PRF Option 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Option Code | Reserved | Option-Length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | PRF | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Option-Length: The length of the PRF Option (in octet), including the 657 4 octet fixed header and the variable length of the EAP message. 659 PRF: The Pseudo-Random Function which the sender supports to generate 660 an MSK. This field contains an IKEv2 Transform ID of Transform Type 661 2 [RFC4306][RFC4868]. A PCP implementation MUST support 662 PRF_HMAC_SHA2_256 (5). 664 5.8. MAC Algorithm Option 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Option Code | Reserved | Option-Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | MAC Algorithm ID | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Option-Length: The length of the MAC Algorithm Option (in octet), 675 including the 4 octet fixed header and the variable length of the EAP 676 message. 678 MAC Algorithm ID: Indicate the MAC algorithm which the sender 679 supports to generate authentication data. The MAC Algorithm ID field 680 contains an IKEv2 Transform ID of Transform Type 3 681 [RFC4306][RFC4868].A PCP implementation MUST support 682 AUTH_HMAC_SHA2_256_128 (12). 684 5.9. Session Lifetime Option 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Option Code | Reserved | Option-Length | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Session Lifetime | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Option-Length: The length of the Session Lifetime Option (in octet), 695 including the 4 octet fixed header and the variable length of the EAP 696 message. 698 Session Lifetime: The life time of the PA Session, which is decided 699 by the authorization result. 701 5.10. Received Packet Option 703 This option is used in a PA-Acknowledgement message to indicate a 704 packet with the contained sequence number has been received. 706 0 1 2 3 707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Option Code | Reserved | Option-Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Received Sequence Number | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Option-Length: The length of the Received Packet Option (in octet), 715 including the 4 octet fixed header and the variable length of the EAP 716 message. 718 Received Sequence Number: The sequence number of the last received 719 PCP packet. 721 5.11. ID Indicator Option 723 The ID Indicator option is used by the PCP client to determine which 724 credentials to provide to the PCP server. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Option Code | Reserved | Option-Length | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | | 732 | ID Indicator | 733 ~ ~ 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Option-Length: The length of the ID Indication Option (in octet), 738 including the 4 octet fixed header and the variable length of the 739 EAP message. 741 ID Indicator: The ID indicator is the identity of the authority 742 that issued the credentials. This value is used by the PCP client 743 to choose proper credentials for authentication. The method of 744 generating this value is out of scope of this document. This 745 field is encoded in UTF-8 [RFC3629] format This field MUST end on 746 a 32-bit boundary, padded with 0's when necessary. 748 6. Processing Rules 749 6.1. Authentication Data Generation 751 If a PCP SA is generated as the result of a successful EAP 752 authentication process, every subsequent PCP message within the 753 session MUST carry an Authentication Tag Option which contains the 754 digest of the PCP message for data origin authentication and 755 integrity protection. 757 Before generating a digest for a PA message, a device needs to first 758 locate the PCP SA according to the session identifier and then get 759 the traffic key. Then the device appends an Authentication Tag 760 Option for PCP Auth at the end of the PCP Auth message. The length 761 of the Authentication Data field is decided by the MAC algorithm 762 adopted in the session. The device then fills the Key ID field with 763 the key ID of the traffic key, and sets the Authentication Data field 764 to 0. After this, the device generates a digest for the entire PCP 765 message (including the PCP header and Authentication Tag Option) 766 using the traffic key and the associated MAC algorithm, and inserts 767 the generated digest into the Authentication Data field. 769 Similar to generating a digest for a PA message, before generating a 770 digest for a common PCP message, a device needs to first locate the 771 PCP SA according to the session identifier and then get the traffic 772 key. Then the device appends the Authentication Tag Option at the 773 end of common PCP message. The length of the Authentication Data 774 field is decided by the MAC algorithm adopted in the session. The 775 device then uses the corresponding values derived from the SA to fill 776 the Session ID field, the Sequence Number field, and the Key ID 777 field, and sets the Authentication Data field to 0. After this, the 778 device generates a digest for the entire PCP message (including the 779 PCP header and Authentication Tag Option) using the traffic key and 780 the associated MAC algorithm, and inputs the generated digest into 781 the Authentication Data field. 783 6.2. Authentication Data Validation 785 When a device receives a common PCP packet with an Authentication Tag 786 Option for Common PCP, the device needs to use the session ID 787 transported in the option to locate the proper SA, and then find the 788 associated transport key (using key ID in the option) and the MAC 789 algorithm. If no proper SA or traffic key is found or the sequence 790 number is invalid (see Section 7.5), the PCP packet MUST be discarded 791 silently. After storing the value of the Authentication field of the 792 Authentication Tag Option, the device fills the Authentication field 793 with zeros. Then, the device generates a digest for the packet 794 (including the PCP header and Authentication Tag Option) with the 795 transport key and the MAC algorithm found in the first step. If the 796 value of the newly generated digest is identical to the stored one, 797 the device can ensure that the packet has not been tampered with, and 798 the validation succeeds. Otherwise, the packet MUST be discarded. 800 Similarly, when a device receives a PA message with an Authentication 801 Tag Option for PCP Auth, the device needs to use the session ID 802 transported in the opcode to locate the proper SA, and then find the 803 associated transport key (using key ID in the option) and the MAC 804 algorithm. If no proper SA or traffic key is found or the sequence 805 number is invalid (see Section 7.4), the PCP packet MUST be discarded 806 silently. After storing the value of the Authentication field of the 807 Authentication Tag Option, the device fills the Authentication field 808 with zeros. Then, the device generates a digest for the packet 809 (including the PCP header and Authentication Tag Option) with the 810 transport key and the MAC algorithm found in the first step. If the 811 value of the newly generated digest is identical to the stored one, 812 the device can ensure that the packet has not been tampered with, and 813 the validation succeeds. Otherwise, the packet MUST be discarded. 815 6.3. Retransmission Policies for PA Messages 817 Because EAP relies on the underlying protocols to provide reliable 818 transmission, after sending a PA message, a PCP client/server MUST 819 NOT send out any subsequent messages until receiving an expect PA 820 message (the PA message with a proper sequence number) from the peer. 821 If no such a message is received in a certain period, the PCP device 822 will re-send the last message according to certain retransmission 823 policies. This work reuses the retransmission policies specified in 824 the base PCP protocol (Section 8.1.1 of [RFC6887]). In the base PCP 825 protocol, such retransmission policies are only applied by PCP 826 clients. However, in this work, such retransmission policies are 827 also applied by the PCP servers. If the timer is expired and no 828 expected response is received, the device will terminate the session 829 and discard the current SA. 831 Note that the last PA messages transported within the phases of 832 session initiation, session re-authentication, and session 833 termination do not have to follow the above policies since the 834 devices sending out those messages do not expect any further PA 835 messages. 837 When a device receives such a duplicate PA message from its session 838 partner, it MUST try to answer it by sending the last outgoing PA 839 message again. In order to achieve this function, the device needs 840 to maintain the last incoming and the associated outgoing packet. In 841 this case, if no outgoing PA message has been generated for the 842 received duplicate PA message yet, the device needs to generate a PA- 843 Acknowledgement message and sends it out. The rate of replying the 844 duplicate PA messages MUST be limited. 846 6.4. Sequence Numbers for PCP Auth Messages 848 PCP uses UDP to transport signaling messages. As an un-reliable 849 transport protocol, UDP does not guarantee ordered packet delivery 850 and does not provide any protection from packet loss. In order to 851 ensure the EAP messages are exchanged in a reliable way, every PCP 852 packet exchanged during EAP authentication must carry an 853 monotonically increasing sequence number. During a PA session, a PCP 854 device needs to maintain two sequence numbers for PA messages, one 855 for incoming PA messages and one for outgoing PA messages. When 856 generating an outgoing PA packet, the device attaches the associated 857 outgoing sequence number to the packet and increments the sequence 858 number maintained in the SA by 1. When receiving a PA packet from 859 its session partner, the device will not accept it if the sequence 860 number carried in the packet does not match the incoming sequence 861 number the device maintains. After confirming that the received 862 packet is valid, the device increments the incoming sequence number 863 maintained in the SA by 1. 865 The above rules are not applicable to PA-Acknowledgement messages 866 (i.e., PA messages containing a Received Packet Option). A PA- 867 Acknowledgement message does not transport any EAP message and only 868 indicates that a PA message is received. Therefore, reliable 869 transmission of PA-Acknowledgement message is not required. For 870 instance, after sending out a PA-Acknowledgement message, a device 871 generates a EAP response. In this case, the device need not have to 872 confirm whether the PA-Acknowledgement message has been received by 873 its session partner or not. Therefore, when receiving or sending out 874 a PA-Acknowledgement message, the device MUST not increase the 875 corresponding sequence number stored in the SA. Otherwise, loss of 876 PA-Acknowledgement message during transportation will cause mismatch 877 in sequence numbers. 879 Another exception is the message retransmission scenarios. When a 880 device does not receive any response from its session partner in a 881 certain period, it needs to retransmit the last outgoing PA message 882 with a limited rate. The original message and duplicate messages 883 MUST use the identical sequence number. When the device receives 884 such a duplicate PA message from its session partner, it MUST try to 885 answer it by sending the last outgoing PA message again. Note that 886 the replying to duplicate PA messages must be rate limited. In such 887 cases, the maintained incoming and outgoing sequence numbers will not 888 be affected by the message retransmission. 890 6.5. Sequence Numbers for Common PCP Messages 892 When transporting common PCP messages within a PA session, a PCP 893 device needs to maintain a sequence number for outgoing common PCP 894 messages and a sequence number for incoming common PCP messages. 895 When generating a new outgoing PCP messages, the PCP device updates 896 the Sequence Number field in the Authentication tag option with the 897 outgoing sequence number maintained in the SA and increments outgoing 898 sequence number by 1. 900 When receiving a PCP packet from its session partner, the PCP device 901 will not accept it if the sequence number carried in the packet is 902 smaller than the incoming sequence number the device maintains. This 903 approach can protect the PCP device from replay attacks. After 904 confirming that the received packet is valid, the PCP device will 905 update the incoming sequence number maintained in the PCP SA with the 906 sequence number of the incoming packet. 908 Note that the sequence number in the incoming packet may not exactly 909 match the incoming sequence number maintained locally. As discussed 910 in the base PCP specification [RFC6887], If a PCP client no longer 911 interested in the PCP transaction and has not yet received PCP 912 response from the server then it will stop retransmitting the PCP 913 request. After that, the PCP client will generate new PCP requests 914 for other purposes using the current SA. In this case, the sequence 915 number in the new request will be larger than the sequence number in 916 the old request and so will be larger than the incoming sequence 917 number maintained in the PCP server. 919 Note that in the base PCP specification [RFC6887], a PCP client needs 920 to select a nonce in each MAP or PEER request, the nonce is sent back 921 in the response. However, it is possible for a client to use the 922 same nonce in multiple MAP or PEER request, this may cause potential 923 risk of replay attacks. This attack is addressed by using the 924 sequence number in the PCP response. 926 6.6. MTU Considerations 928 EAP methods are responsible for MTU handling, so no special 929 facilities are required in PCP to deal with MTU issues. 930 Particularly, EAP lower layers indicate to EAP methods and AAA 931 servers the MTU of the lower layer. EAP methods such as EAP-TLS 932 [RFC5216], TEAP [RFC7170], and others that are likely to exceed 933 reasonable MTUs provide support for fragmentation and reassembly. 934 Others, such as EAP-GPSK assume they will never send packets larger 935 than the MTU and use small EAP packets. 937 If an EAP message is too long to be transported within a single PA 938 message, it will be divided into multiple sections and transports 939 them within different PA messages. Note that the receiver may not be 940 able to know what to do in the next step until receiving all the 941 sections and constructing the complete EAP message. In this case, in 942 order to guarantee reliable message transmission, after receiving a 943 PA message, the receiver replies with a PA-Acknowledgement message to 944 notify the sender to send the next PA message. 946 7. IANA Considerations 948 In order to identify Authentication Opcode, a new value (TBD) needs 949 to be defined in the IANA registry for PCP Opcodes. 951 A set of options are defined in this specification, each of them 952 needs to be associated with a value defined in the IANA registry for 953 PCP option code: 955 Nonce Option TBD 957 Authentication Tag Option for Common PCP TBD 959 Authentication Tag Option for PCP Auth Messages TBD 961 EAP Payload Option TBD 963 PRF Option TBD 965 MAC Algorithm Option TBD 967 Session Lifetime Option TBD 969 Received Packet Option TBD 971 ID Indication Option TBD 973 A set of new result codes is specified in this specification, each 974 result code needs to assigned a value in the IANA registry for PCP 975 result codes. 977 TBD INITIATION 979 TBD AUTHENTICATION-REQUIRED 981 TBD AUTHENTICATION-FAILED 983 TBD AUTHENTICATION-SUCCEED 984 TBD AUTHORIZATION-FAILED 986 TBD SESSION-TERMINATION 988 8. Security Considerations 990 In this work, after a successful EAP authentication process is 991 performed between two PCP devices, a MSK will be exported. The MSK 992 will be used to derive the transport keys to generate MAC digests for 993 subsequent PCP message exchanges. However, before a transport key 994 has been generated, the PA messages exchanged within a PA session 995 have little cryptographic protection, and if there is no already 996 established security channel between two session partners, these 997 messages are subject to man-in-the-middle attacks and DOS attacks. 998 For instance, the initial PA-Server and PA-Client exchange is 999 vulnerable to spoofing attacks as these messages are not 1000 authenticated and integrity protected. In addition, because the PRF 1001 and MAC algorithms are transported at this stage, an attacker may try 1002 to remove the PRF and MAC options containing strong algorithms from 1003 the initial PA-Server message and force the client choose the weakest 1004 algorithms. Therefore, the server needs to guarantee that all the 1005 PRF and MAC algorithms it provides support are strong enough. 1007 In order to prevent very basic DOS attacks, a PCP device SHOULD 1008 generate state information as little as possible in the initial PA- 1009 Server and PA-Client exchanges. The choice of EAP method is also 1010 very important. The selected EAP method must be resilient to the 1011 attacks possible in an insecure network environment, provide user- 1012 identity confidentiality, protection against dictionary attacks, and 1013 support session-key establishment. 1015 When a PCP proxy is located between a PCP server and PCP clients, the 1016 proxy may perform authentication with the PCP server before it 1017 processes requests from the clients. In addition, re-authentication 1018 between the PCP proxy and PCP server will not interrupt the service 1019 that the proxy provides to the clients since the proxy is still 1020 allowed to send common PCP messages to the PCP server during that 1021 period. 1023 9. Acknowledgements 1025 Thanks to Dan Wing for the valuable comments. 1027 10. Change Log 1028 10.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1029 authentication-00 1031 o Added discussion of in-band and out-of-band key management 1032 options, leaving choice open for later WG decision. 1034 o Removed support for fragmenting EAP messages, as that is handled 1035 by EAP methods. 1037 10.2. Changes from wasserman-pcp-authentication-01 to -02 1039 o Add a nonce into the first two exchanged PCP-Auth message between 1040 the PCP client and PCP server. When a PCP client initiate the 1041 session, it can use the nonce to detect offline attacks. 1043 o Add the key ID field into the authentication tag option so that a 1044 MSK can generate multiple traffic keys. 1046 o Specify that when a PCP device receives a PCP-Auth-Server or a 1047 PCP-Auth-Client message from its partner the PCP device needs to 1048 reply with a PCP-Auth-Acknowledge message to indicate that the 1049 message has been received. 1051 o Add the support of fragmenting EAP messages. 1053 10.3. Changes from ietf-pcp-authentication-00 to -01 1055 o Editorial changes, added use cases to introduction. 1057 10.4. Changes from ietf-pcp-authentication-01 to -02 1059 o Add the support of re-authentication initiated by PCP server. 1061 o Specify that when a PCP device receives a PCP-Auth-Server or a 1062 PCP-Auth-Client message from its partner the PCP device MAY reply 1063 with a PCP-Auth-Acknowledge message to indicate that the message 1064 has been received. 1066 o Discuss the format of the PCP-Auth-Acknowledge message. 1068 o Remove the redundant information from the Auth Opcode, and specify 1069 new result codes transported in PCP packet headers 1071 o 1073 10.5. Changes from ietf-pcp-authentication-02 to -03 1075 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1077 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1079 o Specify two new sequence numbers for common PCP messages in the 1080 PCP SA, and describe how to use them 1082 o Specify a Authentication Tag Option for PCP Common Messages 1084 o Introduce the scenario where a EAP message has to be divided into 1085 multiple sections and transported in different PCP-Auth messages 1086 (for the reasons of MTU), and introduce how to use PCP-Auth- 1087 Acknowledge messages to ensure reliable packet delivery in this 1088 case. 1090 10.6. Changes from ietf-pcp-authentication-03 to -04 1092 o Change the name "PCP-Auth" to "PA". 1094 o Refine the retransmission policies. 1096 o Add more discussion about the sequence number management . 1098 o Provide the discussion about how to instruct a PCP client to 1099 choose proper credential during authentication, and an ID 1100 Indication Option is defined for that purpose. 1102 10.7. Changes from ietf-pcp-authentication-04 to -05 1104 o Add contents in IANA considerations. 1106 o Add discussions in fragmentation. 1108 o Refine the PA messages retransmission policies. 1110 o Add IANA considerations. 1112 10.8. Changes from ietf-pcp-authentication-05 to -06 1114 o Added mechanism to handle algorithm downgrade attack. 1116 o Updated Security Considerations section. 1118 o Updated ID Indicator Option. 1120 11. References 1122 11.1. Normative References 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, March 1997. 1127 11.2. Informative References 1129 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1130 10646", STD 63, RFC 3629, November 2003. 1132 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1133 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1134 3748, June 2004. 1136 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1137 4306, December 2005. 1139 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1140 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1142 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1143 Yegin, "Protocol for Carrying Authentication for Network 1144 Access (PANA)", RFC 5191, May 2008. 1146 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1147 Authentication Protocol", RFC 5216, March 2008. 1149 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1150 Extensible Authentication Protocol Method for 3rd 1151 Generation Authentication and Key Agreement (EAP-AKA')", 1152 RFC 5448, May 2009. 1154 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1155 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1156 2013. 1158 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1159 "Tunnel Extensible Authentication Protocol (TEAP) Version 1160 1", RFC 7170, May 2014. 1162 Authors' Addresses 1163 Margaret Wasserman 1164 Painless Security 1165 356 Abbott Street 1166 North Andover, MA 01845 1167 USA 1169 Phone: +1 781 405 7464 1170 Email: mrw@painless-security.com 1171 URI: http://www.painless-security.com 1173 Sam Hartman 1174 Painless Security 1175 356 Abbott Street 1176 North Andover, MA 01845 1177 USA 1179 Email: hartmans@painless-security.com 1180 URI: http://www.painless-security.com 1182 Dacheng Zhang 1183 Huawei 1184 Beijing 1185 China 1187 Email: zhangdacheng@huawei.com 1189 Tirumaleswar Reddy 1190 Cisco Systems, Inc. 1191 Cessna Business Park, Varthur Hobli 1192 Sarjapur Marathalli Outer Ring Road 1193 Bangalore, Karnataka 560103 1194 India 1196 Email: tireddy@cisco.com