idnits 2.17.1 draft-ietf-pcp-authentication-05.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 applied 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 indicate at a PA message is received. Therefore, the reliable transmission of PA-Acknowledgement message does not have to be guaranteed. For instance, after sending out a PA-Acknowledgement message, a device generates a EAP response. In this case, the device should send it to its session partner directly and need not 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, the lost of a PA-Acknowledgement message during transportation will cause the mismatching issues with the sequence numbers. -- The document date (August 23, 2014) is 3534 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5191' is defined on line 1154, 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: February 24, 2015 D. Zhang 6 Huawei 7 August 23, 2014 9 Port Control Protocol (PCP) Authentication Mechanism 10 draft-ietf-pcp-authentication-05 12 Abstract 14 An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to 15 flexibly manage the IP address and port mapping information on 16 Network Address Translators (NATs) or firewalls, to facilitate 17 communications with remote hosts. However, the un-controlled 18 generation or deletion of IP address mappings on such network devices 19 may cause security risks and should be avoided. In some cases the 20 client may need to prove that it is authorized to modify, create or 21 delete PCP mappings. This document proposes an in-band 22 authentication mechanism for PCP that can be used in those cases. 23 The Extensible Authentication Protocol (EAP) is used to perform 24 authentication between PCP devices. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 24, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 64 3.2. Session Termination . . . . . . . . . . . . . . . . . . . 8 65 3.3. Session Re-Authentication . . . . . . . . . . . . . . . . 8 66 4. PA Security Association . . . . . . . . . . . . . . . . . . . 9 67 5. Result Code . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 11 70 6.2. Authentication OpCode . . . . . . . . . . . . . . . . . . 11 71 6.3. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 12 72 6.4. Authentication Tag Option for Common PCP . . . . . . . . 12 73 6.5. Authentication Tag Option for PCP Auth Messages . . . . . 14 74 6.6. EAP Payload Option . . . . . . . . . . . . . . . . . . . 14 75 6.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.8. MAC Algorithm Option . . . . . . . . . . . . . . . . . . 15 77 6.9. Session Lifetime Option . . . . . . . . . . . . . . . . . 16 78 6.10. Received Packet Option . . . . . . . . . . . . . . . . . 16 79 6.11. ID Indicator Option . . . . . . . . . . . . . . . . . . . 16 80 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17 81 7.1. Authentication Data Generation . . . . . . . . . . . . . 17 82 7.2. Authentication Data Validation . . . . . . . . . . . . . 18 83 7.3. Retransmission Policies for PA Messages . . . . . . . . . 18 84 7.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 19 85 7.5. Sequence Numbers for Common PCP Messages . . . . . . . . 20 86 7.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 21 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 90 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 11.1. Changes from wasserman-pcp-authentication-02 to ietf- 92 pcp-authentication-00 . . . . . . . . . . . . . . . . . 23 93 11.2. Changes from wasserman-pcp-authentication-01 to -02 . . 23 94 11.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 23 95 11.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 24 96 11.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 24 97 11.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 24 98 11.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 25 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 101 12.2. Informative References . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 104 1. Introduction 106 Using the Port Control Protocol (PCP) [RFC6887], an IPv4 or IPv6 host 107 can flexibly manage the IP address mapping information on its network 108 address translators (NATs) and firewalls, and control their policies 109 in processing incoming and outgoing IP packets. Because NATs and 110 firewalls both play important roles in network security 111 architectures, there are many situations in which authentication and 112 access control are required to prevent un-authorized users from 113 accessing such devices. This document proposes a PCP security 114 extension which enables PCP servers to authenticate their clients 115 with Extensible Authentication Protocol (EAP). The EAP messages are 116 encapsulated within PCP packets during transportation. 118 The following issues are considered in the design of this extension: 120 o Loss of EAP messages during transportation 122 o Disordered delivery of EAP messages 124 o Generation of transport keys 126 o Integrity protection and data origin authentication for PCP 127 messages 129 o Algorithm agility 131 The mechanism described in this document meets the security 132 requirements to address the Advanced Threat Model described in the 133 base PCP specification [RFC6887]. This mechanism can be used to 134 secure PCP in the following situations: 136 o On security infrastructure equipment, such as corporate firewalls, 137 that does not create implicit mappings for specific traffics. 139 o On equipment (such as CGNs or service provider firewalls) that 140 serve multiple administrative domains and do not have a mechanism 141 to securely partition traffic from those domains. 143 o For any implementation that wants to be more permissive in 144 authorizing explicit mappings than it is in authorizing implicit 145 mappings. 147 o For implementations that support the THIRD_PARTY Option (unless 148 they can meet the constraints outlined in Section 14.1.2.2). 150 o For implementations that wish to support any deployment scenario 151 that does not meet the constraints described in Section 14.1. 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 device (e.g., a host) which is responsible for 162 issuing PCP requests to a PCP server. In this document, a PCP client 163 is also a EAP peer [RFC3748], and it is the responsibility of a PCP 164 client to provide the credentials when authentication is required. 166 PCP Server: A PCP device (e.g., a NAT or a firewall) that implements 167 the server-side of the PCP protocol, via which PCP clients request 168 and manage explicit mappings. In this document, a PCP server is 169 integrated with an EAP authenticator [RFC3748]. Therefore, when 170 necessary, a PCP server can verify the credentials provided by a PCP 171 client and make an access control decision based on the 172 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 message 176 involved within a session includes the PA messages used to perform 177 EAP authentication, key distribution and session management, and the 178 common PCP messages secured with the keys distributed during 179 authentication. Each PA session is assigned a distinctive Session 180 ID. 182 Session Partner: A PCP device involved within a PA session. Each PA 183 session has two session partners (a PCP server and a PCP client). 185 Session Lifetime: The life period associated with a PA session, which 186 decides the lifetime of the current authorization given to the PCP 187 client. 189 PCP Security Association (PCP SA): A PCP security association is 190 formed between a PCP client and a PCP server by sharing cryptographic 191 keying material and associated context. The formed duplex security 192 association is used to protect the bidirectional PCP signaling 193 traffic between the PCP client and PCP server. 195 Master Session Key (MSK): A key derived by the partners of a PA 196 session, using an EAP key generating method (e.g., the one defined in 197 [RFC5448]). 199 PCP-Authentication (PA) message: A PCP message containing an 200 Authentication OpCode. Particularly, a PA message sent from a PCP 201 server to a PCP client is referred to as a PA-Server, while PA 202 message sent from a PCP client to a PCP server is referred to as a 203 PA-Client. Therefore, a PA-Server is actually a PCP response message 204 specified in [RFC6887], and a PA-Client is a PCP request message. 205 This document specifies an option, the Authentication Tag Option for 206 PCP Auth, to provide integrity protection and message origin 207 authentication for PA messages. 209 Common PCP message: A PCP message which does not contain an 210 Authentication OpCode. This document specifies an option, the 211 Authentication Tag Option for Common PCP, to provide integrity 212 protection and message origin authentication for the common PCP 213 messages. 215 3. Protocol Details 217 3.1. Session Initiation 219 At be 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 managements). The Authentication OpCode consists of two 225 fields: Session ID and Sequence Number. The Session ID field is used 226 to identify the session to which the message belongs. The sequence 227 number field is used to detect the disorder or the duplication 228 occurred during packet delivery. 230 When a PCP client intends to proactively initiate a PA session with a 231 PCP server, it sends a PA-Initiation message (a PA-Client message 232 with the result code "INITIATION") to the PCP server. In the 233 message, the Session ID and Sequence Number fields of the 234 Authentication OpCode are set as 0. The PCP client MAY also 235 optionally append a nonce option which consists of a random nonce 236 with the message. 238 After receiving the PA-Initiation, if the PCP server agrees to 239 initiate a PA session with the PCP client, it will reply with a PA- 240 Server message which contains an EAP Identity Request, and the result 241 code field of this PA-Server message is set as AUTHENTICATION- 242 REQUIRED. In addition, the server MUST assign a random session 243 identifier to distinctly identify this session, and fill the 244 identifier into the Session ID field of the Authentication OpCode in 245 the PA-Server message. The Sequence Number field of the 246 Authentication OpCode is set as 0. If there is a nonce option in the 247 received PA-Initiation message, the PA-Server message MUST be 248 attached with a nonce option so as to send the nonce value back. The 249 nonce will then be used by the PCP client to check the freshness of 250 this message. From now on, every PCP message within this session 251 will be attached with this session identifier. When receiving a PA 252 message from an unknown session, a PCP device MUST discard the 253 message silently. If the PCP client intends to simplify the 254 authentication process, it MAY append an EAP Identity Response 255 message within the PA-Initiation message so as to inform the PCP 256 server that it would like to perform EAP authentication and skip the 257 step of waiting for the EAP Identity Request. 259 In the scenario where a PCP server receives a common PCP request 260 message from a PCP client which needs to be authenticated, the PCP 261 server can reply with a PA-Server message to initiate a PA session. 262 The result code field of this PA-Server message is set as 263 AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a 264 session ID for the session and transfer it within the PA-Server 265 message. The Sequence Number field in the PA-Server is set as 0. In 266 the PA messages exchanged afterwards in this session, the session ID 267 MUST be used in order to help session partners distinguish the 268 messages within this session from those not within. When the PCP 269 client receives this initial PA-Server message from the PCP server, 270 it can reply with a PA-Client message or silently discard the request 271 message according to its local policies. In the PA-Client message, a 272 nonce option which consists of a random nonce MAY be appended. If 273 so, in the next PA-Server message, the PCP sever MUST forward the 274 nonce back within a nonce option. 276 In a PA session, an EAP request message is transported within a PA- 277 Server message, and an EAP answer message is transported within a PA- 278 Client message. EAP relies on the underlying protocol to provide 279 reliable transmission; any disordered delivery or loss of packets 280 occurred during transportation must be detected and addressed. 281 Therefore, after sending out a PA-Server message, the PCP server will 282 not send a new PA-Server message until it receives a PA-Client 283 message with a proper sequence number from the PCP client, and vice 284 versa. If a PCP device receives a PA message from its partner and 285 cannot generate a EAP response within a pre-specified period due to 286 certain reasons (e.g., waiting for human input to construct a EAP 287 message or waiting for the additional PA messages in order to 288 construct a complete EAP message), the PCP device MUST reply with a 289 PA-Acknowledge message (PA messages with a Received Packet Option) to 290 notify the packet has been received. This approach not only can 291 avoid un-necessarily retransmission of the PA message but also can 292 guarantee the reliable packet delivery in the conditions where a PCP 293 device needs to receive multiple PA messages before generating an EAP 294 response. 296 In this approach, it is mandated for a PCP client and a PCP server to 297 perform a key-generating EAP method in authentication. Therefore, 298 after a successful authentication procedure, a Master Session Key 299 (MSK) will be generated. If the PCP client and the PCP server want 300 to generate a traffic key using the MSK, they need to agree upon a 301 Pseudo-Random Function (PRF) for the transport key derivation and a 302 MAC algorithm to provide data origin authentication for subsequent 303 PCP packets. In order to do this, the PCP server needs to append a 304 set of PRF Options and MAC Algorithm Options to the initial PA-Server 305 message. Each PRF Option contains a PRF that the PCP server 306 supports, and each MAC Algorithm Option contains a MAC (Message 307 Authentication Code) algorithm that the PCP server supports. 308 Moreover, in the first PA-Server message, the server MAY also attach 309 a ID Indication Option to direct the client to choose correct 310 credentials.After receiving the options, the PCP client selects the 311 PRF and the MAC algorithm which it would like to use, and then attach 312 the associated PRF and MAC Algorithm Options to the next PA-Client 313 message. 315 After the EAP authentication, the PCP server sends out a PA-Server 316 message to indicate the EAP authentication and PCP authorization 317 results. If the EAP authentication succeeds, the result code of the 318 PA-Server message is AUTHENTICATION-SUCCEED. In this case, before 319 sending out the PA-Server message, the PCP server MUST generate a PCP 320 SA and use the derived transport key to generate a digest for the 321 message. The digest is transported within an Authentication Tag 322 Option for PCP Auth. A more detailed description of generating the 323 authentication data can be found in Section 7.1. In addition, the 324 PA-Server MAY also contain a Session Lifetime Option which indicates 325 the life-time of the PA session (i.e., the life-time of the MSK). 326 After receiving the PA-Server message, the PCP client then needs to 327 generate a PA-Client message as response. 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 by following 358 reasons: 360 o The session life period needs to be extended 362 o The sequence numbers is going to reach the maximum 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 never be rolled back and 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, the PCP server MUST update the SA and use the new 380 key to generate digests for the PA-Server and any subsequent PCP 381 message. In addition, the PA-Server MAY be appended with a Session 382 Lifetime Option which indicates the new life-time of the PA session. 384 If the EAP authentication fails, the result code of the last PA- 385 Server is "AUTHENTICATION-FAILED". If the EAP authentication 386 succeeds but Authorization fails, the result code of the last PA- 387 Server is "AUTHORIZATION-FAILED". In the latter two cases, the PA 388 session MUST be terminated immediately after the last PA message 389 exchange. 391 During re-autehtnication, the session partners can also exchange 392 common PCP messages in in parallel. The common PCP messages MUST be 393 protected with the current SA until the new SA has been generated. 395 4. PA Security Association 397 At the beginning of a PA session, a session SHOULD generate a PA SA 398 to maintain its state information during the session. The parameters 399 of a PA SA are listed as follows: 401 o IP address and UDP port number of the PCP client 403 o IP address and UDP port number of the PCP server 405 o Session Identifier 407 o Sequence number for the next outgoing PA message 409 o Sequence number for the next incoming PA message 411 o Sequence number for the next outgoing common PCP message 413 o Sequence number for the next incoming common PCP message 415 o Last outgoing message payload 417 o Retransmission interval 419 o MSK: The master session key generated by the EAP method. 421 o MAC algorithm: The algorithm that the transport key should use to 422 generate digests for PCP messages. 424 o Pseudo-random function: The pseudo random function negotiated in 425 the initial PA-Server and PA-Client exchange for the transport key 426 derivation 428 o Transport key: the key derived from the MSK to provide integrity 429 protection and data origin authentication for the messages in the 430 PA session. The life-time of the transport key SHOULD be 431 identical to the life-time of the session. 433 o The nonce selected by the PCP client at the initiation of the 434 session. 436 o Key ID: the ID associated with Transport key. 438 Particularly, the transport key is computed in the following way: 439 Transport key = prf(MSK, "IETF PCP"| Session_ID| Nonce| key ID), 440 where: 442 o The prf: The pseudo-random function assigned in the Pseudo-random 443 function parameter. 445 o MSK: The master session key generated by the EAP method. 447 o "IETF PCP": The ASCII code representation of the non-NULL 448 terminated string (excluding the double quotes around it). 450 o Session_ID: The ID of the session which the MSK is derived from. 452 o Nonce: The nonce selected by the client and transported in the 453 Initial PA-Client packet. If the PCP client does not select one, 454 this value is set as 0. 456 o Key ID: The ID assigned for the traffic key. 458 5. Result Code 460 This specification uses the result code field specified in the PCP 461 headers to transport the information for authentication and session 462 management. Particularly, the values of following result codes are 463 specified. 465 TBD INITIATION 467 TBD AUTHENTICATION-REQUIRED 469 TBD AUTHENTICATION-FAILED 471 TBD AUTHENTICATION-SUCCEED 473 TBD AUTHORIZATION-FAILED 475 TBD SESSION-TERMINATION 477 6. Packet Format 479 6.1. Packet Format of PCP Auth Messages 481 The format of PA-Server messages is identical to the response packet 482 format specified in Section 7.2 of [RFC6887]. 484 As illustrated in Figure 1, the PA-Client messages use the requester 485 header specified in Section 7.1 of[RFC6887]. The only difference is 486 that eight reserved bits are used to transfer the result codes (e.g., 487 "INITIATION", "AUTHENTICATION-FAILED"). Other fields in Figure 1 are 488 described in Section 7.1 of [RFC6887]. 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Version = 2 |R| Opcode | Reserved | Result Code | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Requested Lifetime (32 bits) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 | PCP Client's IP Address (128 bits) | 499 | | 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 : : 503 : Opcode-specific information : 504 : : 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 : : 507 : (optional) PCP Options : 508 : : 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 1. PA-Client message Format 513 6.2. Authentication OpCode 515 The following figure illustrates the format of an authentication 516 OpCode: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Session ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Sequence Number | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Session ID: This field contains a 32-bit PA session identifier. 528 Sequence Number: This field contains a 32-bit sequence number. In 529 this solution, a sequence number needs to be incremented on every 530 new (non-retransmission) outgoing packet in order to provide 531 ordering guarantee for PCP. 533 6.3. Nonce Option 535 Because the session identifier of PA session is determined by the PCP 536 server, a PCP client does not know the session identifier which will 537 be used when it sends out a PA-Initiation message. In order to 538 prevent an attacker from interrupting the authentication process by 539 sending off-line generated PA-Server messages, the PCP client needs 540 to generate a random number as nonce in the PA-Initiation message. 541 The PCP server will append the nonce within the initial PA-Server 542 message. If the PA-Server message does not carry the correct nonce, 543 the message will be discarded silently. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Option Code | Reserved | Option-Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Nonce | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Option-Length: The length of the Nonce Option (in octet), 554 including the 4 octet fixed header and the variable length of the 555 authentication data. 557 Nonce: A random 32 bits number which is transported within a PCC- 558 Initiate message and the corresponding reply message from the PCP 559 server. 561 6.4. Authentication Tag Option for Common PCP 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Option Code | Reserved | Option-Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Session ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Sequence Number | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Key ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 | Authentication Data (Variable) | 575 ~ ~ 576 | | 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Because there is no authentication OpCode in common PCP messages, the 581 authentication tag for common PCP messages needs to provide the 582 information of session ID and sequence numbers. 584 Option-Length: The length of the Authentication Tag Option for 585 Common PCP (in octet), including the 12 octet fixed header and the 586 variable length of the authentication data. 588 Session ID: A 32-bit field used to indicates the identifier of the 589 session that the message belongs to and identifies the secret key 590 used to create the message digest appended to the PCP message. 592 Sequence Number: This field contains a 32-bit sequence number. In 593 this solution, a sequence number needs to be incremented on every 594 new (non-retransmission) outgoing packet in order to provide 595 ordering guarantee for common PCP messages. 597 Key ID: The ID associated with the traffic key used to generate 598 authentication data. This field is filled with zero if MSK is 599 directly used to secure the message. 601 Authentication Data: A variable-length field that carries the 602 Message Authentication Code for the PCP packet. The generation of 603 the digest varies according to the algorithms specified in 604 different PCP SAs. This field MUST end on a 32-bit boundary, 605 padded with 0's when necessary. 607 6.5. Authentication Tag Option for PCP Auth Messages 609 This option is used to provide message authentication for PA 610 messages. Compared with the Authentication Tag Option for Common 611 PCP, the session ID field and the sequence number field are removed 612 because such information is provided in the Authentication OpCode. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Option Code | Reserved | Option-Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Key ID | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 | Authentication Data (Variable) | 623 ~ ~ 624 | | 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Option-Length: The length of the Authentication Tag Option for PCP 629 Auth (in octet), including the 12 octet fixed header and the 630 variable length of the authentication data. 632 Key ID: The ID associated with the traffic key used to generate 633 authentication data. This field is filled with zero if MSK is 634 directly used to secure the message. 636 Authentication Data: A variable-length field that carries the 637 Message Authentication Code for the PCP packet. The generation of 638 the digest varies according to the algorithms specified in 639 different PCP SAs. This field MUST end on a 32-bit boundary, 640 padded with 0's when necessary. 642 6.6. EAP Payload Option 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Option Code | Reserved | Option-Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 | EAP Message | 651 ~ ~ 652 | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Option-Length: The length of the EAP Payload Option (in octet), 656 including the 4 octet fixed header and the variable length of the 657 EAP message. 659 EAP Message: The EAP message transferred. Note this field MUST 660 end on a 32-bit boundary, padded with 0's when necessary. 662 6.7. PRF Option 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Option Code | Reserved | Option-Length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | PRF | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Option-Length: The length of the PRF Option (in octet), including the 673 4 octet fixed header and the variable length of the EAP message. 675 PRF: The Pseudo-Random Function which the sender supports to generate 676 an MSK. This field contains an IKEv2 Transform ID of Transform Type 677 2 [RFC4306][RFC4868]. A PCP implementation MUST support 678 PRF_HMAC_SHA2_256 (5). 680 6.8. MAC Algorithm Option 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Option Code | Reserved | Option-Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | MAC Algorithm ID | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Option-Length: The length of the MAC Algorithm Option (in octet), 691 including the 4 octet fixed header and the variable length of the EAP 692 message. 694 MAC Algorithm ID: Indicate the MAC algorithm which the sender 695 supports to generate authentication data. The MAC Algorithm ID field 696 contains an IKEv2 Transform ID of Transform Type 3 697 [RFC4306][RFC4868].A PCP implementation MUST support 698 AUTH_HMAC_SHA2_256_128 (12). 700 6.9. Session Lifetime Option 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Option Code | Reserved | Option-Length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Session Lifetime | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Option-Length: The length of the Session Lifetime Option (in octet), 711 including the 4 octet fixed header and the variable length of the EAP 712 message. 714 Session Lifetime: The life time of the PA Session, which is decided 715 by the authorization result. 717 6.10. Received Packet Option 719 This option is used in a PA-Acknowledgement message to indicate a 720 packet with the contained sequence number has been received. 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Option Code | Reserved | Option-Length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Received Sequence Number | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Option-Length: The length of the Received Packet Option (in octet), 731 including the 4 octet fixed header and the variable length of the EAP 732 message. 734 Received Sequence Number: The sequence number of the last received 735 PCP packet. 737 6.11. ID Indicator Option 739 This option provide the an identifier to the PCP client that the 740 client can use to choose which credentials to provide to the PCP 741 server. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Option Code | Reserved | Option-Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 | ID Indicator | 750 ~ ~ 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Option-Length: The length of the ID Indication Option (in octet), 755 including the 4 octet fixed header and the variable length of the 756 EAP message. 758 ID Indicator: The value for a PCP client to choose proper 759 credentials for authentication. The method of generating this 760 value is out of scope of this document. Note that this field 761 could be user friendly and may contain the enterprise name and PCP 762 server name in a human-readable format.This field is encoded in 763 UTF-8 [RFC3629] format This field MUST end on a 32-bit boundary, 764 padded with 0's when necessary. 766 7. Processing Rules 768 7.1. Authentication Data Generation 770 If a PCP SA is generated as the result of a successful EAP 771 authentication process, every subsequent PCP message within the 772 session MUST carry an Authentication Tag Option which contains the 773 digest of the PCP message for data origin authentication and 774 integrity protection. 776 Before generating a digest for a PA message, a device needs to first 777 locate the PCP SA according to the session identifier and then get 778 the traffic key. Then the device appends an Authentication Tag 779 Option for PCP Auth at the end of the PCP Auth message. The length 780 of the Authentication Data field is decided by the MAC algorithm 781 adopted in the session. The device then fills the Key ID field with 782 the key ID of the traffic key, and sets the Authentication Data field 783 to 0. After this, the device generates a digest for the entire PCP 784 message (including the PCP header and Authentication Tag Option) 785 using the traffic key and the associated MAC algorithm, and insert 786 the generated digest into the Authentication Data field. 788 Similar to generating a digest for a PA message, before generating a 789 digest for a common PCP message, a device needs to first locate the 790 PCP SA according to the session identifier and then get the traffic 791 key. Then the device appends the Authentication Tag Option for 792 common PCP at the end of the message. The length of the 793 Authentication Data field is decided by the MAC algorithm adopted in 794 the session. The device then use the corresponding values derived 795 from the SA to fills the Session ID field, the Sequence Number field, 796 and the Key ID field, and sets the Authentication Data field to 0. 797 After this, the device generates a digest for the entire PCP message 798 (including the PCP header and Authentication Tag Option) using the 799 traffic key and the associated MAC algorithm, and inputs the 800 generated digest into the Authentication Data field. 802 7.2. Authentication Data Validation 804 When a device receives a common PCP packet with an Authentication Tag 805 Option for Common PCP, the device needs to use the session ID 806 transported in the option to locate the proper SA, and then find the 807 associated transport key (using key ID in the option) and the MAC 808 algorithm. If no proper SA or traffic key is found or the sequence 809 number is invalid (see Section 7.5), the PCP packet MUST be discarded 810 silently. After storing the value of the Authentication field of the 811 Authentication Tag Option, the device fills the Authentication field 812 with zeros. Then, the device generates a digest for the packet 813 (including the PCP header and Authentication Tag Option) with the 814 transport key and the MAC algorithm found in the first step. If the 815 value of the newly generated digest is identical to the stored one, 816 the device can ensure that the packet has not been tampered with, and 817 the validation succeeds. Otherwise, the packet MUST be discarded. 819 Similarly, when a device receives a PA message with an Authentication 820 Tag Option for PCP Auth, the device needs to use the session ID 821 transported in the opcode to locate the proper SA, and then find the 822 associated transport key (using key ID in the option) and the MAC 823 algorithm. If no proper SA or traffic key is found or the sequence 824 number is invalid (see Section 7.4), the PCP packet MUST be discarded 825 silently. After storing the value of the Authentication field of the 826 Authentication Tag Option, the device fills the Authentication field 827 with zeros. Then, the device generates a digest for the packet 828 (including the PCP header and Authentication Tag Option) with the 829 transport key and the MAC algorithm found in the first step. If the 830 value of the newly generated digest is identical to the stored one, 831 the device can ensure that the packet has not been tampered with, and 832 the validation succeeds. Otherwise, the packet MUST be discarded. 834 7.3. Retransmission Policies for PA Messages 836 Because EAP relies on the underlying protocols to provide reliable 837 transmission, after sending a PA message, a PCP client/server MUST 838 NOT send out any subsequent messages until receiving an expect PA 839 message (the PA message with a proper sequence number) from the peer. 840 If no such a message is received in a certain period, the PCP device 841 will re-send the last message according to certain retransmission 842 policies. This work reuses the retransmission policies specified in 843 the base PCP protocol (Section 8.1.1 of [RFC6887]). In the base PCP 844 protocol, such retransmission policies are only applied by PCP 845 clients. However, in this work, such retransmission policies are 846 also applied by the PCP servers. If the timer is expired and no 847 expected response is received, the device will terminate the session 848 and discard the current SA. 850 Note that the last PA messages transported within the phases of 851 session initiation, session re-authentication, and session 852 termination do not have to follow the above policies since the 853 devices sending out those messages do not expect any further PA 854 messages. 856 When a device receives such a duplicate PA message from its session 857 partner, it MUST try to answer it by sending the last outgoing PA 858 message again. In order to achieve this function, the device needs 859 to maintain the last incoming and the assoicated outgoing packet. In 860 this case, if no outgoing PA message has been generated for the 861 received duplicate PA message yet, the device needs to generate a PA- 862 Acknowledgement message and sends it out. The rate of replying the 863 duplicate PA messages MUST be limited. 865 7.4. Sequence Numbers for PCP Auth Messages 867 PCP adopts UDP to transport signaling messages. As an un-reliable 868 transport protocol, UDP does not guarantee ordered packet delivery 869 and does not provide any protection from packet loss. In order to 870 ensure the EAP messages are exchanged in a reliable way, every PCP 871 packet exchanged during EAP authentication must carry an 872 monotonically increasing sequence number. During a PA session, a PCP 873 device needs to maintain two sequence numbers for PA messages, one 874 for incoming PA messages and one for outgoing PA messages. When 875 generating an outgoing PA packet, the device attaches the associated 876 outgoing sequence number to the packet and increments the sequence 877 number maintained in the SA by 1. When receiving a PA packet from 878 its session partner, the device will not accept it if the sequence 879 number carried in the packet does not match the incoming sequence 880 number the device maintains. After confirming that the received 881 packet is valid, the device increments the incoming sequence number 882 maintained in the SA by 1. 884 The above rules are not applied to PA-Acknowledgement messages (i.e., 885 PA messages containing a Received Packet Option). A PA- 886 Acknowledgement message does not transport any EAP message and only 887 indicate at a PA message is received. Therefore, the reliable 888 transmission of PA-Acknowledgement message does not have to be 889 guaranteed. For instance, after sending out a PA-Acknowledgement 890 message, a device generates a EAP response. In this case, the device 891 should send it to its session partner directly and need not to 892 confirm whether the PA-Acknowledgement message has been received by 893 its session partner or not. Therefore, when receiving or sending out 894 a PA-Acknowledgement message, the device MUST not increase the 895 corresponding sequence number stored in the SA. Otherwise, the lost 896 of a PA-Acknowledgement message during transportation will cause the 897 mismatching issues with the sequence numbers. 899 Another exception is in the message retransmission scenarios. When a 900 device does not receive any response from its session partner in a 901 certain period, it needs to retransmit the last outgoing PA message 902 with a limited rate. The duplicate messages and the original message 903 MUST use the identical sequence number. When the device receives 904 such a duplicate PA message from its session partner, it MUST try to 905 answer it by sending the last outgoing PA message again. Note the 906 rate of replying the duplicate PA messages must be limited. In such 907 cases, the maintained incoming and outgoing sequence numbers will not 908 be affected by the message retransmission. 910 7.5. Sequence Numbers for Common PCP Messages 912 When transporting common PCP messages within a PA session, a PCP 913 device needs to maintain a sequence number for outgoing common PCP 914 messages and a sequence number for incoming common PCP messages. 915 When generating a new outgoing PCP messages, the PCP device attaches 916 the outgoing sequence number for common PCP messages to the messages 917 and increments the sequence number maintained in the SA by 1. 919 When receiving a PCP packet from its session partner, the PCP device 920 will not accept it if the sequence number carried in the packet is 921 smaller than the incoming sequence number the server maintains. This 922 approach can protect the PCP server from replay attacks. After 923 confirming that the received packet is valid, the PCP server will use 924 the sequence number in the incoming packet to take place the incoming 925 sequence number for common PCP messages maintained in the SA. 927 Note that the sequence number in the incoming packet may not exactly 928 match the incoming sequence number maintained locally. In the base 929 PCP specification [RFC6887], a PCP client may stop retransmitting a 930 PCP request without receiving any expected PCP answer when the client 931 is no longer interested in the PCP transaction. After that, the PCP 932 client will try to generate new PCP requests for other purposes using 933 the current SA. In this case, the sequence number in the new request 934 will be larger than the sequence number in the old request and so 935 will be larger the incoming sequence number maintained in the PCP 936 server. 938 Note that in the base EAP sepcification [RFC6887], a PCP client needs 939 to select a nonce in each MAP or PEER request, the nonce is requested 940 to sent back in the response. However, it is possible for a client 941 to use the same nonce in multiple MAP or PEER request, this may cause 942 potential risk of replay attacks. Under the assistance of the 943 sequence number attached in the PCP responses, this issues can be 944 addressed. 946 7.6. MTU Considerations 948 EAP methods are responsible for MTU handling, so no special 949 facilities are required in this protocol to deal with MTU issues. 950 Particularly, EAP lower layers indicate to EAP methods and AAA 951 servers what the MTU of the lower layer is. EAP methods such as EAP- 952 TLS, TEAP, and others that are likely to exceed reasonable MTUs 953 provide fragmentation and reassembley. Others, such as EAP-GPSK 954 assume they will never send packets larger than the MTU and focus on 955 small EAP packets. 957 If an EAP message is too long to be transported within a single PA 958 message, it will be divided into multiple sections and transport them 959 within different PA messages. Note that the receiver may not be able 960 to know what to do in the next step until receiving all the sections 961 and constructing the complete EAP message. In this case, in order to 962 guarantee reliable message transmission, after receiving a PA 963 message, the receiver needs reply with a PA-Acknowledgement message 964 in order to notify the sender to send the next PA message. 966 8. IANA Considerations 968 In order to identify Authentication OpCode, a new value (TBD) needs 969 to be defined in the IANA registry for PCP Opcodes. 971 A set of options are defined in this specification, each of them 972 needs to be associated with a value defined in the IANA registry for 973 PCP option code: 975 Nonce Option TBD 977 Authentication Tag Option for Common PCP TBD 979 Authentication Tag Option for PCP Auth Messages TBD 981 EAP Payload Option TBD 982 PRF Option TBD 984 MAC Algorithm Option TBD 986 Session Lifetime Option TBD 988 Received Packet Option TBD 990 ID Indication Option TBD 992 A set of new result codes is specifided in this specification, each 993 result code needs to assigned a value in the IANA registry for PCP 994 result codes. 996 TBD INITIATION TBD 998 TBD AUTHENTICATION-REQUIRED TBD 1000 TBD AUTHENTICATION-FAILED TBD 1002 TBD AUTHENTICATION-SUCCEED TBD 1004 TBD AUTHORIZATION-FAILED TBD 1006 TBD SESSION-TERMINATION TBD 1008 9. Security Considerations 1010 In this work, after a successful EAP authentication process performed 1011 between two PCP devices, a MSK will be exported. The MSK can be used 1012 to derive the transport keys to generate MAC digests for subsequent 1013 PCP message exchanges. However, before a transport key has been 1014 generated, the PA messages exchanged within a PA session have little 1015 cryptographic protection, and if there is no already established 1016 security channel between two session partners, these messages are 1017 subject to man-in-the-middle attacks and DOS attacks. For instance, 1018 the initial PA-Server and PA-Client exchange is vulnerable to 1019 spoofing attacks as these messages are not authenticated and 1020 integrity protected. In addition, because the PRF and MAC algorithms 1021 are transported at this stage, an attacker may try to remove the PRF 1022 and MAC options containing strong algorithms from the initial PA- 1023 Server message and force the client choose the weakest algorithms. 1024 Therefore, the server needs to guarantee that all the PRF and MAC 1025 algorithms it provides support are strong enough. 1027 In order to prevent very basic DOS attacks, a PCP device SHOULD 1028 generate state information as little as possible in the initial PA- 1029 Server and PA-Client exchanges. The choice of EAP method is also 1030 very important. The selected EAP method must be resilient to the 1031 attacks possibly in an insecure network environment, and the user- 1032 identity confidentiality, protection against dictionary attacks, and 1033 session-key establishment must be supported. 1035 When there is a PCP proxy located between a PCP server and a set of 1036 clients, the proxy may need to perform authentication with the PCP 1037 server before it generates requests for the clients. In addition, 1038 re-authentication will not interrupt the service that the proxy 1039 provides to the clients since the proxy is still allowed to send 1040 common PCP messages to the server during that period. 1042 10. Acknowledgements 1044 Thanks Tirumaleswar Reddy and Dan Wing for the value comments. 1046 11. Change Log 1048 11.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1049 authentication-00 1051 o Added discussion of in-band and out-of-band key management 1052 options, leaving choice open for later WG decision. 1054 o Removed support for fragmenting EAP messages, as that is handled 1055 by EAP methods. 1057 11.2. Changes from wasserman-pcp-authentication-01 to -02 1059 o Add a nonce into the first two exchanged PCP-Auth message between 1060 the PCP client and PCP server. When a PCP client initiate the 1061 session, it can use the nonce to detect offline attacks. 1063 o Add the key ID field into the authentication tag option so that a 1064 MSK can generate multiple traffic keys. 1066 o Specify that when a PCP device receives a PCP-Auth-Server or a 1067 PCP-Auth-Client message from its partner the PCP device needs to 1068 reply with a PCP-Auth-Acknowledge message to indicate that the 1069 message has been received. 1071 o Add the support of fragmenting EAP messages. 1073 11.3. Changes from ietf-pcp-authentication-00 to -01 1075 o Editorial changes, added use cases to introduction. 1077 11.4. Changes from ietf-pcp-authentication-01 to -02 1079 o Add the support of re-authentication initiated by PCP server. 1081 o Specify that when a PCP device receives a PCP-Auth-Server or a 1082 PCP-Auth-Client message from its partner the PCP device MAY reply 1083 with a PCP-Auth-Acknowledge message to indicate that the message 1084 has been received. 1086 o Discuss the format of the PCP-Auth-Acknowledge message. 1088 o Remove the redundant information from the Auth OpCode, and specify 1089 new result codes transported in PCP packet headers 1091 o 1093 11.5. Changes from ietf-pcp-authentication-02 to -03 1095 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1097 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1099 o Specify two new sequence numbers for common PCP messages in the 1100 PCP SA, and describe how to use them 1102 o Specify a Authentication Tag Option for PCP Common Messages 1104 o Introduce the scenario where a EAP message has to be divided into 1105 multiple sections and transported in different PCP-Auth messages 1106 (for the reasons of MTU), and introduce how to use PCP-Auth- 1107 Acknowledge messages to ensure reliable packet delivery in this 1108 case. 1110 11.6. Changes from ietf-pcp-authentication-03 to -04 1112 o Change the name "PCP-Auth" to "PA". 1114 o Refine the retransmission policies. 1116 o Add more discussion about the sequence number management . 1118 o Provide the discussion about how to instruct a PCP client to 1119 choose proper credential during authentication, and an ID 1120 Indication Option is defined for that purpose. 1122 11.7. Changes from ietf-pcp-authentication-04 to -05 1124 o Add contents in IANA considerations. 1126 o Add discussions in fragmentation. 1128 o Refine the PA messages retransmission policies. 1130 o Add IANA considerations. 1132 12. References 1134 12.1. Normative References 1136 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1137 Requirement Levels", BCP 14, RFC 2119, March 1997. 1139 12.2. Informative References 1141 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1142 10646", STD 63, RFC 3629, November 2003. 1144 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1145 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1146 3748, June 2004. 1148 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1149 4306, December 2005. 1151 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1152 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1154 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1155 Yegin, "Protocol for Carrying Authentication for Network 1156 Access (PANA)", RFC 5191, May 2008. 1158 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1159 Extensible Authentication Protocol Method for 3rd 1160 Generation Authentication and Key Agreement (EAP-AKA')", 1161 RFC 5448, May 2009. 1163 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1164 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1165 2013. 1167 Authors' Addresses 1169 Margaret Wasserman 1170 Painless Security 1171 356 Abbott Street 1172 North Andover, MA 01845 1173 USA 1175 Phone: +1 781 405 7464 1176 Email: mrw@painless-security.com 1177 URI: http://www.painless-security.com 1179 Sam Hartman 1180 Painless Security 1181 356 Abbott Street 1182 North Andover, MA 01845 1183 USA 1185 Email: hartmans@painless-security.com 1186 URI: http://www.painless-security.com 1188 Dacheng Zhang 1189 Huawei 1190 Beijing 1191 China 1193 Email: zhangdacheng@huawei.com